[SVN-3630] Rename tracking

• Type: Bug
• Status: Open
• Priority: Critical
• Resolution: Unresolved
• Affects Version/s: trunk
• Fix Version/s: 1.10-consider
• Assignee: Unassigned
• Reporter: C. Michael Pilato
• Created: 06/May/10 17:01
• Updated: 08/Jul/23 00:35

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

Issue Links

• depends upon: SVN-3632 Subversion's RA subsystem should carry rename information
• depends upon: SVN-3633 Track renames as renames inside Subversion repository
• depends upon: SVN-3634 Subversion repository dumpfile format needs to carry rename information
• depends upon: SVN-3631 Client-side tracking of renames
• is blocked by: SVN-3632 Subversion's RA subsystem should carry rename information
• is blocked by: SVN-3633 Track renames as renames inside Subversion repository
• is blocked by: SVN-3634 Subversion repository dumpfile format needs to carry rename information
• is blocked by: SVN-3631 Client-side tracking of renames