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}}
