tags:

views:

20

answers:

2

I know how I got here: I tried to add an entire directory tree to my repository, but one of the subdirectories I did not have write permissions. So when I did svn add, I got errors (which I didn't record, sorry.)

Now, if I do svn status inside the directory I get a whole list of files. Yay! But when I try an svn commit I get the "directory locked" error. As instructed I run svn cleanup and am told that the directory I formerly didn't have permissions on is "not a working copy directory".

If I svn unlock --force, I am told the directory is locked.

This is my copy of the directory and there seems to be no way to commit it. When I did an SVN update on another working copy I got the directory but no other files. Again, when I run svn status in this working directory, I get the long list of files.

I'm afraid of the "delete and checkout" solution because I only have the top-level directory in the repository. I was trying to get these files in.

I'm concerned that if I recursively delete all the .svn directories in the subdirectories beneath this top-level directory, that I will create a bigger conflict. I don't want to dig myself deeper into the hole.

Is there a way out from between the rock and the hard place? Also: is the fact that it was so easy to hose my repository evidence that I should be looking to replace SVN? Not having write permissions on a directory is a condition that software should fail gracefully under. I can't guarantee it won't happen again.

A: 

Can't you just copy the files into your other working copy, without copying the .svn directories, and then do an add and commit from there?

Dingo
+2  A: 

Start by making a full copy of your working directory.

Move the problem working dir somewhere out of your svn tree. Update and commit. Delete the directory itself from your revision if it came back, and commit again. This should have resolved the conflict. Now recursively remove the .svn folders from the problem dir, and copy it back into the target location. Re-add it all to svn, and commit.

Is it clumsy? Yes. Does it solve the problem? It should.

Subversion tends to have some distinct areas that are problematic. You tend to learn to work around them as you use it. SVN and DVCS tend to have different use cases, and are suited to different project management styles. DVCS has its warts too.

Paul McMillan