Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-4255

Automatic merge ignores some cherry-picks, causing conflicts

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: trunk
    • Fix Version/s: unscheduled
    • Component/s: libsvn_client
    • Labels:
      None

      Description

      A 'sync' automatic merge (that is, an automatic merge in the same direction as
      the previous one) correctly skips source revisions that have been cherry-pick
      merged to the target.  However, it does not correctly account for any target
      revisions that have been cherry-pick merged to the source.
      
      In the following diagrams, 'o' is an original change, 'x' is a full merge, 'c'
      is a cherry-pick merge.
      
      Example Cherry1:
      
        #   A (--o------o--[o]----o---
        #     (     \         \     \
        #   B (---o--x---------c-----x
        #     2  34  5  67  8  9 10 11
      
      In example 'Cherry1', revision 8 on the source branch A has been cherry-pick
      merged to the target branch B.  The final automatic merge (A10 -> B11) correctly
      avoids re-merging change A8.
      
      Example Cherry2:
      
        #   A (--o-------------c--o---
        #     (     \         /     \
        #   B (---o--x---o-[o]-------x
        #     2  34  5  67  8  9 10 11
      
      In example 'Cherry2', revision 8 on the target branch B has been cherry-pick
      merged to the source branch A.  The final automatic merge (A10 -> B11) does not
      work correctly: it includes A9 in the set of changes being merged, and because
      the change represented in A9 has already been made on the target branch (in B8),
      this re-applies the equivalent change to B which creates conflicts.
      
      Example Cherry3:
      
        #   A (--o--------------c--o----
        #     (          \     /     \
        #     (           \   /       \
        #   B (---o--o-[o]-x-/---------x
        #                \__/
        #     2  34  5  6  7    8  9  10
      
      In example 'Cherry3', the topology is different but the behaviour is the same as
      in example 'Cherry2'.
      
      This has been the case from version 1.5 (when merge tracking was introduced) to
      the current 1.8-dev state of trunk.
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                julianfoad Julian Foad
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: