subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "SymmetricMerge" by JulianFoad
Date Thu, 15 Mar 2012 13:52:02 GMT
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.

Mime
View raw message