subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "SymmetricMerge" by JulianFoad
Date Thu, 15 Mar 2012 16:30:20 GMT
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 =

Mime
View raw message