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:59:37 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=62&rev2=63

Comment:
Add a second criss-cross merge graph.

  == Symmetric Merge with Criss-Cross Merge ==
  The following kind of merge history is known as a 'criss-cross' merge.
  
- {{attachment:merge-criss-cross-1.png|criss-cross merge}}
+ {{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.
  
@@ -268, +268 @@

  
  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, then ... [? such a change would
have been included in the merge to B3 ?].
+ In the general case, a criss-cross merge need not be a no-op.  Consider the following case:
  
- [TODO: graph]
+ {{attachment:merge-criss-cross-2.png|criss-cross merge 2}}
  
  If A1 were picked as base:
  
-  * Candidate changes  are { A1.5, A2 }.
+  * Candidate changes  are { A2, A3 }.
   * Target natural history is { B1 }; target mergeinfo is { A1 }.
-  * Notice candidate A2 can be skipped, as before.
+  * Notice candidate A3 can be skipped, as before.
-  * Merge just A1.5 to B.
+  * Merge just A2 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 }.
+  * Candidate changes are { B1:A3 }.
   * 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.
+  * 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).

Mime
View raw message