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=82&rev2=83 {{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. + The scenario is notorious for being an awkward case for typical DAG-oriented merge algorithms to handle. At first glance, there are two likely-looking nodes that could be considered as a base, but neither of them leads to a correct 3-way merge in the general case where changes have been made on both branches. In fact, in general there is no way to reconcile the two branches just by using simple 3-way merges without reverse-merging and user interaction. I don't expect to be able to teach Subversion to resolve criss-cross merges automatically, and I don't think this is important. I think it's on the same level as resolving cases where the user cherry-picked some changes from branches A and B into a third branch C all at once (in one commit) and then wants to automatically sync-merge from C into A. In this case as in that case, Subversion should simply detect that there is no sequence of plain 3-way merges possible, and tell the user. + + We now analyze what Subversion's symmetric merge algorithm will do in such cases. === Criss-Cross #1: Minimal === This is how Subversion will handle the simple criss-cross merge illustrated in the graph above. @@ -352, +354 @@ That's just like before, so the change B2 doesn't matter. === Conclusion about Criss-Cross merges === + As noted above, I don't expect Subversion to solve criss-cross cases, at least I put this at a lower priority than 3-branch merge patterns. + + It seems that sometimes there is a "good" base: that is, in some cases it is possible to choose a base and break down the required merge into a series of simple 3-way merges. If we can do so without too much trouble, it would be nice to automatically do this when possible. + + TODO: find an example where there is no good base. Maybe if we extend #3 by adding further changes after A3 and B3 before the merge attempt? + 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. ----
