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 "SvnMergeTheory" by JulianFoad
Date Tue, 07 Feb 2012 15:19:57 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "SvnMergeTheory" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SvnMergeTheory?action=diff&rev1=23&rev2=24

  
  Same dir'n -- svn succeeds.  Opposite dir'n -- svn fails.
  
- TODO: How a record-only merge ("keep-alive dance") enables another reintegrate to work.
+ == The Keep-Alive Dance ==
+ 
+ If you want to continue working on a branch after it has been reintegrated, we have been
saying that there is a choice of two solutions:
+ 
+  1. delete the branch and re-create it
+  1. do a record-only merge of the reintegrated revision
+ 
+ The latter is informally known as the "keep-alive dance".  What exactly does it do?
+ 
+ {{attachment:merge-reint-dance-sync-1.png|reintegrate and keep-alive dance}}
+ 
+ The arrow labeled "cherry" is the record-only merge.  After this, a subsequent sync merge
is broken down into two phases.  For the first phase, Subversion locates A1 as the base and
merges changes A2 and A3 into the WC.  For the second phase, Subversion locates A4 as the
base and merges A5 into the WC.
+ 
+ {{attachment:merge-reint-dance-sync-2.png|reintegrate and keep-alive dance}}
+ 
+ {{attachment:merge-reint-dance-sync-3.png|reintegrate and keep-alive dance}}
+ 
+ This is all very well, and merges the right set of logical changes, but the first phase
is not as good as it could be.  Changes A2 and A3 have already been merged with the early
part of branch B (up to B3) and the result committed as A4; that means the user has already
done any necessary conflict resolution.  It would be better to choose the younger common ancestor
B3 rather than A1 as the base of the merge, and therefore merge the change B3:A4 instead of
A1:A3, because then any conflict resolution associated with merging A:2-3 with B:2-3 has already
been done (in A4) and we'd only be concerned with merging the newer changes on A (B3:A4, A4:A5)
with the newer changes on B (B3:B5).  See "What ''Should'' Happen", below.
  
  == Unifying Sync and Reintegrate ==
- What ''should'' happen if we try to ''reintegrate'' after a ''reintegrate''?
+ What ''should'' happen when we try another merge after a ''reintegrate''?
  
  {{attachment:merge-reint-reint-1.png|svn reintegrate then reintegrate}}
  
- We would think of merging in this direction as being a ''reintegrate'', but the functionality
needed appears to be exactly what Subversion's ''sync'' merge does.
- 
- What ''should'' happen if we try to ''sync'' after a ''reintegrate''?
- 
  {{attachment:merge-reint-sync-1.png|svn reintegrate then sync}}
  
- We would think of merging in this direction as being a ''sync'', but the functionality needed
appears to be exactly what Subversion's ''reintegrate'' merge does.
+ We would call the merging direction in the first case a ''reintegrate'', and in the second
case a ''sync'', but notice that the functionality needed for the ''reintegrate'' appears
to be exactly what Subversion's ''sync'' merge does, and ''vice-versa''.  Looking more carefully
at the second case ...
  
- The point is: the 3-way merge base ''should'' be chosen according to the previous merges,
not on 'this' or 'that' branch according to whether the ''current'' merge is a reintegrate
or a sync.
+ {{attachment:merge-reint-sync-2.png|svn reintegrate then sync}}
+ 
+ ... we would want the new mergeinfo to reflect the idea that "all" the changes from the
source branch have been merged to the target, with just the same form and meaning as described
above for the basic ''reintegrate'' merge.
+ 
+ The conclusion is: to merge correctly, the 3-way merge base should be chosen on 'this' or
'that' branch according to the direction of the last merge, not according to whether the ''current''
merge is a reintegrate or a sync.
  
  == The Two Sides of a Merge ==
  TODO: Explain the idea that the result of a 3-way merge from branch A to B, committed as
B3, can be seen either as a change on B consisting of the addition of some stuff from A, or
can be seen equally validly as the change A2:B3 consisting of the merging of recent changes
on B into the context of A.  The fact that the result was committed on branch B does not matter;
the same result could have been committed on branch A, or on both branches.

Mime
View raw message