Repost, since the first one seemed to get eaten (apologies if you did
actually get it):
> 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 and
> therefore the server knows nothing about it. 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. It's purely a client library issue.
>
> 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 09:02:16 2006