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=22&rev2=23 Those are the basic cases that Subversion 1.7 supports. - TODO: How sync works after a reintegrate. - TODO: How Subversion handles cherry-picks in the direction of sync merges. Same dir'n -- svn succeeds. Opposite dir'n -- svn fails. @@ -69, +67 @@ TODO: How a record-only merge ("keep-alive dance") enables another reintegrate to work. == Unifying Sync and Reintegrate == + What ''should'' happen if we try to ''reintegrate'' after a ''reintegrate''? + + {{attachment:merge-reint-reint-1.png|svn reintegrate then reintegrate}} + + We would think of merging in this direction as being a ''reintegrate'', but the functionality needed appears to be exactly what Subversion's ''sync'' merge does. + What ''should'' happen if we try to ''sync'' after a ''reintegrate''? {{attachment:merge-reint-sync-1.png|svn reintegrate then sync}} + We would think of merging in this direction as being a ''sync'', but the functionality needed appears to be exactly what Subversion's ''reintegrate'' merge does. - What ''should'' happen if we try to ''reintegrate'' after a ''reintegrate''? - - {{attachment:merge-reint-reint-1.png|svn reintegrate then reintegrate}} The point is: the 3-way merge base ''should'' be chosen according to the previous merges, not on 'this' or 'that' branch according to whether the ''current'' merge is a reintegrate or a sync. == 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 mergeing 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. + 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. == 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.
