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=60&rev2=61 Comment: Address some of danielsh's comments == 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. - Considering the final merge in the "sync after reintegrate" graph above, we have: + Considering the final merge in the "sync after reintegrate" graph (repeated from above), we have: * mergeinfo on A5, saying "B:1-3" * mergeinfo on B5, saying "A:1" + [[attachment:merge-reint-sync-1.png]] + The longest continuous prefix of branch A that's fully merged into B is A:1. The longest continuous prefix of B merged to A is B:1-3. We look for a continuous prefix because we need to ignore any later revisions that may have been cherry-picked, after a gap, because in that case it's this first gap that is what we need to be filling first. Youngest common ancestor (w.r.t. complete merging of the branches) is B3, so that's the 3-way base to use. @@ -212, +214 @@ To express it as an algorithm: 1. Find the latest revision of A synced to B and the latest revision of B synced to A. - * The latest revision of A synced to B doesn't mean the last time a merge was performed, but rather the youngest revision 'rA' on A at which all changes on A up to rA are now included in B. [[danielsh: does this mean "the maximum N such that all revisions of A, up to and including rN, have been merged into B?]] - * We consider only direct A <-> B mergeinfo. (Consideration of a merge graph extending to other branches is future work.) [[danielsh: Okay, but I thought we currently record mergeinfo transitively, so considering only direct A<->B mergeinfo suffices for some 3-branch scenarios too?]] + * This means, for the A to B direction, the youngest revision 'rN' on A at which all revisions of A, up to and including rN, are now recorded as having been merged into B. And "now recorded" means recorded in the version of B that is being used as the merge target. Usually the result corresponds to the most recent merge into B from A, but not necessarily, because later revisions from A might previously have been cherry-picked into B. + * We consider only direct A <-> B mergeinfo. (Consideration of a merge graph extending to other branches is future work. Since we record mergeinfo transitively, considering only direct A<->B mergeinfo already suffices for some 3-branch scenarios too, but not all such scenarios.) 1. Choose a base. * Choose the latest revision of A synced to B or the latest revision of B synced to A. * Each candidate base is a common ancestor of the source and target, if ancestry means following either the direct line of descent or the arrows that indicate complete merges. @@ -222, +224 @@ 1. Identify cherry-picks. * Find changes along the source side of the merge that are already 'in' the target. * Look for mergeinfo in both directions - * Past merges from source to target ("forward"): treat them as cherry-picks. + * Past merges from source to target ("forward"): treat them as cherry-picks. - * Past merges from target to source ("backward"): if a revision 150 on the source merges a revision 100 from the target, (Q: what to do exactly? We want to ignore the part that merges r100, but if r150 also merged r120 from an unrelated branch we do want to merge ''that'' part) + * Past merges from target to source ("backward"): if a revision 150 on the source merges a revision 100 from the target, (Q: what to do exactly? We want to ignore the part that merges r100, but if r150 also merged r120 from an unrelated branch we do want to merge ''that'' part) * If a change is partly in the target, consider reporting it and aborting. 1. Break into 3-way merges, skipping the cherry-picks. 1. Mergeinfo addition.
