How to fix "containing working copy admin area is missing" in SVN?

Svn Problem Overview

I deleted manually a directory I just added, offline, in my repository. I can't restore the directory.

Any attempt to do an update or a commit will fail with:

"blabla/.svn" containing working copy admin area is missing.

I understand why, but is there anyway to fix this.

I don't want to checkout the entire repo and add my changes to it manually, it would take hours.

Svn Solutions

Solution 1 - Svn

According to this: http://www.devcha.com/2008/03/svn-directory-svn-containing-working.html

Check-out the folder "blabla" to a different location and then copy its .svn folder back into the original "blabla".

Solution 2 - Svn

fwiw, I had a similar situation and used svn --force delete dir. That solved the issue for me. Then i continued working with my working copy as normal.

Solution 3 - Svn

What I did to fix this was to delete the local copy of the folder under question and then do an svn update of the parent directly afterwards.

Fixed it right up.

Solution 4 - Svn

Can you try to check out a new copy of the parent directory?

Edit: To be bit more specific, I meant to suggest going up one level and deleting the containing directory. Then do a

svn update --set-depth infinity

to replace the directory.

Solution 5 - Svn

I added a directory to svn, then I accidentally deleted the .svn folder within.

I used

svn delete --keep-local folderName

to fix my problem.

Solution 6 - Svn

I just did 'svn revert /blabla' and it worked, the folder is back and I can svn delete it

Solution 7 - Svn

The error "Directory 'blah/.svn' containing working copy admin area is missing" occurred when I attempted to add the directory to the repository, but did not have enough filesystem privileges to do so. The directory was not already in the repository, but it was claiming to be under version control after the failed add.

Checking out a copy of the parent directory to another location, and replacing the .svn folder in the parent dir of the working copy allowed me to add and commit the new directory successfully (after fixing the file permissions, of course).

Solution 8 - Svn

We use maven and svn. It was an mistaken checkin of target directory to SVN that cause this error. Removing that fixed everything, if this hint helps anyone.

Solution 9 - Svn

I tried svn rm --force /path/to/dir to no avail but ended up just running svn up and it fixed it for me.

Solution 10 - Svn

I had this error recently, when the files were excluded by settings in my SVN globals. The error was especially nasty since I also deleted the files directly from the repository - and this meant that the above solutions were refusing wouldn't work. In this case, manually deleting the .svn directory from the directory that I removed from SVN allowed me to run an update which then allowed me to commit.

Solution 11 - Svn

I had the same problem, when I was trying to switch "C:\superfolder"

Error messages:

> Directory 'C:\superfolder\subfolder.svn' > containing > working copy admin area is missing > Please execute the 'Cleanup' command.

After trying to do a "cleanup", I got the following error:

> Cleanup failed to process the following paths: > C:\superfolder
> 'C:\superfolder\subfolder' is not a working copy directory

Solution:

Delete the folder "subfolder"
Clean up the folder "superfolder"
Try to switch again the folder "superfolder"

this worked for me. Please let me know if it also works for you.

Solution 12 - Svn

I had this error recently. It was caused by root owning a couple of files in the directory giving this error.

After I changed the permissions everything worked as expected.

Solution 13 - Svn

Didn't understand much from your posts. My solution is

Cut the problematic folder and copy to some location.
Do Get Solution From Subversion into another working directory (just new one).
Add your saved folder to the new working copy and add it As Existing Project (if it's project as in my case).
Commit;

Solution 14 - Svn

I had this issue. Just move blabla to another location temporarily, tell svn to revert it, and then move it back. It is treated as a new addition. Simple!

Solution 15 - Svn

The simplest that helped me:

rm -rf _dir_in_question_
svn up

If you have changes in the problematic dir, then this is not a good solution for you.

Solution 16 - Svn

I came across this problem when replacing a third party API library with a newer version, and none of the solutions here really worked for me because I wanted to replace the SVN version with the local version. My solution was as follows:

Move the offending folder to my home dir, delete it from SVN and commit:

mv foldercausingproblem ~/
svn --force delete foldercausingproblem
svn commit --message "Temporary removing folder with old API"

Put the folder back, add it to SVN and commit again:

mv ~/foldercausingproblem ./
svn --force add .
svn commit --message "Finally all working!"

Slightly irritating to have to commit twice, but it seems to have worked fine.

Solution 17 - Svn

Just in case anyone wants yet another solution:

Check in your new folder as "foldername2"
Go into Tortise SVN repo browser
Rename "foldername2" to "foldername"
In windows explorer do an update

Hope it helps someone.

-Ev

Solution 18 - Svn

First of all checkout the project into your system in a folder. Then remove the .svn folder from conflict project and copy the .svn folder from new checkout folder and paste into your working copy folder. Then problem is solved.

Solution 19 - Svn

For me, the same issue happened when I both:

deleted (--force) a .map file
added *.map to svn:ignore via svn propedit svn:ignore .

My solution was to:

undo changes to the property
commit changes to the files
checkout a fresh copy of the repository (alas!)
change the property and commit

Solution 20 - Svn

I had this problem when I was trying to add a directory to svn. I solved it by going into repo browser. Right clicking in the left window, choosing add folder and adding the directory directly in the repo browser.

I then deleted the directory locally (after backup of course) did a clean up and svn update and everything was working again.

Solution 21 - Svn

A common task I experienced was having to take one repo directory in staging and copy it to another repo - both under SVN and both called the same name. The way that worked for me was the following:

svn --force delete PROBLEMATIC-DIR
svn export "https://OLD REPO-A/ new-repo-A"
svn add new-repo-A
svn commit new-repo-A

Content Type	Original Author	Original Content on Stackoverflow
Question	e-satis	View Question on Stackoverflow
Solution 1 - Svn	Mark	View Answer on Stackoverflow
Solution 2 - Svn	Matthew Setter	View Answer on Stackoverflow
Solution 3 - Svn	Maurizio	View Answer on Stackoverflow
Solution 4 - Svn	Rob Wells	View Answer on Stackoverflow
Solution 5 - Svn	Alexander	View Answer on Stackoverflow
Solution 6 - Svn	Mala	View Answer on Stackoverflow
Solution 7 - Svn	Rob DiCiuccio	View Answer on Stackoverflow
Solution 8 - Svn	Madu	View Answer on Stackoverflow
Solution 9 - Svn	Nathan J.B.	View Answer on Stackoverflow
Solution 10 - Svn	Casebash	View Answer on Stackoverflow
Solution 11 - Svn	Andreas	View Answer on Stackoverflow
Solution 12 - Svn	J.J.	View Answer on Stackoverflow
Solution 13 - Svn	user834850	View Answer on Stackoverflow
Solution 14 - Svn	Boric	View Answer on Stackoverflow
Solution 15 - Svn	allprog	View Answer on Stackoverflow
Solution 16 - Svn	Jamie Brown	View Answer on Stackoverflow
Solution 17 - Svn	Ev.	View Answer on Stackoverflow
Solution 18 - Svn	Jaideep Singh Raikwar	View Answer on Stackoverflow
Solution 19 - Svn	18446744073709551615	View Answer on Stackoverflow
Solution 20 - Svn	Speck	View Answer on Stackoverflow
Solution 21 - Svn	texasdave	View Answer on Stackoverflow