[svn] SVN Error - Not a working copy

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 ?

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.

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.

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.

Had this same problem, turns out we had Slik 1.6.2 as well as Tortoise on the same machine. Tortoise had been updated (and had updated the working copy) but Slik had not, so Tortoise worked OK, but command lines failed with:

svn: '.' is not a working copy directory

Removing both Tortoise and Slik, then reinstalling Tortoise with command line tools enabled fixed this for me.

Maybe you just copied tree of folder and trying to add lowest one.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

in that case you have to commit directory on the upper level.

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.

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.

Today i have found same issue /FILE_NAME/ is not a working copy in morning and i have spent more then two hours to solve it. After long of RND and Google i found some solution and that is CHECKOUT.

1. CHECKOUT from SUBVERSION to local as new project.
2. Change some of code in java file and COMMIT the project.
3. It's Works for me.

Hope it will helpful for you.

I just ran into a case where the .svn directory is on a nfs server on a different machine, and the nfs client was not running the file locking service (lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

This went away once lockd was started on the nfs client host.

It seems like subversion could come up with a better error message when it has trouble locking files. This was subversion 1.10.0

@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. ]

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.

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'

I made a new checkout from the same project to a different location then copied the .svn folder from it and replaced with my old .svn folder. After that called the svn update function and everything were synced properly up to date.

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'

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.

I made a new checkout from the same project to a different location then copied the .svn folder from it and replaced with my old .svn folder. After that called the svn update function and everything were synced properly up to date.

Had this same problem, turns out we had Slik 1.6.2 as well as Tortoise on the same machine. Tortoise had been updated (and had updated the working copy) but Slik had not, so Tortoise worked OK, but command lines failed with:

svn: '.' is not a working copy directory

Removing both Tortoise and Slik, then reinstalling Tortoise with command line tools enabled fixed this for me.

Maybe you just copied tree of folder and trying to add lowest one.

SVN
|_
  |
  subfolder1
       |
       subfolder2   (here you get an error)

in that case you have to commit directory on the upper level.

Delete .svn folder that is present in your local machine. Press windows icon and type .svn, delete the entire folder. It worked for me.

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'

I just ran into a case where the .svn directory is on a nfs server on a different machine, and the nfs client was not running the file locking service (lockd).

svn: E155007: '/mnt/svnworkdir' is not a working copy

This went away once lockd was started on the nfs client host.

It seems like subversion could come up with a better error message when it has trouble locking files. This was subversion 1.10.0

for mac :- take checkout from server side and a new window will open to select directory from your local machine than put your all code in selected folder then open svn local side and add and commit the project

Recently I was using other developers Mac I had the same situation, problem was; first I needed to type get repo path to terminal but I didn't, than it says what is your user name and password.

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.

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.

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.

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.

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.

I tried pasting the .svn folder from the sub folder to the root folder. It works!!!

Recently I was using other developers Mac I had the same situation, problem was; first I needed to type get repo path to terminal but I didn't, than it says what is your user name and password.

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.

@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. ]

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.

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.

Today i have found same issue /FILE_NAME/ is not a working copy in morning and i have spent more then two hours to solve it. After long of RND and Google i found some solution and that is CHECKOUT.

1. CHECKOUT from SUBVERSION to local as new project.
2. Change some of code in java file and COMMIT the project.
3. It's Works for me.

Hope it will helpful for you.

I also meet this problem in svn diff operation, it was caused by incorrect file path, you should add './' to indicate the current file directory.

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.

This is what I did:

1. rename trunk to trunk_
2. create a new folder trunk
3. Re-checkout and interrupt the process after few files are checked-out
4. Move the files from trunk_ to trunk
5. Do svn cleanup
6. Do svn update. This will update the status of files and then all your files will be versioned.

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.

I tried pasting the .svn folder from the sub folder to the root folder. It works!!!

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'

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.

Delete .svn folder that is present in your local machine. Press windows icon and type .svn, delete the entire folder. It worked for me.

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.

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.

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.

I also meet this problem in svn diff operation, it was caused by incorrect file path, you should add './' to indicate the current file directory.

for mac :- take checkout from server side and a new window will open to select directory from your local machine than put your all code in selected folder then open svn local side and add and commit the project