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 JulianFoad: http://wiki.apache.org/subversion/SymmetricMerge?action=diff&rev1=71&rev2=72 Comment: Typo 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}} @@ -271, +269 @@ 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 === + === Criss-Cross #2: With unmerged logical changes on the source === - In the general case, a criss-cross merge need not be a no-op. Consider the following case: {{attachment:merge-criss-cross-2.png|criss-cross merge 2}} @@ -300, +297 @@ 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}} @@ -322, +318 @@ 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. ---- @@ -339, +334 @@ == The Two Sides of a Merge == TODO: Explain the idea that the result of a 3-way merge from branch A to B, committed as B3, can be seen either as a change on B consisting of the addition of some stuff from A, or can be seen equally validly as the change A2:B3 consisting of the merging of recent changes on B into the context of A. The fact that the result was committed on branch B does not matter; the same result could have been committed on branch A, or on both branches. - Consider a simple history (TODO: graph: O, A1, B1, B1:A2). The changes committed as rA2 can been seen in two ways: either as the application of logical change B1 to branch A, or as the application of logical changes O:A1 to branch B. + Consider a simple history (TODO: graph: O, A1, B1, B1:A2). The changes committed as rA2 can been seen in two ways: either as the application of logical change B1 to branch A, or as the application of logical changes O:A1 to branch B. == Terminology == complete merge:: A merge that merges all the changes from the source branch that have not yet been merged into the target. A ''sync'' merge and a ''reintegrate'' merge and a ''symmetric'' merge are all ''complete'' merges.
