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 Mon, 06 Feb 2012 14:59:43 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=16&rev2=17

   * 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'.
  
- 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.
+ 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 the mergeinfo "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, which we can describe as A2:B3 followed by B3:B4.  The second part (B3:B4) we can descibe
in mergeinfo syntax as "B:4".  The first part, A2:B3, we can't describe using mergeinfo syntax.
 Logically it's equivalent to changes B1 and B2, but it's not physically the same, because
A2:B3 is the rewriting of B1 and B2 into the context of branch A.  (See ''The Two Sides of
a Merge'', below, for clarification.)
  
@@ -69, +69 @@

  TODO: How a record-only merge ("keep-alive dance") enables another reintegrate to work.
  
  == Unifying Sync and Reintegrate ==
- 
  == 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