[Subversion Wiki] Update of "SymmetricMerge" by pburba

[Apache subversion Wiki <co...@subversion.apache.org>]

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 pburba:
http://wiki.apache.org/subversion/SymmetricMerge?action=diff&rev1=96&rev2=97

Comment:
Update symmetric merge algorithm to reflect changes made in r1464102

  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.
+   * 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, have effectively been merged into B.  "Effectively...merged" means that one of the following is true for every revision X on A, where X <= rN:
+    * The merge of rX from A -> B is recorded in the mergeinfo on 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.
+    * The merge of rX from Subtree-of-A -> Subtree-of-B is recorded in the subtree mergeinfo on the version of B that is being used as the merge target *and* rX is operative only within Subtree-of-A (i.e. the subtree merge of rX, if repeated at the root of A <-> B would be inoperative except for mergeinfo changes).
+    * rX is inoperative on A.
  
-   * 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.)
+   * We consider only direct A <-> B mergeinfo (including subtree mergeinfo under A or B). (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.
   {{{