SVN Error - Not a working copy

Svn

Svn Problem Overview

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 ?

Svn Solutions

Solution 1 - Svn

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.

Solution 2 - Svn

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.

Solution 3 - Svn

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.

Solution 4 - Svn

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.

Solution 5 - Svn

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'

Solution 6 - Svn

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.

Solution 7 - Svn

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.

Solution 8 - Svn

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.

Solution 9 - Svn

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

Solution 10 - Svn

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.

Solution 11 - Svn

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.

Solution 12 - Svn

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

Solution 13 - Svn

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

Solution 14 - Svn

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.

Solution 15 - Svn

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.

Solution 16 - Svn

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

Solution 17 - Svn

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.

Solution 18 - Svn

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

Solution 19 - Svn

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.

Solution 20 - Svn

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.

Solution 21 - Svn

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

Solution 22 - Svn

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.

Solution 23 - Svn

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.

Solution 24 - Svn

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.

Solution 25 - Svn

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

Categories
Recommended Svn Solutions

Previous Solution:

How to build query string with Javascript

JavascriptStringFormsGet

Next Solution:

When to use a linked list over an array/array list?

ArraysListArraylistLinked List

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionVijay DevView Question on Stackoverflow
Solution 1 - SvnJesperEView Answer on Stackoverflow
Solution 2 - SvnKen ArnoldView Answer on Stackoverflow
Solution 3 - SvnStaffan LundstromView Answer on Stackoverflow
Solution 4 - SvnHextlerView Answer on Stackoverflow
Solution 5 - SvnabatishchevView Answer on Stackoverflow
Solution 6 - SvnHenryFView Answer on Stackoverflow
Solution 7 - SvnAlexLaView Answer on Stackoverflow
Solution 8 - SvnarieltoolsView Answer on Stackoverflow
Solution 9 - SvnnavinView Answer on Stackoverflow
Solution 10 - SvnShaunak SontakkeView Answer on Stackoverflow
Solution 11 - SvnArmstrongyaView Answer on Stackoverflow
Solution 12 - SvnmindonView Answer on Stackoverflow
Solution 13 - SvnJesperEView Answer on Stackoverflow
Solution 14 - SvnagnulView Answer on Stackoverflow
Solution 15 - SvnSamikshaView Answer on Stackoverflow
Solution 16 - SvnalastairsView Answer on Stackoverflow
Solution 17 - SvnTwoayemView Answer on Stackoverflow
Solution 18 - SvnRaviPatidarView Answer on Stackoverflow
Solution 19 - SvnChintan KhetiyaView Answer on Stackoverflow
Solution 20 - SvnSamirView Answer on Stackoverflow
Solution 21 - SvnJuanView Answer on Stackoverflow
Solution 22 - SvnRamesh JayaView Answer on Stackoverflow
Solution 23 - SvnsqrepantsView Answer on Stackoverflow
Solution 24 - SvnPavan KailashView Answer on Stackoverflow
Solution 25 - SvnBhuvanaView Answer on Stackoverflow