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=63&rev2=64 Comment: More criss-cross. If we pick base A1: - * Candidate changes are { A2 }. + * Candidate changes are { A2 }. - * Target natural history is { B1 }; target mergeinfo is { A1 }. + * Target natural history is { B1,B2 }; target mergeinfo is { A1 }. * Notice candidate A2 can be skipped because it represents a logical change (B1) that is already in the target branch's natural history. * Skip A2 from the source ranges. - * Update the mergeinfo on B. (See "Recording Mergeinfo for Skipped Changes".) + * Update the mergeinfo on B. (See "Recording Mergeinfo for Skipped Changes".) * Perfect result. (In this case, no-op.) If we pick base B1: - * Candidate changes are { B1:A2 }. + * Candidate changes are { B1:A2 }. - * Target natural history is { B1 }; target mergeinfo is { A1 }. + * Target natural history is { B1,B2 }; target mergeinfo is { A1 }. * Notice candidate B1:A2 can be skipped because it represents a logical change (A1) that is already recorded as merged into the target branch. * Skip B1:A2 from the source ranges. - * Update the mergeinfo on B. (See "Recording Mergeinfo for Skipped Changes".) + * Update the mergeinfo on B. (See "Recording Mergeinfo for Skipped Changes".) * 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. @@ -274, +274 @@ If A1 were picked as base: - * Candidate changes are { A2, A3 }. + * Candidate changes are { A2, A3 }. - * Target natural history is { B1 }; target mergeinfo is { A1 }. + * Target natural history is { B1,B3 }; target mergeinfo is { A1 }. - * Notice candidate A3 can be skipped, as before. + * Notice candidate A3 can be skipped because it represents B1, as before. * Merge just A2 to B. * Update the mergeinfo on B. (See "Recording Mergeinfo for Skipped Changes".) * Perfect result. @@ -284, +284 @@ If B1 were picked as base: * Candidate changes are { B1:A3 }. - * Target natural history is { B1 }; target mergeinfo is { A1 }. + * Target natural history is { B1,B2 }; target mergeinfo is { A1 }. - * 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. + * 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). @@ -293, +293 @@ 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. + + {{attachment:merge-criss-cross-3.png|criss-cross merge 3}} + + If A1 were picked as base: + + * Candidate changes are { A2, A3 }. + * Target natural history is { B1,B2 }; target mergeinfo is { A1 }. + * Notice candidate A3 can be skipped because it represents B1, as before. + * Merge just A2 to B. + + If B1 were picked as base: + + * Candidate changes are { B1:A3 }. + * Target natural history is { B1,B2 }; target mergeinfo is { A1 }. + * 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. + + So the change B2 doesn't matter. ---- = Appendices =
