A sane way to rename a directory in subversion working copy

Question

While somehow versed in VCS (regular svn, git and git-svn user) I can't seem to wrap my head around this peculiar SVN behavior.

Whenever I need to rename a directory in my SVN working copy from an otherwise 'clean' state - i.e svn status returns nothing and all other modifications have been commited - like so (which is what the svn doc suggests):

svn mv foo bar
svn commit

SVN complains loudly:

Adding         bar
Adding         bar/toto
Deleting       foo
svn: Commit failed (details follow):
svn: Item '/test/foo' is out of date

As you wish:

svn update

Which gives:

   C foo
At revision 46.
Summary of conflicts:
  Tree conflicts: 1

There's a tree conflict, while no third-party change happened. Obviously, the only way to get out of this tree conflict mess is generically (from the svn red book):

svn resolve --accept working -R .
svn commit

Renaming it remotely on the repo then updating my working copy seems quite braindead:

url=$(svn info | grep -e '^URL:' | sed 's/^URL: //') svn mv $url/foo $url/bar
svn update

Is there a sanctioned, more streamlined way to rename a folder that I'm missing? What is the root cause behind that particularly surprising tree conflict state?

Answer 1

svn mv works for me:

C:\svn\co>svn mv my_dir new_dir
A         new_dir
D         my_dir\New Text Document.txt
D         my_dir


C:\svn\co>svn commit -m foo
Raderar             my_dir
Lägger till         new_dir

Arkiverade revision 2.

C:\svn\co>

Sorry for the Swedish output of svn.

There must be something else that is wrong in your case.

Edit:
As pointed out in the comments by Lloeki

To reproduce the behavior you also need to update and commit a file contained in the folder, but not update the folder itself.

file commit creates a new rev n on the repo, but local metadata is not updated (as it has always be, see svn log after any commit) , thus dir metadata is at rev n-1. It follows that svn won't commit because of the metadata diff, and it won't update because there's indeed a conflict on the dir: update metadata vs delete.

The behavior is "expected" and the "solution" is to update the working copy before issuing the svn rename command.