On Thu, Apr 29, 2010 at 9:17 PM, Vadym Chepkov <vchep...@gmail.com> wrote:
> > On Apr 29, 2010, at 3:47 AM, Daniel Becroft wrote: > > > > [b2]$ svn merge --dry-run ^/branches/b1 >> --- Merging r2 through r4 into '.': >> C README >> Summary of conflicts: >> Tree conflicts: 1 >> > > > After r3, you'll need to do a '--record-only' merge of r4 into the second > branch: > > (untested) svn merge --record-only -c 4 ^/branches/b1 > > SVN doesn't seem to trace back through the commits to see that r3 was > really a merge from b2->b1. Like yourself, I initially though that it would > be able to deal with this, but it doesn't seem to (and there is probably a > very good reason why it can't). > > Cheers, > Daniel B. > > > Well, as you can see in the log, it also wants to merge r3 back, not just > r4, so we would have to "record-only" 2 of them, it seems. > I'm pretty sure that you only need to do a record-only of r4. If you do a 'svn merge -r 2:3 ^/branches/b1, I don't think it will actually do anything (other than modify the mergeinfo property). When I get a chance, I'll run a quick test on it (or if you have the WCs from the above example, you could try it yourself). > The problem is, we utilize a "home made" automerge utility that constantly > merges all changes from b1 to b2, > but merges from b2 to b1 are done manually. After r4 is committed, it > produces conflict for automerge immediately and this is what I am trying to > avoid. By the way, maybe there is an intelligent automerge utility out > there that can handle this kind of things, if anyone knows. > You could check if r4 contains mergeinfo for b2, and if so, don't worry about doing the merge between b1->b2, or force it to be record-only. Cheers, Daniel B.
