Feature request: rename after move/copy

Imagine this folder layout:
  trunk/folder1/
  trunk/folder1/fileA
  trunk/folder2/

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
to.

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: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jul 7 14:57:32 2006