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=24&rev2=25 - What's the theoretical difference between 'sync', 'reintegrate' and 'cherry-pick' merges in Subversion? + What's the theoretical difference between 'sync' and 'reintegrate' merges in Subversion, and how do 'cherry-pick' merges fit in? == Playing catch-up with Sync and Reintegrate == Brane wrote: @@ -65, +65 @@ Same dir'n -- svn succeeds. Opposite dir'n -- svn fails. == The Keep-Alive Dance == - If you want to continue working on a branch after it has been reintegrated, we have been saying that there is a choice of two solutions: 1. delete the branch and re-create it @@ -98, +97 @@ The conclusion is: to merge correctly, the 3-way merge base should be chosen on 'this' or 'that' branch according to the direction of the last merge, not according to whether the ''current'' merge is a reintegrate or a sync. + == How Subversion Could Find the Youngest Merge Base == + 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. + + + + ---- + = Appendices = == The Two Sides of a Merge == TODO: Explain the idea that the result of a 3-way merge from branch A to B, committed as B3, can be seen either as a change on B consisting of the addition of some stuff from A, or can be seen equally validly as the change A2:B3 consisting of the merging of recent changes on B into the context of A. The fact that the result was committed on branch B does not matter; the same result could have been committed on branch A, or on both branches.
