[
https://issues.apache.org/jira/browse/SVN-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Foad updated SVN-3630:
-----------------------------
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.
was:
{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}
> 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
>
>
> 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)
