[Subversion Wiki] Update of "SymmetricMerge" by JulianFoad

[Apache subversion Wiki <co...@subversion.apache.org>]

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=51&rev2=52

Comment:
Add a criss-cross merge section, in response to a question from Daniel Shahaf.

  {{{#!wiki comment
  [danielsh] State here briefly the reasons we may want to move towards that model?
  }}}
- 
  === Abstract ===
  The essence of this document is that it looks like we can relatively easily  enhance Subversion so that a plain 'merge' command will act as either  'sync' or 'reintegrate' automatically, depending on the history of the  branch, and furthermore will work better than either of them in the  scenario of continuing work on a branch after a reintegrate.
  
@@ -216, +215 @@

  
  [TODO] Express it as an algorithm.
  
- {{{#!wiki comment
+ == Symmetric Merge with Cherry-Picks ==
+ Next,  we need to account for cherry-picks.  If there are cherry-picks from  the source [...], we look for the end of the first gap.  [TODO...]
+ 
+ == Symmetric Merge with Criss-Cross Merge ==
  [danielsh] How does the algorithm cope with the following history: O - common parent; A1 - text change; B1 - text change; A2 - merge of B1 to A; B2 - merge of A1 to B; and being asked to merge A into (a working copy of) B?
- }}}
  
- == Symmetric Merge with Cherry-Picks ==
- Next, we need to account for cherry-picks.  If there are cherry-picks from the source [...], we look for the end of the first gap.  [TODO...]
+ [TODO] Graph
+ 
+ First we pick a base according to whatever rule we decided.  It could be A1 or B1.
+ 
+ If we pick base A1:
+ 
+  * Notice A2 is a 'cherry-pick', because it represents a logical change (B1) that is already 'on' the target branch.
+  * Skip A2 from the source ranges.
+  * Perfect result.  (In this case, no-op.)
+ 
+ If we pick base A2:
+ 
+  * Notice B1:A2 (the first change on the source side of the merge) is a 'cherry-pick', because it represents a logical change (A1) that is already 'on' the target branch.
+  * Skip B1:A2 from the source ranges.
+  * 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.
  
  ----
  = Appendices =