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 "SvnMergeTheory" by JulianFoad
Date Tue, 31 Jan 2012 12:11:23 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=6&rev2=7

  }}}
  Let's examine how Subversion performs a sync merge and how it performs a reintegrate merge.
  
- 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).
+ In the following example, two sync merges are shown.  Let's jump straight to examining the
second one.  (The first one is just a simpler case of the same thing.)
  
  {{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.
+  * Find the common ancestor of A and B (just following the plain lines of descent, ignoring
merges).
+   * That's state 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.
+  * Consider all the changes along the history of branch A, after the common ancestor O up
to and including A4.
+   * That's changes A1, A2, A3, A4.
-  * Looked at B's mergeinfo, to see what has already been merged from A. It says A1 and A2.
+  * Look at B's mergeinfo, to see what has already been merged from A.
+   * That's changes 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.
+  * Determine the changes from A that have not yet been merged into B, 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).
+   * That's changes A3 and A4.
+  * Perform a 3-way merge of A3 and A4 into B (actually into the WC based on B4).  The base
of the 3-way merge is the predecessor of change A3, which is A2.
  
  And then the user committed that WC as revision B5.
  
@@ -46, +50 @@

  
  {{attachment:merge-reint-1.png|svn sync merge}}
  
- The only significant difference is that Subversion selects a base node that is on the ''target''
branch rather than on the ''source'' branch.
+ The main significant difference is that Subversion selects a base node that is on the ''target''
branch rather than on the ''source'' branch.
+ 
+ But what's the mergeinfo? [TODO...]
+ 
+ 
  
  == 3-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.

Mime
View raw message