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

E

21

186

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.

Endothelioma answered 8/9, 2009 at 13:36 Comment(0)

W

150

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".

Waltman answered 8/9, 2009 at 13:46 Comment(6)

I have SVN so much. Littering .svn subdirectories all over the place must have been the worst idea in version control history. – Corbet 10/6, 2013 at 15:11

Folks, do check out the below suggestions by Rob, it's far easy then the current solution. – Sports 19/6, 2013 at 4:55

Mohammed, thanks for the heads up. That worked for me. Was trying to get SVN to ignore a log directory, and deleting .svn got me to this problem. Rob's solution solved it. – Heptateuch 30/6, 2014 at 18:27

Johannes, i am not a proponent of SVN either but the advantage of the .svn directories is that you can check out sub directories of a repository and maintain version control. – Levison 7/3, 2015 at 20:13

@MohammadArif, There are two "Robs" now – Inhabitancy 12/6, 2017 at 20:32

@CharlesClayton, I meant Rob Wells now :) – Sports 13/6, 2017 at 4:20

K

123

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.

Kowtko answered 1/12, 2009 at 10:44 Comment(6)

This worked for me as well. Updates and cleans failed because the directory never was in the repository, but the working copy was sure that it was under revision control. I wonder if I added the directory, but then deleted it before I committed it? – Utah 11/6, 2010 at 19:21

This is very good. I had added a directory, deleted the .svn but never commited. This totaly did the trick – Japheth 18/10, 2010 at 22:30

Thank you; this answer saved me a lot of time. svn cleanup then svn --force delete <directory-that-doesn't-exist-but-should> worked for me. – Valor 10/11, 2010 at 8:46

Worked on the second try, I first tried without --force, that somehow left a lock file in .svn of the parent which I had to manually remove. Second time with --force fixed the problem. – Teeter 8/2, 2011 at 15:28

Thank you. This totally did the trick. Force the delete and then add back the directory did it for me. – Saintly 5/4, 2011 at 2:58

Hm, that command simply gives me the same "working copy" error. – Stinnett 29/10, 2012 at 12:21

T

73

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.

Tedmann answered 12/6, 2010 at 4:25 Comment(2)

I can't believe...I tried everything...and it was just that easy!!! It perfectly worked, many thanks!!!!! – Arduous 4/7, 2012 at 17:54

This is the most straight forward answer. – Syllabic 15/7, 2015 at 11:26

M

35

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.

Marthamarthe answered 8/9, 2009 at 13:41 Comment(6)

I tried that but for some strange reason, I end up with an empty directory. I don't get it... – Endothelioma 8/9, 2009 at 13:54

An explicit <code>svn update blabla</code> from the parent should work too. – Alba 8/9, 2009 at 15:44

@jmanning2k, that's what i thought as well, but the OP said that he'd tried it and it hadn't worked. – Marthamarthe 8/9, 2009 at 15:58

To clarify, I suggested --set-depth infinity because of this: #867335 – Retsina 8/9, 2009 at 16:11

Awesome, it's resolved the issue, I think, it should be the accepted answer because one doesn't need to take the checkout and copy the .svn folder. – Sports 19/6, 2013 at 4:53

This needs so much more upvotes... quick and relatively (for svn standards) clean solution. – Nga 20/1, 2015 at 7:59

H

6

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.

Hero answered 16/1, 2013 at 16:52 Comment(2)

This worked for me when my IDE added a directory, and then I had moved a directory of the same name into place before it was committed. – Destinee 28/1, 2013 at 8:31

tried this, but still couldn't commit. I used svn checkout --force [url] which recreated the .svn folder – Strophe 18/4, 2013 at 3:25

A

4

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

Anachronism answered 28/9, 2010 at 16:32 Comment(1)

Thanks. I had this issue and tried your suggestion and it worked. – Dragline 31/1, 2013 at 21:18

C

3

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).

Congruency answered 11/2, 2010 at 2:12 Comment(0)

S

2

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.

Sebbie answered 6/9, 2010 at 0:29 Comment(2)

Removing what/from where exacly? – Admetus 11/11, 2010 at 15:42

maven creates the "target" directory, when building. Usually no one is suppose to check in this one. An accedent checkin made a permission issue next time checkout which created this error. Removing "target" directory from SVN solved the issue. – Sebbie 24/11, 2010 at 1:4

L

2

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

Lolalolande answered 5/1, 2012 at 22:19 Comment(0)

D

1

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.

Donal answered 18/12, 2009 at 1:29 Comment(0)

R

1

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.

Reckoning answered 19/7, 2010 at 12:59 Comment(0)

H

1

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.

Hoodwink answered 19/1, 2011 at 13:44 Comment(0)

P

1

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;

Prophetic answered 12/3, 2011 at 0:49 Comment(0)

D

1

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!

Dragline answered 31/1, 2013 at 21:20 Comment(0)

E

1

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.

Echinate answered 3/7, 2013 at 11:49 Comment(0)

M

1

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:

1) 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"

2) 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.

Muscovado answered 29/7, 2013 at 14:25 Comment(1)

I generally like to work on code separately from my working copy of the repo (IDEs, compilers, error parsers etc. do not like .svn, and there is no 'EVERYONE IGNORE .SVNs EXCEPT SVN!' command in Eclipse afaik); this means that the basic SVN commit process for me is: 1. checkout working copy of repo 2. delete root directory of project I have an update for 3. copy and paste updated project directory to parent directory of project in working copy 4. svn add --force <projname> 5. commit. This usually works, but can occasionally throw the OP's error. Jamie Brown's fix worked in my case – Ayurveda 1/10, 2013 at 17:15

K

0

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

Kaput answered 6/3, 2011 at 23:17 Comment(0)

P

0

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.

Prey answered 14/10, 2011 at 10:3 Comment(0)

G

0

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

Grandpa answered 12/3, 2012 at 9:52 Comment(0)

N

0

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.

Neurotomy answered 2/5, 2012 at 15:0 Comment(1)

I might add that this is added to my "svn sucks" file. – Neurotomy 17/5, 2012 at 15:16

G

0

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

Gourd answered 28/3, 2019 at 17:5 Comment(0)

Recommended topics

Hot tags