On 18.01.2012 14:45, Julian Foad wrote: >> A@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