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 Mon, 30 Jan 2012 18:11:17 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=1&rev2=2

  What's the theoretical difference between 'sync', 'reintegrate' and 'cherry-pick' merges
in Subversion?
  
  == Playing catch-up with Sync and Reintegrate ==
- 
  Brane wrote:
  
+ {{{
  When you create a branch, the origin of the branch is an interesting bit of information.
However, for merging, it is entirely irrelevant if branch A was created from B or the other
way around. To illustrate:
  
- {{{
      (1)
                 +- b@r2 ---- b@r3 ----
       (branch) /              | (merge)
@@ -20, +19 @@

               \               | (merge)
       (branch) \              v
                 +- b@r2 ------+- b@r4 ----
+ 
+ Cases (1) and (2) are exactly equivalent as far as the merge algorithm is concerned, but
Subversion calls the first a reintegrate merge and the second a sync merge, and treats them
differently, as if branch (a) were somehow special. It's not.
  }}}
+ Let's examine how Subversion performs a sync merge and how it performs a reintegrate merge.
  
- Cases (1) and (2) are exactly equivalent as far as the merge algorithm
- is concerned, but Subversion calls the first a reintegrate merge and the
- second a sync merge, and treats them differently, as if branch (a) were
- somehow special. It's not.
- -- Brane
+ In the following example, two sync merges are shown.  Let's jump straight to examining the
second one.  (It is easy to see how the first one was performed).
+ 
+ {{attachment:merge-sync-1-req.png|requested sync merge}} To perform the second sync merge
(before it was committed as revision B5), Subversion:
+ 
+  * Found the common ancestor of A and B, which is point O on the diagram.
+  * Considered all the changes along the history of branch A, after the common ancestor O
up to and including A4. The changes are: A1, A2, A3, A4.
+  * Looked at B's mergeinfo, to see what has already been merged from A. It says A1 and A2.
+  * Determined that the changes from A that have not yet been merged into B are A3 and A4,
according to the evidence of B's mergeinfo.
+  * Performed a 3-way merge, using A2 as the base, from A4 into B (actually the WC based
on B4).
+ 
+ And then the user committed that WC as revision B5.
+ 
+ {{attachment:merge-sync-1-svn.png|svn sync merge}}
+ 
+ (The arcs that start with a circle and end with a T-shaped bar represent the span of the
source side of the merge.)
+ 
+ == 3-way merge ==
+ {{{#!wiki comment
+ 
+ Subversion performs a requested merge as a sequence of 3-way merges.
  
  
- {{attachment:merge-sync-1-req.png|basic sync merges}}
- 
- == 3-way merge ==
- 
- 
- 
- {{{#!wiki comment
- 
- Subversion performs a requested merge as a sequence of 3-way merges.  For example, in a
simple 'sync' merge such as the second one in <merge-sync-1-req.png> [1], Subversion
determines that all the source changes up to A2 are already merged, so the source side of
the merge is changes A2:A4 (aka A:3-4 in mergeinfo syntax), as shown in <merge-sync-1-svn.png>.
 On that diagram, the arcs that start with a circle and end with a T-shaped bar represent
the span of the source side of the merge.
  
  What Subversion actually does is it looks along the (direct) history of the source branch
(A), and finds the first contiguous range of revisions along the history of A that haven't
  
@@ -48, +56 @@

  
  I believe you're quite right in saying that our reintegrate and sync merges are restricted
versions of a single general merge, iff we're talking about merging patterns that consist
only of sync and reintegrate merges.
  
- Remember that ClearCase doesn't track cherry-pick merges [2]. 
+ Remember that ClearCase doesn't track cherry-pick merges [2].
  
  
  
@@ -75, +83 @@

    [1] I've just been writing a merge graph drawing program to help produce diagrams like
this. Attached as 'merge-graph-v2.py'.
  
    [2] ClearCase can perform a cherry-pick merge, and may even be able to record some metadata
about it, but (as far as I can discover) the merge algorithm doesn't take account of cherry
picks when working out what needs to be merged.  Git is similar; from what I read recently
it has an extension that can perform a cherry-pick merges and  store cherry-pick metadata
somewhere and use it to track cherry picks when using that extension -- but the metadata is
completely separate from the fundamental merge DAG, and AFAIK the standard merges don't recognize
and account for cherry picks.
- 
  }}}
  

Mime
View raw message