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.

Answer 2

One could think of a scenario where the directory has been changed in the repository by an other user. Renaming the same folder in your working copy may trigger tree conflicts during commit.

Resolving conflicts shows how to resolve 'tree conflicts' in subversion.