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=75&rev2=76 Comment: Start writing up subtree merges. 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|The Two Sides of a Merge]], below, for clarification.) + + == Subtree Merges == + This section sets out how Subversion should perform a merge when a subtree of the merge source and/or target has its own mergeinfo that differs from the mergeinfo that it would otherwise inherit from its parent directory. In other words, the set of revisions of this subtree that have been merged differs from the set of revisions of its parent directory that have been merged. + + === The Principle === + Each subtree should be considered separately in terms of calculating what needs to be merged. + + We break down the whole merge into phases (revision ranges) and we complete each phase across all subtrees before moving on to the next phase. + + === The Rationale === + In a ''complete merge'', the user is always asking Subversion to merge all of the changes (up to a given limiting revision) that have not already been merged. We should not omit unmerged changes in a subtree just because they lie outside the revision ranges that need to be merged for the root of the merge. + + Why do we complete a revision-range phase across all subtrees before moving to the next phase? The main alternative would be to merge each subtree in the minimum number of possible steps. Advantages: A logical single-revision tree state after each phase -- may help if conflict resolution needed, as user will have a consistent reference base across the tree. We stop after a phase if there are any unresolved conflicts. Disadvantages: Any merges can conflict more if broken into phases than if applied in one go. + + === The Details === + For a given merge request (from a source URL at a given revision to a target WC), apply that same request separately to each subtree. In principle, that means every subtree in the tree. In implementation, we can first work out which subtrees will need a different set of merges, and then treat just those subtrees specially. + + The merge required for a subtree might have its base after or before the base of the parent's merge. It might even have its base on the opposite branch from the parent's merge. == Cherry-pick Merges == [Note: This section is rather long, and should be considered more as reference material than an introduction, as it aims to set out all the possible cases.]
