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
> 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.
Received on 2010-04-29 22:32:37 CEST