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

Merging a change from a path's natural history creates self-referential mergeinfo

    XMLWordPrintableJSON

    Details

      Description

      If we merge a change to a path from that path's own natural history the merge
      tracking logic prevents the merge from being repeated.  However, mergeinfo is
      recorded and this mergeinfo is redundant .  This cause of this bug has existed
      for a long time, it is only with the recent change to make no-op merges set
      mergeinfo (see issue #2883) that it has (re?)surfaced.  For example:
      
      >svn info src-trunk
      Path: src-trunk
      URL: http://svn.collab.net/repos/svn/trunk
      Repository Root: http://svn.collab.net/repos/svn
      Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
      Revision: 30214
      Node Kind: directory
      Schedule: normal
      Last Changed Author: cmpilato
      Last Changed Rev: 30212
      Last Changed Date: 2008-04-03 09:43:47 -0400 (Thu, 03 Apr 2008)
      
      
      >svn pg svn:mergeinfo src-trunk
      /branches/svn-mergeinfo-enhancements:30122
      
      >svn merge http://svn.collab.net/repos/svn/trunk src-trunk -c25549
      
      >svn st -q src-trunk
       M     src-trunk
      
      >svn diff src-trunk
      
      Property changes on: src-trunk
      ___________________________________________________________________
      Modified: svn:mergeinfo
         Merged /trunk:r25549
      
      
      >svn pg svn:mergeinfo src-trunk
      /branches/svn-mergeinfo-enhancements:30122
      /trunk:25549
      
      This self-referential mergeinfo isn't harmful as it's semantically correct.  It
      is however potentially confusing to users as discussed in these threads:
      
      http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=134491
      http://subversion.tigris.org/servlets/ReadMsg?listName=svn&msgNo=34322
      
      As the second thread discusses, common cyclic merges could introduce
      self-referential mergeinfo, but that was fixed in r29085.  This case is likely
      to be a lot less common however.  It won't happen during merges where no
      revision range is specified, it will only happen if you specifically ask to
      merge a range from a paths own history.  But a not-so-unusual use case is when
      re-mergeing a change from a path's own history that was previously reverse-merged.
      

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              pburba Paul Burba
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: