SVN Error - Not a working copy

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

WARNING: rm -rf deletes the folder content permanently. Backup before executing it

If you get a not a working copy error, it means that Subversion cannot find a proper .svn directory in there. Check to see if there is an .svn directory in contents

The ideal solution is a fresh checkout, if possible.

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.

I solved it by

Copy a backup of the impacted folders SVN revert the impacted folders Paste the files back from the backup

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

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.

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'

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.

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.

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

Moved the old folder out, Copied the new one 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 tried pasting the .svn folder from the sub folder to the root folder. It works!!!

This is what I did:

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

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.

facing the same error when trying to checout parts of sources from a large svn project

svn co --depth empty svn://tug.org/texlive/trunk/Build
cd Build
svn update --set-depth infinity --parents ./source/texk/web2c

here the --parents is the key to make it success

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.

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.

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

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.

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

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.

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

Hope it will helpful for you.

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

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.

I had this exact error. I noticed that I was in the wrong directory. Once I reverted to the SVN Trunk directory the issue was resolved.

I saw this error when I was performing mvn release:prepare on my code. In my case, I had migrated the project from SVN to Github, and had cloned the source code from Github. But in my pom.xml file, I missed to update the SCM location from SVN URL to Github URL, which caused the mismatch between the working directories.

Correcting URL to the Github location helped solve it for me.

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