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 15:33:35 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=61&rev2=62

Comment:
Criss-cross merge: corrections to danielsh's edits, and further expansion.

  
  If we pick base A1:
  
+  * Candidate changes  are { A2 }.
+  * Target natural history is { B1 }; target mergeinfo is { A1 }.
-  * Notice A2 is a 'cherry-pick', because it represents a logical change (B1) that is already
'on' the target branch.
+  * 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".)
-  * Perfect result.  (In this case, no-op: A1:A2 minus A2.)
+  * Perfect result.  (In this case, no-op.)
  
  If we pick base B1:
  
-  * Notice B1:A2 (the first change on the source side of the merge) is a 'cherry-pick', because
it represents a logical change (B1) that is already 'on' the target branch.
+  * Candidate changes  are { B1:A2 }.
+  * Target natural history is { B1 }; 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".)
-  * Perfect result.  (In this case, no-op: B1:A2 minus A2.)
+  * 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 B1.
+ 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, such a change would have been
included in the merge to B3.  If A1 were picked as base then such A1.5 would have been included
in the merge ranges.  If B1 were picked as base, [[TODO: would A1.5 have been included too?]]
+ 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 ?].
+ 
+ [TODO: graph]
+ 
+ If A1 were picked as base:
+ 
+  * Candidate changes  are { A1.5, A2 }.
+  * Target natural history is { B1 }; target mergeinfo is { A1 }.
+  * Notice candidate A2 can be skipped, as before.
+  * Merge just A1.5 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 }.
+  * 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.
+  * 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).
+ 
+ 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.
  
  ----
  = Appendices =

Mime
View raw message