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 11:56:47 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=22&rev2=23

  
  Those are the basic cases that Subversion 1.7 supports.
  
- TODO: How sync works after a reintegrate.
- 
  TODO: How Subversion handles cherry-picks in the direction of sync merges.
  
  Same dir'n -- svn succeeds.  Opposite dir'n -- svn fails.
@@ -69, +67 @@

  TODO: How a record-only merge ("keep-alive dance") enables another reintegrate to work.
  
  == Unifying Sync and Reintegrate ==
+ What ''should'' happen if we try to ''reintegrate'' 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.
- What ''should'' happen if we try to ''reintegrate'' after a ''reintegrate''?
- 
- {{attachment:merge-reint-reint-1.png|svn reintegrate then reintegrate}}
  
  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.
  
  == 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 mergeing 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.
+ 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.
  
  == Cherry pick: 3-way or 4-way Merge ==
  Subversion currently performs any requested merge as a sequence of 3-way merges.  For simple
''sync'' and ''reintegrate'' merges, that's exactly what's needed.  Usually there is just
one 3-way merge, but if cherry-picks are being skipped then Subversion breaks down the merge
source range into sub-ranges and performs one 3-way merge per sub-range.

Mime
View raw message