On Thu, Apr 29, 2010 at 9:17 PM, Vadym Chepkov <vchepkov_at_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
> (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).
> 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.
Received on 2010-04-29 22:32:37 CEST