You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@wandisco.com> on 2010/05/28 16:59:40 UTC
Re: Rename tracking - client side
I (Julian Foad) wrote:
> [...] I've just discovered issue #3630 "Rename tracking" and
> its dependants, and will read them. I think "Rename tracking" is a good
> name. [...]
I made a start on documenting what's needed for the client side of
rename tracking (issue #3631):
[[[
* notes/rename-tracking/renames-client-side.txt
New file.
]]]
[[[
CLIENT-SIDE TRACKING OF RENAMES
===============================
CONTENTS
1. Introduction
2. Behaviour of Local Renames
3. Behaviour of Incoming Renames
4. Copies
1. Introduction
See issue #3631, "Client-side tracking of renames", and issue #3630,
"Rename tracking".
This document specifies the desired client-side behaviour for tracking
a rename.
A local, scheduled rename can result from a Subversion "rename" command
or from an incoming rename during an update, switch or merge. The
behaviour of local renames is specified in section 2.
The other necessary part of client-side behaviour is handling an
incoming rename during an update, switch or merge. That behaviour is
specified in section 3.
A. What is a Rename?
A "rename" operation moves a node from one path to another, in a
single operation. The original node is then in a different
directory and/or has a new name within its directory.
No distinction is made between the words "rename" and "move": either
word refers to the operation that moves a node to a different
directory and/or changes its base name.
No distinction is made between renaming a file, a directory or a
symlink, unless otherwise noted.
A rename cannot change the node kind.
A node can be renamed and edited in the same change.
B. What is New?
The rename operation can be viewed as having two halves - removal
from the source path, and adding or copying to the target path - but
unlike in previous versions of Subversion, these two actions are:
- atomic (indivisible), and
- not quite the same as the separate "svn delete" and "svn copy"
operations.
The rename is remembered and propagated as a rename. One result is
that when a node 'foo' is renamed to 'bar' in branch B1 and that
change is then merged to branch B2, the corresponding node 'foo' in
branch B2 is renamed to 'bar'. In previous version of Subversion,
that did not happen; instead, node 'foo' in B2 was deleted and then
a new node 'bar' was created in B2 by copying the original 'foo'
from B1.
2. Behaviour of Local Renames
A local rename is a scheduled change in the working copy.
A. Atomicity
- commit either path: fail, or commit both halves (TBD)
- resolve either path: fail, or resolve both halves (TBD)
- revert either path: fail, or revert both halves (TBD)
- merge from either path: fail, or include both halves (TBD)
- update/switch: fail, or include both halves (TBD)
- changelist: ?
- export: ?
- lock/unlock: ?
- ...
B. Incoming edits (from update/switch/merge)
Here, "edit" means any modification including a property change or,
for a directory, an add or delete or edit of a child.
- Incoming edit to the source path of any rename (even if a
replacement node exists at that path): apply to the target path.
### Or tree conflict if a replacement node exists?
- Incoming edit to the target path: tree conflict (?) (not possible
with up/sw)
- Incoming add at the source path: tree conflict.
- Incoming add at the target path: tree conflict.
- Incoming delete of the source path: tree conflict.
- Incoming delete of the target path: tree conflict.
- For incoming renames, and cases where there is both an incoming
rename and a local rename, see section 3.
C. Commit
- Transmit the rename information to the server.
- See issue #3632, "Subversion's RA subsystem should carry rename
information".
D. Other WC commands
- copy from source path: fail (can't reference a gone-away node)
- copy from target path: record as copy of that target path? (can we
guarantee ordering such that that will be propagated correctly?)
- copy/move a dir with a whole rename inside it: DTRT (ordering?)
- delete target path: convert the rename into a delete.
- info: on source node, display the target path; on target path,
indicate it is a tracked rename
- rename from source path: fail (can't reference a gone-away node)
(unless the source has since been replaced by a new node, in which
case that new node is referenced)
- rename from target path: adapt the original rename
- status: indicate source and target paths are parts of a rename
- ...
3. Behaviour of Incoming Renames
An incoming rename is a rename described to the client by the server
during an update, switch or merge operation.
A. Automatically merge the incoming rename with the local working copy,
if possible. If not possible, raise a tree conflict.
- Incoming rename, identical to a local rename: merge the two
identical changes and unschedule the local rename
- Incoming rename, where source is source of a local rename:
adjust the local rename accordingly
- Incoming rename, where target is target of a local rename:
tree conflict
- Incoming rename, where source is target of a local rename:
tree conflict (not possible for up/sw)
- Incoming rename, where target is source of a local rename:
tree conflict (not possible for up/sw)
- Incoming rename, local edit: rename the local node, keeping the
local edits (including any unversioned nodes in it, if it's a dir)
- Incoming rename, local delete: tree conflict
B. Source of Information on Incoming Renames
- The intended source is from an updated RA interface. See issue
#3632, "Subversion's RA subsystem should carry rename information"
- A possible backward compatibility measure, when talking to servers
that do not support rename tracking, could be to infer renames
from heuristics on incoming deletes and copies.
4. Copies
### TO DO
Copies should exhibit behaviour in line with renames. During a merge,
an incoming copy should result in a local copy from a local source,
rather than a local copy from a source in the source branch. ...
]]]
- Julian
Re: Rename tracking - client side
Posted by Julian Foad <ju...@wandisco.com>.
On Tue, 2010-06-01 at 15:26 -0400, C. Michael Pilato wrote:
> Julian Foad wrote:
> > I (Julian Foad) wrote:
> >> [...] I've just discovered issue #3630 "Rename tracking" and
> >> its dependants, and will read them. I think "Rename tracking" is a good
> >> name. [...]
> >
> > I made a start on documenting what's needed for the client side of
> > rename tracking (issue #3631):
> >
> > [[[
> > * notes/rename-tracking/renames-client-side.txt
> > New file.
> > ]]]
>
> Did this get committed?
Committed in r952171, with Peter Samuelson's comments so far in r952179.
- Julian
Re: Rename tracking - client side
Posted by "C. Michael Pilato" <cm...@collab.net>.
Julian Foad wrote:
> I (Julian Foad) wrote:
>> [...] I've just discovered issue #3630 "Rename tracking" and
>> its dependants, and will read them. I think "Rename tracking" is a good
>> name. [...]
>
> I made a start on documenting what's needed for the client side of
> rename tracking (issue #3631):
>
> [[[
> * notes/rename-tracking/renames-client-side.txt
> New file.
> ]]]
Did this get committed?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Rename tracking - client side
Posted by Peter Samuelson <pe...@p12n.org>.
[Julian Foad]
> 2. Behaviour of Local Renames
> D. Other WC commands
>
> - copy from source path: fail (can't reference a gone-away node)
>
> - copy from target path: record as copy of that target path? (can we
> guarantee ordering such that that will be propagated correctly?)
Huh ... I think this operation, {mv A B; cp B C}, should behave exactly
like {cp A C; mv A B}.
Peter
Re: Rename tracking - client side
Posted by Peter Samuelson <pe...@p12n.org>.
[Julian Foad]
> 1. Introduction
>
> B. What is New?
>
> The rename operation can be viewed as having two halves - removal
> from the source path, and adding or copying to the target path - but
> unlike in previous versions of Subversion, these two actions are:
>
> - atomic (indivisible), and
>
> - not quite the same as the separate "svn delete" and "svn copy"
> operations.
I don't see a good place in your document to put these further
differences, but they should be noted somewhere:
- 'svn log --stop-on-copy' does not stop.
- 'svn diff' and 'svnlook diff' do not show either a
whole-file add or a whole-file delete