Home/ Questions/Q 3237862
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T17:47:16+00:00

I know how I got here: I tried to add an entire directory tree

  • 0

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.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0