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

Merge order affects final result for repeated added & deleted changes

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.8.x
    • Fix Version/s: ---
    • Component/s: libsvn_client
    • Labels:
      None
    • Environment:

      Windows 7

      Description

      There seems to be a problem with the merge logic in SVN when merging
      repeated added & deleted changes out-of-order.
      
      Example activity on branch A:
      r1: A new file is added.
      r2: A line is added
      r3: The line is removed
      r4: The line is re-added
      Later activity on branch B (created from A_at_r1):
      r5: r2 and r4 are merged in.
      r6: r3 is merged in.
      
      What happens in r5 is that repeated merging of the same change does _not_
      cause duplication or merge conflict. Instead, r4 seems to be ignored. The
      end result after r6 (a complete merge) is that r4 is missing from branch B.
      This is inconsistent with svn:mergeinfo which claims that it has been
      merged. Patches to reproduce are attached to the mail-list URLs.
      
      Could it be possible to make svn merges fail on repeated merges of the same
      change, instead of just ignoring them?
      
      The problem was reproduced using svn 1.8.1 (command-line) client on Win7
      64bit SP1, and svn server 1.7.6 (VisualSVN 2.5.6, Apache 2.2.22) on Win
      server 2008 R2.
      
      Related discussions on dev@svn:
      http://svn.haxx.se/dev/archive-2013-04/0205.shtml
      

      http://svn.haxx.se/users/archive-2013-08/0049.shtml

      Original issue reported by forderud

      1. 1_test_patches.txt
        0.7 kB
        Subversion Importer
      2. 2_merge_tests.py2.patch
        2 kB
        Subversion Importer

        Activity

        Hide
        julianfoad Julian Foad added a comment -

        This behaviour is one of several trade-offs that have historically been made in
        favour of convenience for some (loosely controlled) work flows, where more
        strictness would be better for other (tightly controlled) work flows. More
        details of the convenience trade-offs can be read in my email to dev@ on
        2013-04-11, subject "Re: Merge bug causes changesets to be applied although this
        should not be the case", <http://svn.haxx.se/dev/archive-2013-04/0261.shtml>
        which is within the thread linked in #desc1.
        
        Behaviour like this is present not only in Subversion's text merge but also in
        many third-party text merge tools. On the other hand, surely some of them offer
        strict detection. You can work around this issue by plugging in a three-way text
        merge tool that provides the desired strict conflict detection if you have one.
        
        I agree that it would be good to enhance Subversion's merge to provide some
        control over the specific kinds of change that are marked as conflicts, or over
        the general level of strictness in merging.
        
        

        Show
        julianfoad Julian Foad added a comment - This behaviour is one of several trade-offs that have historically been made in favour of convenience for some (loosely controlled) work flows, where more strictness would be better for other (tightly controlled) work flows. More details of the convenience trade-offs can be read in my email to dev@ on 2013-04-11, subject "Re: Merge bug causes changesets to be applied although this should not be the case", <http://svn.haxx.se/dev/archive-2013-04/0261.shtml> which is within the thread linked in #desc1. Behaviour like this is present not only in Subversion's text merge but also in many third-party text merge tools. On the other hand, surely some of them offer strict detection. You can work around this issue by plugging in a three-way text merge tool that provides the desired strict conflict detection if you have one. I agree that it would be good to enhance Subversion's merge to provide some control over the specific kinds of change that are marked as conflicts, or over the general level of strictness in merging.
        Hide
        subversion-importer Subversion Importer added a comment -

        Attachment 2_merge_tests.py2.patch has been added with description: Patch for failing XFAIL test (2nd revision)

        Show
        subversion-importer Subversion Importer added a comment - Attachment 2_merge_tests.py2.patch has been added with description: Patch for failing XFAIL test (2nd revision)
        Hide
        subversion-importer Subversion Importer added a comment -

        Created an attachment (id=1285)
        Patch for failing XFAIL test (2nd revision)
        
        

        Original comment by forderud

        Show
        subversion-importer Subversion Importer added a comment - Created an attachment (id=1285) Patch for failing XFAIL test (2nd revision) Original comment by forderud
        Hide
        subversion-importer Subversion Importer added a comment -

        Attachment 1_test_patches.txt has been added with description: Patches to reproduce

        Show
        subversion-importer Subversion Importer added a comment - Attachment 1_test_patches.txt has been added with description: Patches to reproduce
        Hide
        subversion-importer Subversion Importer added a comment -

        Created an attachment (id=1284)
        Patches to reproduce
        
        

        Original comment by forderud

        Show
        subversion-importer Subversion Importer added a comment - Created an attachment (id=1284) Patches to reproduce Original comment by forderud

          People

          • Assignee:
            Unassigned
            Reporter:
            subversion-importer Subversion Importer
          • Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development