Obstructed folders in Subversion

What the heck does "obstructed" mean when you try to check into Subversion? I see two folders in red with text status of "obstructed." I don't see what this means anywhere in the docs.

When I try the cleanup command, I get "folder name is not a working directory." This is a folder I just created in VS, and when I try to add it to Subversion it gives me that error. All other folders are fine.

it occurs when you have deleted or moved the .svn subdirectories (without going through SVN commands), so SVN has a corrupted view of the working copy.

Try a cleanup first, and if that doesn't solve it, revert (or update) the directory to restore the subdirectory .svn folders.

Without knowing what causes this, the solution can be to export the working copy (the entire checkout you have locally) to somewhere else.

If you are using tortoisesvn, you get the option to "export un-versioned files", but I think if doing it from the command line it only exports versioned files so you might have a bit of a laborious task copying un-versioned files manually.

Once done, check out a clean working copy and then drop the exported backup you have over the top of it. It's very important that the backup has no .svn folders in it.

I've seen these errors before when people have checked out working copies inside other working copies or anything else that corrupts the .svn entries.

Had the same issue and fixed it like this:

• renamed the obstructed dir
• created the dir with its original name in SVN (e.g. svn mkdir)
• updated the parent folder, so the newly created dir appears in my working copy
• copied the files from the obstructed to the newly created dir and commited them

If you're on a *nix system, ensure that you didn't create a file, add it to SVN, then delete it, replacing it with a folder of the same name. Doesn't help OP, but hopefully it'll save someone a bunch of stress.

This means that, for some reason, a conflict has occurred during the operation. Check to see if there is an existing unversioned file or folder with the same name as a versioned one.

(Paraphrased from the Tortoise SVN client help file)

Nothing worked for me so i've done the following:

• exported with the unversioned files in a new location
• renamed the existing folder
• moved the folder from the export location in the project
• renamed the new folder
• add, commit
• removed the old, renamed folder
• renamed the new folder
• commit

There are different variations of scenario that can cause this situation. Here is one example:

I ended up with the ! mark on a directory which was renamed from www to www_a without using 'svn rename' command:

1. Rename the current directory that bears the original name, for example to www_b
2. Rename www_a back to www
3. Make sure you do 'svn update' or 'svn revert' inside the www directory
4. Delete the up-to-date www directory without using 'svn delete'
5. Go to the parent directory and issue 'svn update'
6. This will restore the original www directory
7. This time use 'svn rename' to rename www to www_a
8. Rename www_b back to www
9. Use 'svn add' to add it into the repository

You should get a correct svn work directory at this point. And learn a thing or two on how to resolve svn directory confusion.

Faced this issue on a Windows machine.

I had checked out the directory before I checked out the entire project it belonged to. It caused the 'obstructed' issue for me.

I simply deleted that folder and ran an update from root (of that folder). It worked fine.

Commands like cleanup etc. did not work for me.

Some word of caution:

1. This is costly if the folder is large.
2. It will cause you to lose all your changes if there are any.

All the best.

I have also seen this on Windows when I have created a symbolic link to a repository directory; in this case, the repository root is seen as "obstructed". This doesn't seem to have any affect, though.

Steps to reproduce:

1. Checkout your repo

   svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir
   

2. Check that your directory is OK

   cd plugin_dir
   svn st -u
   

   Output should be

   Status against revision: 1234
   

3. Create the symlink (which shows the problem)

   cd ..
   mklink /d link_dir plugin_dir
   cd link_dir
   svn st -u
   

   Output will be

   ~           1234  .
   Status against revision: 1234
   

I ran into this problem when pasting at folder with subdirectories into my working copy using my FTP client - I knew I screwed up as soon as I hit the transfer button... the perils of working way too late.

I tried all the suggestions above and other found online to no avail. Every option produced the error that my directory was locked and the operation could not be performed.

I went into my Time Machine copy, restored the directory and was good to go. I cleaned the working copy as a precaution, updated my files properly and was back in business.

We often have multiple branches on the go at the same time, in order to save me switching or messing around with IIS configuration I check each branch out to a separate folder. I then use directory linking to connect those folders back to the main path configured in IIS.

So for me the linked directory always has a yellow exclamation and is marked as obstructed. I believe this is because it was technically created/moved outside of SVN.

I get this "obstructed" status on directories when I do updates to a CMS (WordPress or Drupal) through the web interface -- the application is unaware that its code is actually a subversion working copy, so when updating a plugin it removes that plugin's directory (including the .svn directory) and drops in a new directory from the new version of the plugin.

To get that .svn dir back, from the directory containing the obstructed dir. I do a checkout with --force. For example, if plugin_dir is marked "~", from its parent directory I run:

svn checkout --force http://svn.server.hostname/path/to/repo/and/plugin_dir

Any files already there are left alone and marked "E" on the output of the checkout command (marked as "M" when I run svn status).

I sometimes have to go back and add any files that were new with the update; or delete files that should be deleted as part of the update, since they re-appeared when I did the checkout. I believe these are marked as "A" on the checkout, but a subsequent svn status won't mention them.

I ran into this in Eclipse where some files were marked with a red exclamation point. The problem was a stray .svn folder in the source directory. I deleted the .svn folder, refreshed eclipse, and was able to check in the files.

This can also happen when you upgrade your subversion to a version that XCode does not support.

Here's the simplest (and safest) way I've found to resolve this:

1. Temporarily rename the offending file or directory (or a parent directory) that is obstructed (e.g. add ".backup").
2. Delete any .svn directories inside the renamed directory (if applicable).
3. svn revert the renamed (and now missing) object from step 1.
4. svn delete the reverted object.
5. Re-rename the backup from step 1 back to its original name.
6. Add and check-in the renamed object back into svn as a new object.

This occurred to me when I replaced a file with a folder, having the exact same name. Solved by deleting the old file, commit, and then add the new one. A little hacky, but worked for me :)

I deleted .svn in obstructed directories and update it from outside. Then outside svn command will recognize these files.