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

Rename tracking



    • Bug
    • Status: Open
    • Critical
    • Resolution: Unresolved
    • trunk
    • 1.10-consider
    • None
    • None


      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 #SVN-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

      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 #SVN-898 suggestions.


        Issue Links



              Unassigned Unassigned
              cmpilato C. Michael Pilato
              0 Vote for this issue
              5 Start watching this issue