Karl Fogel wrote:
> I understand that this might make certain operations easier, but I
> think we need solid theoretical grounding for any such change. Being
> convenient (in some circumstances) is not the same as being correct.
OTOH, it is ever so unambiguous from a user's POV. The rule would be
that you can rename/copy+delete files locally all you want, and once
you commit, the repo will reflect the files moved/copied as per the
time you do the commit. Easy to understand.
Also there's nothing technically hindering this functionality, so
there's no good reason to disallow it.
Also, the current state of consecutive svn cp/mv will quickly lead a
user to think his WC is busted every time he accidentally renames a
file wrong, which will make him dislike Subversion in the long run.
Here's an explanation of that scenario.
Scenarios:
1.) You accidentally rename 'abc' to 'dex' instead of 'def'.
2.) You accidentally rename 'abg' to 'def' instead of 'abc' to 'def'.
3.) You accidentally copy 'abc' to 'dex' instead of 'def'.
4.) ... etc ...
We'll start with 1).
# svn mv abc dex
Oops, should've been 'def'. It now seems very obvious (user POV) to
undo the move by 'svn mv'ing the file to a correct filename:
# svn mv dex def
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'dex' has local modifications
That fails, with an unrelated and therefore very poor error message
(local mods?!).
The user might then try to 'svn revert'. He's a bit confused now,
because which file should be the target of svn revert - the renamed
one or the original one?
He tries the renamed one first since it actually exists in his filesystem:
# svn revert dex
Reverted 'dex'
Only to find that it does not accomplish what he expects (renaming the
file back). Judging from the above output, it actually looks like it
reverted 'half' of the rename, eg. the addition of dex, but did not
undo the removal of 'abc'. If he has local mods, he'll be very
worried, but let's assume for now that he hasn't and it's OK that
'dex' is gone. He now does a regular 'ls' but sees that 'dex' is
still there:
# ls
dex
He's getting more confused. Then he tries to svn revert the original
file instead:
# svn revert abc
Reverted 'abc'
Only to find that now he has TWO files - both the original and the
moved-to file:
# ls
abc
dex
Most users will now give up and do one of two things:
a.) Nuke the entire working copy and check out a new one. Most will
probably do this, and go on to be very annoyed about how ungracefully
Subversion handles a wrong file rename.
b.) If user has local changes that he does not wish to be lost, he'll probably:
b.1.) Commit whatever state his WC is in, then clean things up in a
later commit.
b.2.) Check out a new working copy, start copying individual modified
files (but not the ones affected by his svn mv) over from the old one,
to create a good WC.
All of the above solutions leaves a pretty bad impression. Simply
allowing consecutive svn cp/mv in a working copy obviously makes the
problem go away.
Another practicality is that allowing consecutive svn cp/mv would give
Subversion clients and scripts fewer error situations to handle, which
is always a good thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 13 11:19:16 2005