[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 4329]  automatic merge uses reintegrate type merge if source is fully synced
From:       pburba () tigris ! org
Date:       2013-03-20 21:36:41
Message-ID: 20130320213641.AE25B690001 () sc157-tigr ! sjc ! collab ! net
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=4329






------- Additional comments from pburba@tigris.org Wed Mar 20 14:36:41 -0700 2013 -------
I've attached a proposed patch and log message for a potential fix for this
issue (id=1269) and (id=1270) respectively.

Julian has asked me what this change means for the symmetric merge algorithm
(described here
http://wiki.apache.org/subversion/SymmetricMerge#Symmetric_Merge_Algorithm). 
The high level algorithm is this:

Given two ancestrally related branches A and B, which may have had any number of
syncs, cherrypicks, and subtree merges between them, we attempt an auto merge
from A to B:

        /---A---------------------------------
       /       \  /            \
      /       sync, cherry      \
---yca     and subtree merges   auto merge
      \        /  \               \
       \      /    \               \
        \---B-----------------------?---------

[[[
This algorithm provides a symmetric merge with skipping of source revisions that
have already been cherry-picked to the target branch.

    1. Find the latest rev of A synced to B and of B synced to A.
    2. Choose a base.
    3. Identify cherry-picks.
    4. Break into 3-way merges, skipping the cherry-picks.
    5. Perform the 3-way merges and mergeinfo addition.

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.)
]]]

My patch adjusts the two bullet points of step 1 to the following:

        * 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:

            i) 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.

            ii) 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).
  
            iii) rX is inoperative on A.  

        * 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.)

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=3051565

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]