Proposal: Genuine WC Moves
Everyone agrees that genuine renames are needed, and that they can't really
be implemented until v2.0 because it will require incompatibly extending the
protocol to have a 'rename' command. This proposal only concerns genuine
renames within a WC.
Part I: Genuine WC Moves
1. 'moved' attribute
In the entries file, we have a 'copied' attribute. This attribute
indicates that the file has been copied from another WC item. Certain
operations are prohibited on copied files for technical reasons -- for
example, one cannot use an item with copied="true" as the source for another
copy operation.
I propose adding a 'moved' attribute for all files that were affected by a
mv operation. This 'moved' attribute will partially behave as
copied="true", in that it will prohibit moved files from being used as the
source of a copy:
# [case 1]
$ svn mv foo bar
$ svn cp bar bar2
# no way jose
However, entries with the 'moved' attribute *should* be allowed to move
again, so that this:
# [case 2]
$ svn mv a b
$ svn mv b c
should be no different from this:
# [case 3]
$ svn mv a c
2. schedule and new-name
When a file is moved, the entries files should be adjusted as such:
1a. The entry for the original filename should be given
schedule='move-to'. This will indicate that the file is to be deleted
(as schedule='delete') when committing, but also that the file is to be
treated as renamed for other situations. It will also be given the
attribute new-name, with the value of the new filename (relative to
what? I have not yet decided the best answer for that yet. It should be
chosen such that the new file can be found.)
2a. The entry for the new filename should have schedule='move-from' and
the attribute old-name with what the filename was originally (again,
I am not yet certain what it should be relative to, just that we should
be able to correctly determine the original filename.)
If the entry for the old filename already has schedule='move-from', then
this is the 2nd step of '[case 2]' above, and we need to do this instead:
1b. Find the entry for the original filename, based on the old-name
attribute. Set *that* entry's new-name to the correct new name.
2b. Delete the entry for the old filename.
3b. Create an entry for the new filename, as in step 2a above.
Then, undoing a move should consist of:
$ svn mv foo bar
# oops
$ svn revert foo
# or, svn revert bar
and not this, which is currently what's required:
$ svn mv foo bar
# oops
# svn revert foo
# svn revert --recursive bar
# rm -rf bar
Alternatively, with enough intelligence, this should work:
$ svn mv foo bar
# oops
$ svn mv bar foo
This sort of thing should (hopefully) leave everything in the original
state, without reverting the *contents* of any changed files.
Things to consider
* sussman wants to know: what should happen when the user does this?
$ svn mv A B
$ svn commit B
It can either fail (and succeed only if the user does 'svn commit A B'),
or it can behave as 'svn commit A B' does currently. I think that it's
easiest if both 'svn commit A' and 'svn commit B' behave as 'svn commit A B'
would do today.
Part II: Handling said moves more gracefully when updating
This is the part I haven't quite worked out as well yet. Fortunately, Part I
doesn't require Part II in order to work (but Part II does require part I to
work.) I have a few ideas running around in my head, here's one of the ones
I've come up with.
1. When updating, don't report the original names of moved files as having
been deleted.
2. When updating, do automagic translation of filenames somehow. That is,
when this happens:
$ svn mv foo bar
$ svn up
U foo/a
Presently the update to foo/a will cause the entire tree of 'foo' to be
magically reproduced. What *should* happen, ideally, is that the client
should say 'oh, wait, we moved foo->bar' and then translate that into
U bar/a
This sort of thing would be easy to do by simply taking the filename
coming back, and replacing 'foo' with 'bar'. Things get tricky, however,
when handling this sort of thing:
$ svn mv a b/c
Like I said, this one needs more thought.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 10 20:02:51 2005