Strange problem with Subversion - "File already exists" when trying to recreate a directory that USED to be in my repository

Question

So - I used to have a directory called mysql a few revisions ago. I deleted it, and decided to start over - but when I try to create the new mysql directory - I keep running into the 'File Already Exists' error:

support:/etc/puppet/modules# mkdir mysql
support:/etc/puppet/modules# svn add mysql/
A         mysql
support:/etc/puppet/modules# svn commit -m " Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-r', path '/trunk/modules/mysql'
support:/etc/puppet/modules# svn delete mysql
svn: Use --force to override this restriction
svn: 'mysql' has local modifications
support:/etc/puppet/modules# svn --force delete mysql
D         mysql

I saw some other posts suggest forcing an update

support:/etc/puppet/modules# svn status
support:/etc/puppet/modules# svn update
At revision 11.
support:/etc/puppet/modules# svn mkdir mysql
A         mysql
support:/etc/puppet/modules# svn commit -m "Test"
Adding         modules/mysql
svn: Commit failed (details follow):
svn: File already exists: filesystem '/var/lib/svn/puppet/db', transaction '11-s', path '/trunk/modules/mysql'

Answer 1

I managed to work around it by reverting back to the last version that I had the mysql directory in, then deleting the contents of the directory, putting the new contents in it, and checking the new information back in. Although I'm curious if anyone has a better explanation for what the heck was going on there.

Answer 2

I'm not sure if this is helping you, but I guess that when you do a svn add mysql after you've deleted it it will just reinstantiate the directory (so don't do a mkdir yourself). If you create a directory yourself svn expects a .svn directory inside it because it already 'knows' about it.

Answer 3

One thing to try is to revert back to a revision that has the directory still in it, use "svn delete mysql" at that point, commit and then.....

nm... you answered it.

Answer 4

already had this type of problem.

my solution was:

delete the folder from svn but keep a copy of the folder somewhere, commit the changes. in the backup-copy, delete recursively all the .svn-folders in it. for this you might run

#!/bin/bash

find -name '.svn' | while read directory;
do
    echo $directory;
    rm -rf "$directory";
done;

delete the local repository and re-check out entire project. don't know whether partial deletion/checkout are sufficient.

regards

Answer 5

I had a problem like this when I deleted a folder (and subfolders) and went to recreate them from scratch. You get this error from manually deleting and readding folders (whereas files seem to cope OK with this).

After some frustrating messing around, found I had to:
(using TortoiseSVN on Windows)

1. Move conflicting folders out of working copy
2. Do an svn update which added old files/folders back into working copy
3. Svn delete folder
4. Commit
5. Copy new folder back into working copy (ensuring you delete all the .svn folders inside)
6. Commit

Unfortunately it (A) requires two commits, and (B) loses file revision history as it only tracks back to the recent re-add (unless someone can explain how to fix this).

An alternative solution that works around these issues is to skip steps 3 and 4, the only problem being that old/unnecessary files may still be present in your directory. You could delete these manually.

Would love to hear any additional insights others might have on this.

Simon.