SVN Working Copy xxx locked and cleanup failed

Question

I get this error when I do a svn update:

Working copy xxxxxxxx locked Please execute "Cleanup" command

When I run cleanup, i get

Cleanup failed to process the following paths: xxxxxx

How do i get out of this loop?

Answer 1

A lot of times this is because of one corrupt file. This happened to me when I accidentally checked in resharper files. Do you have anything funky in there?

Answer 2

Are you using TortoiseSVN and just upgraded? I've had that problem before when moving from 1.4 to 1.5 and not rebooting. (Try a reboot).

The reason you need to reboot is because the cache file gets all funky.

Otherwise, to just move on, export that working copy into a new folder (don't copy the .svn hidden folders), re-checkout the project, and move all your code back, then proceed with your commit.

Answer 3

One approach would be to:

1. Copy edited items to another location.
2. Delete the folder containing the problem path.
3. Update the containing folder through Subversion.
4. Copy your files back.
5. Commit

Another option would be to delete the top level folder and check out again. Hopefully it doesn't come to that though.

Answer 4

A colleague at work constantly sees this message, and for him it's because he deleted a directory under SVN version control without deleting it from SVN, and then created a new directory in it's place not under version control, with the same name.

IF this is your problem...

There are different ways to fix it, depending on how/why the directory was replaced.

Either way, you will likely need to:

A) Rename the existing directory to a temporary name

B) Do an SVN revert to recover the directory deleted from the file system, but not from SVN

From there, you would either

A) Copy the relevant files into the directory that was deleted

B) If you had a significant change of contents in the directory, do an SVN delete on the original, commit, and rename your new directory back to the desired name, followed by an SVN add to get that one under version control.

Answer 5

I have the same problem, and issueing the delete command won't work either because it says a file is locked. Though when I try to unlock, it says no files are locked... Luckily for me, the most recent version of all files is on a single computer, so how can I delete the entire folder including subfolders and re-commit them without errors please?

Answer 6

SVN normally updates its internal structure (.svn/prop-base) of the files in a folder before the actual files is fetched from repository. Once the files are fetched this will be cleared up. Frequently the error is thrown because the "update" failed or prematurely cancelled during the update progress.

1. Check any files are listed under .svn/prop-base directory
2. Remove any files which are not under the folder
3. Cleanup
4. Update

Now the update should work.

Answer 7

Had the same problem because I exported a folder under a version-controlled folder. Had to delete the folder from TortoiseSVN, then delete the folder from the filesystem (TortoiseSVN does not like unversioned subfolders ... why not???)

Answer 8

just delete the .svn folders, then run a cleanup on the parent directory. Works perfectly!!

Answer 9

Hi! I´ve the same problem and find a answer that help me a lot.

Try it.

look in your .svn folder, there will be a file in it called lock, delete that file and you will be able to updated. There may be more lock files in subfolders .svn directories, they will need deleting also, this could be done as a batch quite simply from the command line.

You are manually editing files in the .svn folder, they have been put there for a reason, that reason might be a mistake, but if not you could be damaging your local copies.

SOURCE : http://www.svnforum.org/2017/viewtopic.php?p=6068

Answer 10

When i have this problem, i find running the cleanup command directly on the problem path generally seems to work. Then I'll run cleanup from the working root again, and it'll complain about some other directory. and i just repeat until it stops complaining.

Answer 11

For me, the trick was to run 'svn cleanup' at the top of my working copy, not in the folder where I'd been working the whole time before the problem occurred.

Answer 12

The easiest way to do this is show hidden folders and then open the .SVN folder. You should see a zero KB file named "lock" deleting this will fix the problem

Answer 13

I had this under TortoiseSVN and the error was related to a new directory I'd created under a new project. I had just created this project, so there was no way this directory had existed before. I looked in the repository browser and the new folder was indeed already in the repository, but TortoiseSVN didn't show it as committed.

In order to get around it, since I'd just created the folder anyway, I deleted it in the repository, and then did a commit. It worked fine.

Since I did this outside of Visual Studio, I then had to restart Visual Studio for it to figure everything out again.

Answer 14

If you're on a Windows machine, View the repository through a browser and you may well see two files with the same filename but using different cases. Subversion is case sensitive and Windows isn't so you can get a lock when Windows thinks it's pulling down the same file and Subversion doesn't. Delete the duplicate file names on the repository and try again.

Answer 15

I had this problem because external folders do not want to be linked into an existing folder. If you add an svn:externals property line where the destination is an existing (versioned or non-versioned) folder, you will get the SVN Woring Copy locked error. Here a cleanup will also tell you that everthing is all right but still updating won't work.

Solution: Delete the troubling folder from the repository and make an update in the root folder where the svn:externals property is set. This will create the folder and all will be fine again.

This problem arose for me because svn:externals for files requires the destination folder to be version controlled. After I noticed that this doesn't work across different repositories, I swaped from external files to external folder and got into this mess.

Answer 16

Start Search....Lock...Select all files listed and delete..fixed

Answer 17

the following should do:

svn status | grep ". L" | sed 's/.* (.*)$/\1/' | awk '{print length($1),$1}' | sort -nr | awk '{print "pushd " $2 "; svn cleanup ; popd"}' | sh

Answer 18

Do not delete your solution!

in the .svn folder you have a file called lock it is 0 bytes long

You can delete all these files from all the .svn folders in your solution and it will work

It worked in my case

Answer 19

Good Solution!

don't have any problem

Answer 20

If you're on linux, try this:

find "/the/path/to/your/directory" -name .svn -type d | xargs chmod 0777 -R

Then run the cleanup command on that directory, then try to update.

Answer 21

@Chuck's solution wasn't practical for me. In the first time I had the problem, it worked but also gave lots extra-work. In the second case, I changed loads of file while I was using my notebook outside the network. I couldn't see myselft going folder by folder after the changed files. Had hope on tortoise and worked. See how:

Environment Was:

1. Visual Studio 2008
2. Ankhsvn

Procedure:

1. First I couldn't commmit, it said that I needed to clean up
2. Second, I couldn't clean up, there was a folder out of the svn - "bin"
3. I downloaded Tortoise lastest version, tried and doesn't work due to dammed folder.
4. Renamed that folder and now I could Update the local repository with the lasted version.
5. A couple of files came in.
6. Did the commit and worked.