[
https://issues.apache.org/jira/browse/SVN-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15861300#comment-15861300
]
Stefan Sperling commented on SVN-3630:
--------------------------------------
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.)
> Rename tracking
> ---------------
>
> Key: SVN-3630
> URL: https://issues.apache.org/jira/browse/SVN-3630
> Project: Subversion
> Issue Type: Bug
> Components: src
> Affects Versions: trunk
> Reporter: C. Michael Pilato
> Priority: Critical
> Fix For: 1.10-consider
>
>
> {noformat:nopanel=true}
> 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.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
