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

In tree conflict info, report left/right URL@REV of the incoming change

Details

    • Improvement
    • Status: Closed
    • Critical
    • Resolution: Fixed
    • trunk
    • 1.6.0
    • unknown

    Description

      A tree conflict currently reports whether the incoming change was a delete or
      add or modify. To help the user resolve the conflict, it would be better to also
      store and report the merge-left source and merge-right source URL@REV for a
      merge, and something similar for an update/switch. This would avoid the user
      having to remember or try to find out this info.
      
      In some cases, e.g. update a mixed-revision WC, I suspect (but have not
      verified) that it may presently be impossible to determine what the previous
      base revision number was after trying an update that caused tree conflicts.
      

      Attachments

        Issue Links

          Activity

            julianfoad Julian Foad added a comment -

            This suggestion of storing URL@REV is a minimal way to ensure that the necessary
            information is propagated. Possible improvements include:
            
            * UI/API for accessing OLD/THEIRS/MINE or LEFT/RIGHT/MINE.
            
            An improvement would be to provide an API and UI for accessing these
            LEFT/RIGHT/MINE or OLD/THEIRS/MINE files/dirs with a specific syntax rather than
            URL@REV. For example, a set of revision keywords applicable to any WC item while
            it is in any kind of conflict, thus: "svn proplist ./foo.txt@MINE", etc.
            
            * Cache locally
            
            An improvement would be to cache the OLD/THEIRS/MINE files locally like we cache
            the pristine base. (We might need a UI/API for accessing them, because the
            present URL@REV UI semantics require the target to be fetched from the
            repository, not from a local cache.)
            
            (Discussion should be on the mailing list, not here. Any actual proposal of this
            nature should be in a separate issue and linked from here. I don't yet have
            issues filed for these two suggestions.)
            
            

            julianfoad Julian Foad added a comment - This suggestion of storing URL@REV is a minimal way to ensure that the necessary information is propagated. Possible improvements include: * UI/API for accessing OLD/THEIRS/MINE or LEFT/RIGHT/MINE. An improvement would be to provide an API and UI for accessing these LEFT/RIGHT/MINE or OLD/THEIRS/MINE files/dirs with a specific syntax rather than URL@REV. For example, a set of revision keywords applicable to any WC item while it is in any kind of conflict, thus: "svn proplist ./foo.txt@MINE", etc. * Cache locally An improvement would be to cache the OLD/THEIRS/MINE files locally like we cache the pristine base. (We might need a UI/API for accessing them, because the present URL@REV UI semantics require the target to be fetched from the repository, not from a local cache.) (Discussion should be on the mailing list, not here. Any actual proposal of this nature should be in a separate issue and linked from here. I don't yet have issues filed for these two suggestions.)

            *** Issue 3330 has been marked as a duplicate of this issue. ***
            

            stsp Stefan Sperling added a comment - *** Issue 3330 has been marked as a duplicate of this issue. ***

            See also this thread:
            http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=145450
            

            stsp Stefan Sperling added a comment - See also this thread: http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=145450
            julianfoad Julian Foad added a comment -

            Bumped the priority because it would be Really Useful.
            

            julianfoad Julian Foad added a comment - Bumped the priority because it would be Really Useful.
            julianfoad Julian Foad added a comment -

            Started, on branch "tc_url_rev".
            

            julianfoad Julian Foad added a comment - Started, on branch "tc_url_rev".
            julianfoad Julian Foad added a comment -

            Bumped the priority to "1.6".
            
            

            julianfoad Julian Foad added a comment - Bumped the priority to "1.6".
            julianfoad Julian Foad added a comment -

            Mostly done... Branch merged to trunk in r34xxx.
            
            One bug is reported at <http://svn.haxx.se/dev/archive-2008-11/0963.shtml>: a
            tree conflict during merge is reported as "file:///.../repos/trunk@1" but should
            be "file:///.../repos/trunk/com/yoyodyne@1".
            
            

            julianfoad Julian Foad added a comment - Mostly done... Branch merged to trunk in r34xxx. One bug is reported at <http://svn.haxx.se/dev/archive-2008-11/0963.shtml>: a tree conflict during merge is reported as "file:///.../repos/trunk@1" but should be "file:///.../repos/trunk/com/yoyodyne@1".
            julianfoad Julian Foad added a comment -

            That bug was fixed in r34436.
            
            Closing this issue as Fixed.
            

            julianfoad Julian Foad added a comment - That bug was fixed in r34436. Closing this issue as Fixed.

            People

              Unassigned Unassigned
              julianfoad Julian Foad
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: