SVN Error - Not a working copy

Question

I got quite a few questions about the same topic here on SO. But could not get an useful answer. And none of these questions talk about the exact problem I have. So I thought adding one more question here is ok. Please do not close this as a duplicate !

Recently our svn server was changed and we did a svn switch. Since the working copy had a huge amount of unversioned resources, the working copy got locked and we started switching folder by folder for all folders under svn, which works perfectly fine.

But at the top most level of the repository, when I try to update files, I get the svn: Working copy '.' locked error and cleanup is not helping either. When I do cleanup, I get errors like these - svn: 'content' is not a working copy directory

Fresh checkout is NOT an option at all. Are there any other ways to cleanup and release the locks and do the switch completely ?

EDIT: The last paragraph in JesperE's answer

If you get a "not a working copy" when doing a recursive "svn cleanup" my guess is that you have a directory which should be a working copy (i.e. the .svn directory at the toplevel says so), but it is missing its own .svn directory. In that case, you could try to just remove/move that directory and then do a local update

seems to be the solution to the problem in the repository. I have identified those folders and did a fresh checkout of those specific folders alone and wow, the locks are released in the subsequent cleanup! Thanks a lot JesperE !!

But, I still cannot figure out the svn switch error which now reads something like,

svn: The repository at 'svn://repourl/reponame/foldername' has uuid 'm/reponame', but the WC has 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Any ideas ?

Answer 1

Often when you can't accept an obvious answer (fresh checkout), it is a good idea to explain why. I can't think of a reason why a fresh checkout would never be an option.

If you get a "not a working copy" error, it means (as I'm sure you know) that Subversion cannot find a proper .svn directory in there. Is there a .svn directory in "contents"? (That is the kind of information you have to provide in order to people to be able to troubleshoot the issue. Remember that we do not have access to your setup, so you have to explain it is such detail that we can figure out from your description whats wrong.)

If you get a "not a working copy" when doing a recursive "svn cleanup" my guess is that you have a directory which should be a working copy (i.e. the .svn directory at the toplevel says so), but it is missing its own .svn directory. In that case, you could try to just remove/move that directory and then do a local update (i.e. "rm -rf content; svn checkout content").

Answer 2

svn: The repository at 'svn://repourl/reponame/foldername' has uuid 'm/reponame', but the WC has 'b5b39681-0ff6-784b-ad26-2846b9ea8e7d'

Every subversion repo has a unique identifier (uuid). Subversion uses this to make sure that the repo is actually the same when doing things like switching. You should probably change the uuid on the server to be the same as before.

Answer 3

Could it be a working copy format mismatch? It changed between svn 1.4 and 1.5 and newer tools automatically convert the format, but then the older ones no longer work with the converted copy.

Answer 4

You must have deleted a SVN - base file from your project (which are read-only files). Due to this you get this error.

Check out a fresh project again, merge the changes (if any) of your older SVN project with new one using "Winmerge" and commit the changes in your latest check out.

Answer 5

Workaround: Rename directory which is not 'working copy' Checkout/update/restore this directory again Move files from renamed directory to new Commit changes

Reason: You made some changes to some files under .svn directory, this breaks 'working copy'

Answer 6

@JesperE mentions that you need to change the uuid. The following should help you achieve this.

On SVN 1.5+, you can do svnadmin setuuid; you can then check that it's been set correctly using svnlook uuid. On earlier versions of SVN, it's a harder process. See http://chestofbooks.com/computers/revision-control/subversion-svn/Managing-Repository-UUIDs-Reposadmin-Maint-Uuids.html

Additionally the UUID of "m/reponame" looks suspicious. I believe it should be a hex-formatted number like the working copy's, so maybe this action will improve things all round :-)

[I originally commented on @JesperE's answer, but created this answer to make it more obvious to people and more helpful for Google. I've since removed my comments. ]

Answer 7

I got into a similar situation (svn: 'papers' is not a working copy directory) a different way, so I thought I'd post my battle story (simplified):

$ svn add papers
svn: Can't create directory 'papers/.svn': Permission denied

Oops! fix permissions... then:

$ svn add papers
svn: warning: 'papers' is already under version control
$ svn st
~     papers
$ svn cleanup
svn: 'papers' is not a working copy directory

And even moving papers out of the way and running svn up (which worked for the OP) didn't fix it. Here's what I did:

$ mv papers papers_
$ svn cleanup
$ svn revert papers
Reverted 'papers'
$ mv papers_/ papers
$ svn add papers

That worked.

Answer 8

I just got "not a working copy", and for me the reason was the Automouter on Unix. Just a fresh "cd /path/to/work/directory" did the trick.

Answer 9

If you created a file inside a new directory, instead of 'svn add newdir/newfile' use 'svn add newdir' because you need to add the directory. All the files inside the directory will be added by default.

Answer 10

I solved it by

1. Copy a backup of the impacted folders
2. SVN revert the impacted folders
3. Paste the files back from the backup

In my case the problem was due to deleted .svn-files.

Answer 11

Same, I needed to update a 'contrib' folder:

1. Moved the old folder out,
2. Copied the new one
3. Copied the .svn folders into each (only three in my case) new folder.

I my case too the problem was due to deleted .svn folders.

Solved.