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] Trivial Update of "SymmetricMerge" by DanielShahaf
Date Thu, 15 Mar 2012 17:14:25 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 DanielShahaf:
http://wiki.apache.org/subversion/SymmetricMerge?action=diff&rev1=69&rev2=70

Comment:
criss-cross += subheaders

  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 ==
+ 
+ === Criss-Cross #1: Minimal ===
+ 
  The following kind of merge history is known as a 'criss-cross' merge.
  
  {{attachment:merge-criss-cross-1.png|criss-cross merge 2}}
@@ -267, +270 @@

   * 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.
+ 
+ === Criss-Cross #2: With unmerged logical changes on the sourcew ===
  
  In the general case, a criss-cross merge need not be a no-op.  Consider the following case:
  
@@ -292, +297 @@

  
  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.  Let's try
the same but with a change in B as well.
+ It seems like there must be more complex cases in which neither base will work.
+ 
+ === Criss-Cross #3: with unmerged logical changes on both sides ===
+ 
+ Let's try the same but with a change in B as well.
  
  {{attachment:merge-criss-cross-3.png|criss-cross merge 3}}
  
@@ -311, +320 @@

   * Bail out, telling the user there's a problem.
  
  That's just like before, so the change B2 doesn't matter.
+ 
+ === Conclusion about Criss-Cross merges ===
  
  Can we define the base-choosing algorithm so that it always picks the "good" base when there
is one?  The last rev on A synced to B is A1, and the last rev on B synced to A is B1.  Normally,
we'd expect either B1 to be >= the target of the A1->B merge, or vice versa.  But neither
is the case here; that's more or less what defines this as a criss-cross.  There's something
special going on, so the presence of change A2 makes a base on the source branch succeed whereas
a base on the target branch fails.  We perhaps just need to codify that "something special"
-- some rule that says which base to consider the "better one" depending on the relative ages
of ... A1, B1, A3, B3, and A2.
  

Mime
View raw message