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.