subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "SvnMergeTheory" by JulianFoad
Date Fri, 03 Feb 2012 16:56:05 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:

   * Determine the changes from A that have not yet been merged into B, according to the evidence
of B's mergeinfo.
    * 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.
+  * Finally, the user commits that WC as revision B5.
  {{attachment:merge-sync-1-svn.png|svn sync merge}}
@@ -53, +52 @@

  The main significant differences are:
   * For the 3-way merge, Subversion selects a base node that is on the ''target'' branch
rather than on the ''source'' branch.
-  * For the mergeinfo, Subversion records all the changes along the source branch (B), starting
from 'O'.  That does not accurately descibe either the set of logical changes (because B3
was not a logical change) or the set of physical changes (because B1 and B2 were not physically
merged; A2:B3 was merged instead, which is logically equivalent).
+  * For the mergeinfo, Subversion records all the changes along the source branch (B), starting
from 'O'.
+ It is interesting to consider the meaning of the mergeinfo that is recorded.  The mergeinfo
added to branch A in change A5 says that all the changes along branch B have been merged which,
loosely speaking, is correct.  But if we look carefully, that does not accurately descibe
the set of ''logical changes'' that have been merged, because B3 was not a new logical change
introduced on branch B.  B3 (if viewed as a change on B) was the merging into B of changes
A1 and A2, and we haven't tried to merge those back onto A; instead we've carefully chosen
a 3-way merge that avoided trying to re-apply them to A and just merged the ''other'' changes
from B.
+ More significantly, neither does "B:1-4" accurately describe the set of ''physical changes''
that were merged.  The physical (3-way) merge took the difference between A2 and B4, and it
isn't even possible to describe that using mergeinfo syntax.  because , because B1 and B2
were not physically merged; A2:B3 was merged instead, which is logically equivalent). Those
are the cases that Subversion 1.7 supports.
- == 3-way or 4-way Merge ==
+ == 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.
  For a ''cherry-pick'' merge, a 3-way merge is not quite right:
@@ -71, +74 @@

  == Drawing Merge Graphs ==
  The graphs in this page are constructed with the program [[|]]
from configuration files such as [[attachment:merge-reint-1.txt]].
+ === Notation ===
+ A name and number such as "A2", shown in an ellipse on the graphs, means version "2" of
branch "A".  That means the state of branch "A" in some revision of the Subversion repository;
the actual revision number is not stated.
+ Time advances from left to right along ''lines'' on the graph, both the dotted lines showing
natural history and the solid or dashed lines showing merges.  Where there is no line, no
time relationship implied: the revision number of B1 could be lower, the same or higher than
the revision number of A1, and likewise B2 could have been committed before A1.
+ In some contexts, "A1" refers to the change that describes revision A1 relative to its predecessor
along its line of natural history.  Mergeinfo syntax, for example, refers to changes in this
+ The arcs that start with a circle and end with a T-shaped bar represent the span of the
source side of the merge. The circle means "exclusive" and the bar "inclusive", in the sense
that an arc from A1 to A2 doesn't include the change associated with A1 (that is, the difference
between state A0 and state A1) and does include the change associated with A2 (the difference
between state A1 and state A2).
  {{{#!wiki comment
  The assumption is that the sync merge is one special case of merging and so can take one
set of shortcuts, while the reintegrate is another special case and can take a different approach
with its own set of restrictions and short-cuts.

View raw message