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=86&rev2=87 Comment: More criss-cross. * Candidate changes are { A2, A3 }. * Target natural history is { B1, B2, B3 }; target mergeinfo is { A1 }. * Notice candidate A3 can be skipped because it represents B1, as before. - * Merge just A2 to B. + * Merge "just" A2 to B. + * Conflict between A2 and { B1, B2 } has to be resolved. + * Conflict between A2 and B1 had already been resolved in the B1 -> A3 merge, so this part of the user's work is repetitive. + + The two sides of the merge are A1:A2 which we can write as { A2 }, and A1:B3 which represents original changes { B1, B2 }. The conflict between A2 and B2 has not been resolved before, but the conflict between A2 and B1 had already been resolved by the user during the merge B1->A3. + + The conflict between A2 and B1 will be broadly the same as it was before. It will not be exactly the same, because the conflicting hunks that were previously seen in B1 are now being seen in state B3 where they may have been modified or moved around by the subsequent changes B2 and B3. + + The quality of the result here can be judged by how much conflict the merge encounters that the user feels should not be necessary. If there is a lot of conflict between A2 and B1 (perhaps B1 is a big change), the user may feel that it should not be necessary to resolve that part of the conflict again. If there is little conflict between A2 and B1, resolving that again is no big deal. If B1 were picked as base: @@ -523, +531 @@ * 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. - That's just like before, so the change B2 doesn't matter. + If O were picked as base: + + * Candidate changes are { A1, A2, A3 }. + * Target natural history is { B1, B2, B3 }; target mergeinfo is { A1 }. + * Notice candidate A1 is already on B, and A3 represents B1, so those can be skipped. + * The merge would then be: base A1, source-right A2, target B4. + + That is then the same as if we'd picked A1 as base. === Criss-Cross #4: with unmerged logical changes on both sides === Let's try the same but with changes after the merges as well. {{attachment:merge-criss-cross-4.png|criss-cross merge 4}} + If A1 were picked as base: + + * Candidate changes are { A2, A3, A4 }. + * Target natural history is { B1, B2, B3, B4 }; target mergeinfo is { A1 }. + * Notice candidate A3 can be skipped because it represents B1, as before. + * Merge just A2 to B. === 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.
