Dear Wiki user, You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.
The "SymmetricMerge" page has been changed by DanielShahaf: http://wiki.apache.org/subversion/SymmetricMerge?action=diff&rev1=69&rev2=70 Comment: criss-cross += subheaders Next, we need to account for cherry-picks. If there are cherry-picks from the source [...], we look for the end of the first gap. [TODO...] == Symmetric Merge with Criss-Cross Merge == + + === Criss-Cross #1: Minimal === + The following kind of merge history is known as a 'criss-cross' merge. {{attachment:merge-criss-cross-1.png|criss-cross merge 2}} @@ -267, +270 @@ * Perfect result. (In this case, no-op.) One non-trivial requirement here is that the cherry-pick identification step recognizes that B1:A2 is a candidate change (although it is not in itself a change on the natural history of any branch), and that it represents logical change A1. + + === Criss-Cross #2: With unmerged logical changes on the sourcew === In the general case, a criss-cross merge need not be a no-op. Consider the following case: @@ -292, +297 @@ If we don't automatically detect and select the good base, then criss-cross merges would sometimes work and sometimes not, with little clue as to why. - It seems like there must be more complex cases in which neither base will work. Let's try the same but with a change in B as well. + It seems like there must be more complex cases in which neither base will work. + + === Criss-Cross #3: with unmerged logical changes on both sides === + + Let's try the same but with a change in B as well. {{attachment:merge-criss-cross-3.png|criss-cross merge 3}} @@ -311, +320 @@ * Bail out, telling the user there's a problem. That's just like before, so the change B2 doesn't matter. + + === Conclusion about Criss-Cross merges === Can we define the base-choosing algorithm so that it always picks the "good" base when there is one? The last rev on A synced to B is A1, and the last rev on B synced to A is B1. Normally, we'd expect either B1 to be >= the target of the A1->B merge, or vice versa. But neither is the case here; that's more or less what defines this as a criss-cross. There's something special going on, so the presence of change A2 makes a base on the source branch succeed whereas a base on the target branch fails. We perhaps just need to codify that "something special" -- some rule that says which base to consider the "better one" depending on the relative ages of ... A1, B1, A3, B3, and A2.
