Quoting Karl Fogel <kfogel@newton.ch.collab.net>:
> There is a "back story" to why rename is implemented as delete+copy
> instead of as a single primitive. It's the scenario where someone
> updates a tree in such a way as to receive only one side of a rename
> event.
>
> For example, Joe does
>
> $ svn rename foo/blah.c bar/blah.c
>
> Then, Veronica does
>
> $ cd foo # (or bar)
> $ svn update
>
> When Veronica updates, she should experience the delete (or copy) that
> occurred in the tree she's updating, yet *not* experience the
> corresponding other event, since that occurred in a place she's not
> updating.
>
> I'm not sure how this affects the discussion. Perhaps we just weren't
> imaginative enough when we were implementing rename, and it's actually
> possible to have atomic renames and also have Veronica's update work
> correctly. I just wanted to explain the back story, and make sure
> that people keep the scenario in mind when they're thinking about this
> problem.
This is a good point. Luckily, if (when!) we do rename correctly, it reduces to
two directory changes (possibly on the same directory, of course); so, if your
working copy only has one of those directories, you'll see only one directory
change on update -- which is exactly right.
The bigger problem is this:
$ cd wc; ls -F
foo/ bar/
$ svn mv foo/qux bar/qux
$ svn st
D + foo/qux # The '+' here is "delete for rename"
A + bar/qux
$ cd foo
$ svn ci -m 'Committing half a rename?'
(Note, the status output is just an example, I'm sure we can do better.)
We have to either forbid this scenario (unrealistic), or force the commit of
bar/qux even if the commit is in foo/, and that's a non-trivial change in WC
management. A revert must also magically affect the other half of the rename.
I think the right approach would be to do the server- (and FS-) side changes
first, and hook the new rename into "svn mv URL URL", and only tackle the WC
side once that's done.
Good job we don't allow repo<->WC renames. Nor should we.
Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 12 08:03:19 2002