Details

    • Type: Bug
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: trunk
    • Fix Version/s: 1.10-consider
    • Component/s: src
    • Labels:
      None

      Description

      The history of Subversion is littered with intense conversations about the
      concept of "renames" or "moves".  Modeled today as a copy of an object to a new
      location followed by a deletion of the same object, renames in Subversion behave
      in ways subtly different from how folks knowledgeable about filesystem designs
      and implementations would expect.  Issue #898 tracks this disparity and its
      prescribed remedy.
      
      But for years I've been unconvinced that "true renames" are required for correct
      day-to-day operation of Subversion.  To date, I've not seen convincing evidence
      that there is an inherent problem with the copy+delete model.  Why then, is
      Subversion's handling of rename operations the source of so much complaint and
      frustration?  Because it is very, very incomplete.
      
      The copy+delete concept is applied on the client side:  'svn move' is almost
      exactly just 'svn copy' and then 'svn delete'.  So far so good.  Except when
      it's not.  Because the minute that the move operation completes, Subversion has
      forgotten a critical piece of information:  that the copy and the delete are two
      parts of a higher conceptual operation that's valuable to recognize.  Because
      the working copy stores nothing to tie the copy and delete together, you are
      free to act independently on each of those operations, committing only one of
      them instead of both, or reverting one of them, etc.  Even when you commit both
      sides of a renamed object, there is no information transmitted to the server to
      tell it that the copy and delete are conceptually tied together.  Therefore
      there's no data stored in the repository to that effect.  Therefore, when
      clients are pulling information out of the repository (updates, log history,
      merges, etc.) there is no data transmitted to the clients to that effect.  The
      special connectedness of the operations is forgotten immediately, to the
      detriment of Subversion's ability to help its users do what they often need to
      do with renamed objects.  The results today include excessive tree conflicts,
      excessive data transferred across the wire, and excessive user confusion and
      frustration.
      
      This issue exists as an umbrella issue to track remedies to the user-visible
      problems of Subversion's rename-forgetfulness, independent of the more
      theoretical "true rename" issue #898 suggestions.
      

        Issue Links

          Activity

          Hide
          stsp Stefan Sperling added a comment -

          The new conflict resolver in 1.10 should address some (most?) of the user-level concerns: https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver

          That said, the resolver in its current form may not be the best possible technical solution which could be implemented.

          (There was no specific issue filed for the resolver, so I'm linking to release notes.)

          Show
          stsp Stefan Sperling added a comment - The new conflict resolver in 1.10 should address some (most?) of the user-level concerns: https://subversion.apache.org/docs/release-notes/1.10.html#conflict-resolver That said, the resolver in its current form may not be the best possible technical solution which could be implemented. (There was no specific issue filed for the resolver, so I'm linking to release notes.)
          Hide
          brane Branko ─îibej added a comment -

          Moved to 1.10-consider
          

          Show
          brane Branko ─îibej added a comment - Moved to 1.10-consider
          Hide
          pburba Paul Burba added a comment -

          Setting the initial target milestone to 'unscheduled' as part of an issue sweep
          for the forthcoming 1.8 release.  Some elements of this issue may be addressed
          in 1.8, but it certainly isn't a blocker for 1.8.
          

          Show
          pburba Paul Burba added a comment - Setting the initial target milestone to 'unscheduled' as part of an issue sweep for the forthcoming 1.8 release. Some elements of this issue may be addressed in 1.8, but it certainly isn't a blocker for 1.8.

            People

            • Assignee:
              Unassigned
              Reporter:
              cmpilato C. Michael Pilato
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:

                Development