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 Wed, 18 Apr 2012 11:33:50 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=86&rev2=87

Comment:
More criss-cross.

   * Candidate changes are { A2, A3 }.
   * Target natural history is { B1, B2, B3 }; target mergeinfo is { A1 }.
   * Notice candidate A3 can be skipped because it represents B1, as before.
-  * Merge just A2 to B.
+  * Merge "just" A2 to B.
+  * Conflict between A2 and { B1, B2 } has to be resolved.
+  * Conflict between A2 and B1 had already been resolved in the B1 -> A3 merge, so this
part of the user's work is repetitive.
+ 
+ The two sides of the merge are A1:A2 which we can write as { A2 }, and A1:B3 which represents
original changes { B1, B2 }.  The conflict between A2 and B2 has not been resolved before,
but the conflict between A2 and B1 had already been resolved by the user during the merge
B1->A3.
+ 
+ The conflict between A2 and B1 will be broadly the same as it was  before.  It will not
be exactly the same, because  the conflicting hunks that were previously seen in B1 are now
being seen in  state B3 where they may have been modified or moved around by the subsequent
changes B2 and B3.
+ 
+ The quality of the result here can be judged by how  much conflict the merge encounters
that the user feels should not be  necessary.  If there is a lot of conflict between A2 and
B1 (perhaps B1 is a big change), the user may feel that it should not be necessary to resolve
that part of the conflict again.   If there is little conflict between A2 and B1, resolving
that again is no big deal.
  
  If B1 were picked as base:
  
@@ -523, +531 @@

   * 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.
  
- That's just like before, so the change B2 doesn't matter.
+ If O were picked as base:
+ 
+  * Candidate changes are { A1, A2, A3 }.
+  * Target natural history is { B1, B2, B3 }; target mergeinfo is { A1 }.
+  * Notice candidate A1 is already on B, and A3 represents B1, so those can be skipped.
+  * The merge would then be: base A1, source-right A2, target B4.
+ 
+ That is then the same as if we'd picked A1 as base.
  
  === Criss-Cross #4: with unmerged logical changes on both sides ===
  Let's try the same but with changes after the merges as well.
  
  {{attachment:merge-criss-cross-4.png|criss-cross merge 4}}
  
+ If A1 were picked as base:
+ 
+  * Candidate changes are { A2, A3, A4 }.
+  * Target natural history is { B1, B2, B3, B4 }; target mergeinfo is { A1 }.
+  * Notice candidate A3 can be skipped because it represents B1, as before.
+  * Merge just A2 to B.
  
  === Conclusion about Criss-Cross merges ===
  As noted above, I don't expect Subversion to solve criss-cross cases, at least I put this
at a lower priority than 3-branch merge patterns.

Mime
View raw message