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=62&rev2=63 Comment: Add a second criss-cross merge graph. == Symmetric Merge with Criss-Cross Merge == The following kind of merge history is known as a 'criss-cross' merge. - {{attachment:merge-criss-cross-1.png|criss-cross merge}} + {{attachment:merge-criss-cross-1.png|criss-cross merge 2}} The scenario is notorious for being an awkward case for typical DAG-oriented merge algorithms to handle. There are two possible bases, and neither of them is clearly the right one to use, and the choice may make a difference to the result in the general case. @@ -268, +268 @@ 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. - In the general case, a criss-cross merge need not be a no-op. For example, if there had been an original logical change on A after A1 and before A2, then ... [? such a change would have been included in the merge to B3 ?]. + In the general case, a criss-cross merge need not be a no-op. Consider the following case: - [TODO: graph] + {{attachment:merge-criss-cross-2.png|criss-cross merge 2}} If A1 were picked as base: - * Candidate changes are { A1.5, A2 }. + * Candidate changes are { A2, A3 }. * Target natural history is { B1 }; target mergeinfo is { A1 }. - * Notice candidate A2 can be skipped, as before. + * Notice candidate A3 can be skipped, as before. - * Merge just A1.5 to B. + * Merge just A2 to B. * Update the mergeinfo on B. (See "Recording Mergeinfo for Skipped Changes".) * Perfect result. If B1 were picked as base: - * Candidate changes are { B1:A2 }. + * Candidate changes are { B1:A3 }. * Target natural history is { B1 }; target mergeinfo is { A1 }. - * Notice candidate B1:A2 represents logical changes { A1, A1.5 }. A1 is already on B; A1.5 isn't. Therefore we can neither merge nor skip this change. + * Notice candidate B1:A3 represents logical changes { A1, A2 }. A1 is already on B; A2 isn't. Therefore we can neither merge nor skip this change. * Bail out, telling the user there's a problem. It appears that in this case there is a "good" base and a "bad" base. We could automatically detect this (by trying both ways, if not more easily).
