[
https://issues.apache.org/jira/browse/SVN-3630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17741224#comment-17741224
]
Ken commented on SVN-3630:
--------------------------
When dealing with source code, files are small enough that the current system
can work.
That is not the case for projects dealing with large, binary files.
"Rename/move" operations are a _major issue_ when large files are involved.
Doing a "{color:#172b4d}rename/move"{color} and "commit" is easy enough for the
user applying it. The change is immediate and consumes a trivial amount of
bandwidth. However, every user that subsequently updates is forced to download
excessive amounts of redundant data.
Renaming a 1GB file means every other user has to download that file, even if
they already have it.
If a folder containing 50 of those files is moved or renamed, every client
needs to download 50GB of data. That also means a lot of unnecessary writes to
the drive, especially when we consider pristines.
It would be a massive improvement for Subversion to handle "rename/move"
operations in a more client-friendly fashion. Even if the solution is efficient
only in clear-cut cases (triggering a conflict in other cases), it would help.
> 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
(v8.20.10#820010)
