[
https://issues.apache.org/jira/browse/SVN-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad updated SVN-3630:
-----------------------------
Component/s: (was: src)
> Rename tracking
> ---------------
>
> Key: SVN-3630
> URL: https://issues.apache.org/jira/browse/SVN-3630
> Project: Subversion
> Issue Type: Bug
> Affects Versions: trunk
> Reporter: C. Michael Pilato
> Priority: Critical
> Fix For: 1.10-consider
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
