What causes the SVN Error "Not a working copy"?

Question

Recently our Subversion (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 topmost level of the repository, when I try to update files, I get an error that says svn: Working copy '.' locked. Trying to do cleanup does not help either; it causes errors like svn: 'content' is not a working copy directory.

A fresh checkout is not an option at all. How else can I clean up and release the locks and complete the svn switch process?

for R users encountering this error: https://github.com/wch/r-source/wiki#adding-svn-information — isomorphismes, Feb 21 '19 at 05:08

score 132 · Accepted Answer · edited Jan 15 '23 at 09:51

132

If you get a "not a working copy" when doing a recursive svn cleanup, you likely have a subdirectory which should be a working copy (i.e. the .svn directory at the top level says so), but the subdirectory is missing its own .svn directory.

In that case, you could move or delete that directory and then do a local update. To delete the directory,

rm -rf content
svn checkout content

WARNING: rm -rf deletes the folder content permanently.

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

The ideal solution is a fresh checkout, if possible.

edited Jan 15 '23 at 09:51

Dietrich Epp

205,541
37
345
415

answered Dec 17 '08 at 11:59

JesperE

63,317
21
138
197

1

I agree, do a fresh checkout instead of trying to move your working copy with the repo. – Tigraine Dec 17 '08 at 12:00
2

My problem is that I've migrated to a new server and restored my backups of the filesystem with work not yet committed, and used svnadmin to filter out old projects I no longer need. So my repository contains all the info I need, but has a new UUID. In this case, I'm just going to tar up the changed files, get a fresh checkout, and then untar. – Drarok Aug 28 '09 at 15:21
Your suggestion in first paragraph does not work on my system (W7+Cygwin). Rather rm & svn update did it. – Jukka Dahlbom May 02 '12 at 12:54
19

**WARNING:** `rm -rf` deletes the folder `content` permanently. Take a backup before executing it. – KrishPrabakar Mar 13 '15 at 09:51

score 48 · Answer 2 · answered Jun 01 '09 at 21:16

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.

score 6 · Answer 3 · answered Jan 20 '10 at 15:11

6

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.

answered Jan 20 '10 at 15:11

Staffan Lundstrom

61
1
1

How to do it ? Please explain in brief – Anand Savjani Jun 29 '15 at 06:49

score 5 · Answer 4 · edited Oct 08 '12 at 09:55

5

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.

edited Oct 08 '12 at 09:55

Himanshu

31,810
31
111
133

answered Oct 08 '12 at 09:50

Hextler

59
1
1

score 3 · Answer 5 · answered Dec 28 '09 at 02:40

3

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.

answered Dec 28 '09 at 02:40

HenryF

31
1

score 3 · Answer 6 · edited Feb 02 '23 at 21:18

3

Workaround:

Rename the directory which is not the 'working copy'. Check out/update/restore this directory again. Move files from the renamed directory to a new one. Commit changes.

Reason:

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

edited Feb 02 '23 at 21:18

Peter Mortensen

30,738
21
105
131

answered Dec 17 '08 at 13:21

abatishchev

98,240
88
296
433

1

@peter-mortensen a passive-aggressive edit of 15-years old response, huh? thanks for the edit itself and for a link with the exact timing too. but it wasn't really necessary :-P – abatishchev Feb 03 '23 at 22:20
1

Wow: he did it to almost every answer/comment here... Wikipedia hyperlinks etc. Reputation/point farming on 15 year old threads. – Andy Needham Feb 22 '23 at 12:06

score 1 · Answer 7 · answered Dec 01 '09 at 13:08

1

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.

answered Dec 01 '09 at 13:08

AlexLa

11
1

Re *"Automouter on Unix"*: Can you be more specific? What Unix and what [desktop environment](https://en.wikipedia.org/wiki/Desktop_environment)? – Peter Mortensen Feb 02 '23 at 21:32
OK, the OP has left the building: *"Last seen more than 13 years ago"* – Peter Mortensen Feb 02 '23 at 21:32

score 1 · Answer 8 · answered Feb 05 '14 at 13:52

1

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

answered Feb 05 '14 at 13:52

navin

11
1

score 1 · Answer 9 · answered Mar 05 '14 at 10:14

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.

score 1 · Answer 10 · edited Feb 02 '23 at 21:52

1

I also met this problem in a svn diff operation. It was caused by an incorrect file path. You should add './' to indicate the current file directory.

edited Feb 02 '23 at 21:52

Peter Mortensen

30,738
21
105
131

answered May 20 '14 at 07:36

Armstrongya

795
1
6
9

Re *"current file directory"*: Do you mean current working directory? – Peter Mortensen Feb 02 '23 at 21:52

score 1 · Answer 11 · answered Mar 06 '10 at 16:20

1

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.

answered Mar 06 '10 at 16:20

arieltools

1,136
3
15
21

Found this about 4 hours into SVN cleanup using the Eclipse plugin - good times! Working copy is locked - no it's not, come up with a better message Eclipse people, thanks. – Darth Jon May 20 '15 at 20:29

score 1 · Answer 12 · edited Feb 02 '23 at 22:23

1

I was facing the same error when trying to check out 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 a success.

edited Feb 02 '23 at 22:23

Peter Mortensen

30,738
21
105
131

answered Sep 08 '21 at 09:53

mindon

318
4
13

score 0 · Answer 13 · edited Feb 02 '23 at 21:50

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

svn: '.' is not a working copy directory

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

score 0 · Answer 14 · edited Feb 02 '23 at 22:06

0

For Mac: take a checkout from the server side and a new window will open to select the directory from your local machine. Then put all your code in the selected folder. Then open the SVN local side. Add and commit the project.

edited Feb 02 '23 at 22:06

Peter Mortensen

30,738
21
105
131

answered Jul 16 '15 at 09:44

RaviPatidar

1,438
1
18
29

Re *"take a checkout from the server side and a new window will open"*: What SVN client? – Peter Mortensen Feb 02 '23 at 22:06

score 0 · Answer 15 · edited Feb 02 '23 at 22:05

0

Today I have found the same issue, /FILE_NAME/ is not a working copy, in the morning, and I have spent more than two hours to solve it. After a long of RND and Google I found some solution and that is Checkout.

Checkout from Subversion to local as a new project.
Change some of code in a Java file and Commit the project.
It works for me.

edited Feb 02 '23 at 22:05

Peter Mortensen

30,738
21
105
131

answered Nov 17 '15 at 07:31

Chintan Khetiya

15,962
9
47
85

score 0 · Answer 16 · edited Feb 02 '23 at 21:12

0

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

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

edited Feb 02 '23 at 21:12

Peter Mortensen

30,738
21
105
131

answered Dec 17 '08 at 12:22

JesperE

63,317
21
138
197

Changing uuid on the server - How to do this ? – Vijay Dev Dec 17 '08 at 12:31
Honestly, I have no idea, I just assume that it can be done. Have you checked in the Subversion Book says anything about it? – JesperE Dec 17 '08 at 19:26

score 0 · Answer 17 · edited Feb 02 '23 at 21:13

0

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

edited Feb 02 '23 at 21:13

Peter Mortensen

30,738
21
105
131

answered Dec 17 '08 at 12:27

agnul

12,608
14
63
85

score 0 · Answer 18 · edited Feb 02 '23 at 21:14

0

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.

edited Feb 02 '23 at 21:14

Peter Mortensen

30,738
21
105
131

answered Dec 17 '08 at 12:57

Samiksha

6,122
6
29
28

score 0 · Answer 19 · edited Feb 02 '23 at 22:04

0

Recently I was using another developer's Mac. I had the same situation. The problem was; first I needed to type get repository path in the terminal, but I didn't. Then it says what is your user name and password.

edited Feb 02 '23 at 22:04

Peter Mortensen

30,738
21
105
131

answered Jun 25 '18 at 11:28

Samir

6,405
5
39
42

What ***exactly*** did you type? Can you provide an example? – Peter Mortensen Feb 02 '23 at 22:05
unfortunately so many times passed, I am not able to remember sorry – Samir Feb 03 '23 at 08:24

score 0 · Answer 20 · edited Feb 02 '23 at 22:08

I just ran into a case where the .svn directory is on an 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

score 0 · Answer 21 · edited Feb 02 '23 at 22:10

0

I made a new checkout from the same project to a different location, copied the .svn folder from it, and replaced it with my old .svn folder.

After that I called the svn update function and everything were synced properly up to date.

edited Feb 02 '23 at 22:10

Peter Mortensen

30,738
21
105
131

answered Sep 17 '19 at 08:23

Ramesh Jaya

671
1
10
16

What do you mean by *"called the svn update function"*? On the command line? Or in some SVN client? Which one? – Peter Mortensen Feb 02 '23 at 22:10

score 0 · Answer 22 · edited Feb 03 '23 at 02:19

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 Managing Repository UUIDs.

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-around :-)

score 0 · Answer 23 · answered Nov 26 '21 at 15:43

0

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.

answered Nov 26 '21 at 15:43

sqrepants

996
2
10
22

score 0 · Answer 24 · edited Feb 02 '23 at 22:15

0

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.

edited Feb 02 '23 at 22:15

Peter Mortensen

30,738
21
105
131

answered Feb 07 '22 at 17:40

Pavan Kailash

31
2

`mvn` and `pom.xml` implies [Maven](https://en.wikipedia.org/wiki/Apache_Maven). – Peter Mortensen Feb 02 '23 at 22:19

Bhuvana · Answer 25 · 2023-03-27T06:39:47.563

-1

Delete the .svn folder that is present in your local machine. Press the windows icon if it is a

windows machine

and type .svn, delete the entire folder. It worked for me.

edited Mar 27 '23 at 06:39

answered Aug 08 '16 at 11:04

Bhuvana

47
3

Re *"Press the windows icon"*: In what context? This question is not tagged with any particular platform or SVN client. – Peter Mortensen Feb 02 '23 at 22:01

What causes the SVN Error "Not a working copy"?

25 Answers25

Linked

Related