Imagine this folder layout:
Now I decide to do a bit of rearranging (as part of a larger edit) and
want to move it over to a different folder:
> svn mv trunk/folder1/fileA trunk/folder2/
That's ok, and leaves fileA in an 'add with history' state.
After some more development (without committing from the move, because
things are still not in a good commit state), I decide that it's a good
idea to rename fileA to fileB, since its function has changed.
> svn mv trunk/folder2/fileA trunk/folder2/fileB
svn: Use --force to override this restriction
svn: Move will not be attempted unless forced
svn: 'fileA' has local modifications
This is odd behaviour, since a move/rename should be nondestructive in
this context. Still:
> svn mv --force trunk/folder2/fileA trunk/folder2/fileB
svn: Cannot copy or move 'findsym.c': it's not in the repository
yet; try committing first
This is just plain wrong. Don't force me to commit when I don't want
It's certainly possible to do, since I've managed to do an
after-the-fact rename (without losing any history) through manual edits
of the files in the .svn folder, but that's not much fun.
If you know you're planning on renaming the file, then you can do it at
the time of the move (by specifying the new filename), but there really
ought to be a way to rename the file after the fact. It's a purely
local operation, after all; there's no need to go to the server because
it's still just in an "add with history" state. All you need to do is
to rename the file and then adjust the .svn file names accordingly (and
fix the 'entries' file too). No need for the delete/add-with-history
dance that the normal committed rename performs.
Doing a regular non-SVN rename is not sufficient because then it loses
its history (and confuses the working copy).
(Actually, this is probably a symptom of something more fundamental; I
ought to be able to rename a file in the "added" state as well, but it
won't let me do that either.)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jul 7 14:57:32 2006