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 "SymmetricMerge" by JulianFoad
Date Fri, 16 Mar 2012 10:24:41 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "SymmetricMerge" page has been changed by JulianFoad:
http://wiki.apache.org/subversion/SymmetricMerge?action=diff&rev1=74&rev2=75

Comment:
Say 'V1.7' instead of 'currently' or 'today'.

  === Abstract ===
  The essence of this document is that it looks like we can relatively easily  enhance Subversion
so that a plain 'merge' command will act as either  'sync' or 'reintegrate' automatically,
depending on the history of the  branch, and furthermore will work better than either of them
in the  scenario of continuing work on a branch after a reintegrate.
  
- We explain how Subversion performs ''sync'' and ''reintegrate'' merges, expressing the results
in terms of copying ''logical changes'' from one branch to another.  We compare this with
the way a ''symmetric'' merge would handle the same cases, and we see how the ''symmetric''
merge can handle a much bigger set of useful cases.  We also show how previous ''cherry-pick''
merges are currently handled and how they would be handled by a symmetric merge.
+ We explain how Subversion performs ''sync'' and ''reintegrate'' merges, expressing the results
in terms of copying ''logical changes'' from one branch to another.  We compare this with
the way a ''symmetric'' merge would handle the same cases, and we see how the ''symmetric''
merge can handle a much bigger set of useful cases.  We also show how previous ''cherry-pick''
merges are handled in V1.7 and how they would be handled by a symmetric merge.
  
  In particular, we show the limitations of using the so-called ''keep-alive dance'' after
reintegrating a branch, and we show how much better the symmetric merge is in this scenario.
  
- We start to develop the ''symmetric merge'' as an algorithm which can be implemented in
Subversion using the current, existing mergeinfo.  It should be suitable for replacing both
the ''sync'' and ''reintegrate'' algorithms, because it performs as a backward-compatible
upgrade for each of them.
+ We start to develop the ''symmetric merge'' as an algorithm which can be implemented in
Subversion using the existing V1.7 mergeinfo.  It should be suitable for replacing both the
''sync'' and ''reintegrate'' algorithms, because it performs as a backward-compatible upgrade
for each of them.
  
  === Background on 3-way merging ===
  The following sections assume that the reader understands how the diff3 algorithm works.
The diff3 algorithm is used to perform a merge between an original version of a file and two
different versions of the file, each derived from the original version (in Subversion, the
derived versions are often referred to as "mine" and "theirs"). This paper provides an explanation
and an analysis of the diff3 algorithm: http://www.cis.upenn.edu/~bcpierce/papers/diff3-short.pdf
@@ -138, +138 @@

  {{attachment:merge-cherry2-sync-4.png|Cherry-Pick 2 and Sync Again}}
  
  === Cherry-Pick 3 and Sync Again (Merge in Same Direction) ===
- Just like "Cherry-Pick 2 and Sync Again", Subversion currently does not notice the cherry-pick
in this case, and what ''should'' happen is it should break the merge into two phases.
+ Just like "Cherry-Pick 2 and Sync Again", Subversion V1.7 does not notice the cherry-pick
in this case, and what ''should'' happen is it should break the merge into two phases.
  
  === Cherry-Pick 1 and Reintegrate (Merge in Opposite Direction) ===
  [??? Need to check this] Subversion's ''reintegrate'' doesn't recognize cherry-picked revisions
in either direction.  It looks specifically for the last ''complete'' catch-up.
@@ -146, +146 @@

  {{attachment:merge-cherry1-reint-1.png|Cherry-Pick 1 and Reintegrate}}
  
  === Cherry-Pick 2 and Reintegrate (Merge in Opposite Direction) ===
- Just like "Cherry-Pick 2 and Sync Again", Subversion currently does not notice the cherry-pick
in this case, and what ''should'' happen is it should break the merge into two phases.
+ Just like "Cherry-Pick 2 and Sync Again", Subversion V1.7 does not notice the cherry-pick
in this case, and what ''should'' happen is it should break the merge into two phases.
  
  === Cherry-Pick 3 and Reintegrate (Merge in Opposite Direction) ===
- Like "Cherry-Pick 2 and Sync Again", Subversion currently does not notice the cherry-pick
in this case.
+ Like "Cherry-Pick 2 and Sync Again", Subversion V1.7 does not notice the cherry-pick in
this case.
  
  What ''should'' happen, however, is more complex.  The cherry-pick logical change (B3) is
not one of the changes we were planning to merge.  The first change we're planning to merge
is A1:B4, which represents three logical changes (B2, B3, B4).  We're not going to attempt
to take part of that first physical change (A1:B4), so our options are to complain to the
user, or to go ahead and accept that part of what we're merging is already on the target.
  
@@ -197, +197 @@

  We call the result a ''symmetric merge'' algorithm.
  
  == The Symmetric Merge Algorithm ==
- Today we have ''sync'' which looks for a base on the source branch, and ''reintegrate''
which looks for a base on the target branch.  What we need is a single algorithm that finds
the most recent base, on either branch.  Like the current ''reintegrate'', it needs to choose
a base for the 3-way merge, and potentially a different base (this one always on the source
branch) for the mergeinfo to be recorded.
+ In V1.7 we have ''sync'' which looks for a base on the source branch, and ''reintegrate''
which looks for a base on the target branch.  What we need is a single algorithm that finds
the most recent base, on either branch.  Like the V1.7 ''reintegrate'', it needs to choose
a base for the 3-way merge, and potentially a different base (this one always on the source
branch) for the mergeinfo to be recorded.
  
  Considering the final merge in the "sync after reintegrate" graph (repeated from above),
we have:
  
@@ -349, +349 @@

  Looking from this "side" of the merge, the change B2:A3, which is the difference between
B2 and A3, consists of the addition of change A2 (strictly, O:A2) into the content of B2.
  
  === Symmetry ===
- 
  The merge is combining changes from both branches into one result, and, in principle, the
merge process need not care which branch the result is destined for: the very same resulting
tree of files and directories could equally well be produced by a merge in the other direction,
from branch A to branch B:
  
  {{attachment:merge-two-sides-2.png|Merge Two Sides 2}}

Mime
View raw message