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=17&rev2=18 * 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 == + == 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. + == 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.
