On 18.01.2012 14:45, Julian Foad wrote:
>> A_at_1---r4---r5---r6---r7----------------r11----------->
>> |\ ^ |
>> | \ | |
>> | \ reintegrate |
>> | V | |
>> | A_COPY_2-----------------r9---r10--- |
>> | ^ sync merge
>> | / |
>> | cherry-pick merge of r8 |
>> V / V
>> A_COPY-------------------r8------------------------->
>
> Thanks for this good example of a more complex use case. I've included it in <http://wiki.apache.org/subversion/KeepingReintegratedBranchAlive> and written up a discussion of the options there.
>
> What do we want in this case? The options are basically:
>
> (1) try to merge (as we do now), despite knowing it will conflict;
Actually, you know that it will not conflict, unless r9 or r10
introduced changes in the same place as r8. Otherwise the code is the
same and diff3 should skip that part, yes?
> (2) skip r11 (not usually good in this kind of case);
In fact, always wrong.
> (3) figure out what really "should" be merged and merge it;
That's what diff3 is for, isn't it. Mergeinfo is always only a hint
about whole revisions. If you want to know what "should" be merged,
you'd have to track the merged changes at least at hunk granularity, if
not actual line level. Specifically, mergeinfo doesn't help at all once
you start cherry-picking. Even a cherry-pick merge of a single revision
will produce /some/ extraneous changes to the target branch, even if
it's only as much as shifting lines around a bit due to patch fuzz.
> (4) stop and tell the user what's up.
"This bit is a conflict" that comes out of diff3 is exactly that. Using
diff4 would help a bit, but basically, if the user moves the code around
too much, all bets are off.
-- Brane
Received on 2012-01-18 20:03:34 CET