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=84&rev2=85 In more detail. 1. Find the latest revision of A synced to B and the latest revision of B synced to A. - * 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.) + + * TODO: If, in a later phase of development, we're going to examine indirect mergeinfo for detection of cherry picks, then probably we also need to do so here. {{{ In: A_tip: pathrev @@ -266, +267 @@ (Note: B is a WC "actual" tree including any local mods.) Out: - A_base: pathrev - B_base: pathrev + A_base: pathrev # last location on A that's fully sync'd to B + A_to_B: pathrev # location on B where became fully sync'd from A + B_base: pathrev # last location on B that's fully sync'd to A + B_to_A: pathrev # location on A where became fully sync'd from B - (Note: B_base can't possibly be B if B has local mods.) + (Note: B_base can't possibly be B_wc if B_wc has local mods, + because that modified version can't have been merged to A + because we can only merge committed changes. A_to_B, on the + other hand, probably can be B_wc so perhaps its data type + can't be strictly a pathrev.) Implementation: Currently: @@ -277, +284 @@ TODO: fill in the details here and re-visit the implementation. }}} - 2. Choose a base. + 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. @@ -286, +292 @@ * Choose the 'more recent' one in some sense -- be it time of commit, or number of changes since then, or some other measure. * [TODO] In what cases do the selection methods give different results? Only after a criss-cross merge? + + * TODO: Compare A_base.rev with B_base.rev only, or compare also A_to_B with B_to_A? {{{ In: - A_base: pathrev + A_base + A_to_B - B_base: pathrev + B_base + B_to_A Out: - base: pathrev + base: pathrev # A_base or B_base + mid: pathrev # A_to_B or B_to_A Implementation: Currently, in find_symmetric_merge(): (A_base->rev > B_base->rev) ? A_base : B_base }}} - 3. Identify cherry-picks. + 1. Identify cherry-picks. - * Find changes along the source side of the merge that are already 'in' the target. * Look for merges in both directions (from current source to current target ("forward") and from current target to current source ("backward")). For each merge: - - * Break down the merge into its component logical changes. + * Break down the merge into its component logical changes. - * If the merge consists entirely of logical changes that are not in the target, or consists entirely of logical changes that are in the target, treat it as a unit -- a cherry pick. + * If the merge consists entirely of logical changes that are not in the target, or consists entirely of logical changes that are in the target, treat it as a unit -- a cherry pick. - * Otherwise, fall back to the user: report to the user which logical changes that merge includes, and suggest that the user run more specific merges that pull only the subset of logical changes they want. + * Otherwise, fall back to the user: report to the user which logical changes that merge includes, and suggest that the user run more specific merges that pull only the subset of logical changes they want. + 3a. (Only needed for implementation phase 2.) Create an (implicit or explicit) list of indivisible changes along each side of the merge, since the BASE. - - 3a. Create an (implicit or explicit) list of indivisible changes - along each side of the merge, since the BASE. {{{ For example: @@ -325, +332 @@ In: base + mid A_tip B_wc @@ -351, +359 @@ revisions (or ranges of revs) that are not all known to be operative? }}} - 3b. Discover the changes from A that have been merged to B since BASE. {{{ In: @@ -407, +414 @@ A change onto A_changes_to_warn. }}} - 4. Break into 3-way merges, skipping the cherry-picks. + 1. Break into 3-way merges, skipping the cherry-picks. {{{ Implementation: @@ -422, +429 @@ # elide either or both of those if they are no-ops }}} - 5. Perform the 3-way merges and mergeinfo addition. + 1. Perform the 3-way merges and mergeinfo addition. {{{ Implementation:
