[jira] [Commented] (SVN-3630) Rename tracking

    [ https://issues.apache.org/jira/browse/SVN-3630?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D177412=
24#comment-17741224 ]=20

Ken commented on SVN-3630:
--------------------------

When dealing with source code, files are small enough that the current syst=
em 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 amoun=
t 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" op=
erations in a more client-friendly fashion. Even if the solution is efficie=
nt only in clear-cut cases (triggering a conflict in other cases), it would=
 help.

=C2=A0

> 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 th=
e
> concept of "renames" or "moves".=C2=A0 Modeled today as a copy of an obje=
ct 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 de=
signs
> and implementations would expect.=C2=A0 Issue #SVN-898 tracks this dispar=
ity and its
> prescribed remedy.
> But for years I've been unconvinced that "true renames" are required for =
correct
> day-to-day operation of Subversion.=C2=A0 To date, I've not seen convinci=
ng evidence
> that there is an inherent problem with the copy+delete model.=C2=A0 Why t=
hen, is
> Subversion's handling of rename operations the source of so much complain=
t and
> frustration?=C2=A0 Because it is very, very incomplete.
> The copy+delete concept is applied on the client side:=C2=A0 'svn move' i=
s almost
> exactly just 'svn copy' and then 'svn delete'.=C2=A0 So far so good.=C2=
=A0 Except when
> it's not.=C2=A0 Because the minute that the move operation completes, Sub=
version has
> forgotten a critical piece of information:=C2=A0 that the copy and the de=
lete are two
> parts of a higher conceptual operation that's valuable to recognize.=C2=
=A0 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 on=
e of
> them instead of both, or reverting one of them, etc.=C2=A0 Even when you =
commit both
> sides of a renamed object, there is no information transmitted to the ser=
ver to
> tell it that the copy and delete are conceptually tied together.=C2=A0 Th=
erefore
> there's no data stored in the repository to that effect.=C2=A0 Therefore,=
 when
> clients are pulling information out of the repository (updates, log histo=
ry,
> merges, etc.) there is no data transmitted to the clients to that effect.=
=C2=A0 The
> special connectedness of the operations is forgotten immediately, to the
> detriment of Subversion's ability to help its users do what they often ne=
ed to
> do with renamed objects.=C2=A0 The results today include excessive tree c=
onflicts,
> 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-visi=
ble
> 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)