Working copy XXX locked and cleanup failed in SVN

I get this error when I do an svn update:

> Working copy XXXXXXXX locked Please > execute "Cleanup" command

When I run cleanup, I get

> Cleanup failed to process the > following paths: XXXXXXXX

How do I get out of this loop?

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 or merge changes as needed.
5. Commit

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

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.

Look in your .svn folder, there will be a file in it called lock. Delete that file and you will be able to update. There may be more lock files in the .svn directory of each subdirectory. They will need deleting also. This could be done as a batch quite simply from the command line with e.g.

find . -name 'lock' -exec rm -v {} \;

Note that 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 copy.

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

In my case I solved it by manually deleting a record in the SQLite ".svn\wc" file lock record in the WC_LOCK table.

I opened the "WC" file with SQLite editor and executed

delete from WC_LOCK

Following eakkas's comment, you might need to delete all the entries from WORK_QUEUE table as well.

Easiest way ever:

1. Go to Parent directory(Folder) of Project.
2. Pres Right click
3. Press on TortoiseSVN then Press Clean up...
4. Clean up dialog would appear automatically
5. Select Clean up working copy status, Break locks, Fix time stamps, Vacuum pristine copies, Refresh shell overlays, Include externals
6. Pres OK

You did your job successfully.

Check the screen shots for your reference.

First step:

Second step: Enable the Break lock option(second check box in cleanup popup window)

Hope this will help you a lot.

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

For me none of the above solutions worked. I found a solution by breaking locks. When I performed svn cleanup, I selected "Break Locks" along with "Clean up working copy status".

This one worked for me.

1. Go to the root folder,
2. Right click and cleanup
3. Check all available options
4. Press ok

After clean up it will allow you to update to the latest version.

For me, it was actually Tortoise's fault, sort of. Tortoise just complained "cannot clean up, run clean up", but when I ran the command line (svn cleanup), it clearly told me that it couldn't delete some files that were in use, the solution to which was obvious. Once I closed Visual Studio (which was keeping the files open), then the cleanup worked fine.

Other programs can also keep files open in the repo causing this issue. Excel holding an xls open was a culprit in another instance so it may be wise to close all programs that may be using anything in the repo or even rebooting to force programs to close out and then trying cleanup again.

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.

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

I came across the exact same issue using SVN 1.7 and none of the fixes mentioned above worked.

Foremost, make sure you backup all your edited content.

After spending a couple of hours (didn't redownload everything as my branch is over 6gb in size), I found that there is a db file called "wc" in the .svn folder of your branch.

Open up the db file using any db manager (i used firefox's sqlite manager plugin) and navigate to WC_LOCK table. This table will have the entries for the acquired locks. Delete the records from the table and you're done :)

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.

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.

I did it by just creating a new folder, checking out the project, copying the updated files to the new folder.

It was fixed with a fresh checkout.

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.

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

In Versions under Mac OS: Action -> Cleanup working copy locks at...

I often get such an issue. My pattern that causes cleanup problems.

1. I open image file in viewer.
2. I delete image file/folder.
3. I am trying to commit/update

Closing image viewer where deleted file is opened solves the problem. Maybe other software can block cleanup the same way.

In general. I believe restarting computer may help in such cases.

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.

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

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.

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

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

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

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.

In-place unversioning of the files, and a fresh checkout into the same location, has solved this problem for me.

In TortoiseSVN, to do an in-place unversioning, right-drag the root folder of the working copy from the file list onto itself in the directory tree, and choose "SVN Export versioned items here" from the pop-up menu. TortoiseSVN notices that the destination is the same as the source, and suggests unversioning the working copy.

After unversioning, do a fresh checkout into the same folder (which now contains an unversioned copy of all the files you had). TortoiseSVN will warn you that you are checking out into an existing folder, but you can go ahead.

After this, cleanups, updates and other operations worked without a hitch. Since both of the above steps preserve local modifications, there should not be any loss of information (but backing the working copy up before this may nevertheless be a good idea).

One warning: If the working copy contains mixed versions or uncommitted property changes, that information WILL be lost. For me, this is not a common occurrence, and given the choice of a corrupt working copy or losing uncommitted property changes, I tend to opt for the latter.

I had this problem where the "clean up" worked, but the "update" would continue to fail. The solution that worked was to delete the folder in question via Windows Explorer, not TortoiseSVN's delete (which marks the deletion as something to commit to the repository, and then I did a "checkout" to essentially "update" the folder from the respository.

More info on the difference between an O/S delete and an SVN delete here: http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-rename.html

Notably:

> When you TortoiseSVN → Delete a file, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit.

And:

> If a file is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those files and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing file and replace it with the latest version from the repository.

I did the following to fix my issue:

1. Renamed the offending folder by placing an "_" in front of the folder name.
2. Did a "Clean Up" of the parent folder.
3. Renamed the offending folder back to it original name.
4. Did a commit.

In solution explorer, right click on the project, in the opening sub-menu click on subversion and select clean-up. It will solve the problem, as it did for me. Hope it will work.

To do the clean up

1. Delete the .svn folder.

2. Do the svncheckout in the root folder.

3. Try performing the clean up operation.

This got my issue resolved.

For me, the problem was with completely full disk drive (linux inodes in my case), when i deleted some folders it started working again.

The error was the following (on any svn action):

$ svn cleanup
svn: E155004: Run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)
svn: E155004: Working copy locked; try running 'svn cleanup' on the root of the working copy ('/my/directory') instead.
svn: E155004: Working copy '/my/directory' locked
svn: E200030: sqlite[S14]: unable to open database file
svn: E200030: Additional errors:
svn: E200030: sqlite[S14]: unable to open database file

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

I had a file in my root directory that was messing it up. (No lock files, svn cleanup failed, etc.) My whole checkout is > 2GB with slow network speeds, so checking everything out again wasn't a great option for me.

What worked for me:

1. Reverted & reverted change in the messed up working copy (#1).
2. Checked out another copy of the repo (#2) with --depth empty
3. Added and committed the file in the new working copy (#2).
4. Updated in the original working copy (#1).

Seemed to be back to normal for me.

Updating the directory permissions (granting write access) solves the problem as well.

chmod +w <dir_name>

I had the same problem. Seems it has been fixed in the latest versions. I have updated my Tortoise SVN to the latest version (1.7.11) and clean up has worked well.

You can download the latest version here: downoad tortoise svn.

I know this is a really old thread but I maintain that:

The easiest and safest method to fix this is to delete your hidden ".svn" folder and check everything out again.

It fixes most problems when svn screws around should keep local changes (marked as "conflicted") when you check out the head revision again.

Clean up certainly is not enough to solve this issue sometimes.

If you use TortoiseSVN v1.7.2 or greater, right click on the Parent directory of the locked file and select TortoiseSVN -> Repo Browser from the menu. In the Repro Browser GUI right click the file that is locked and there will be an option to remove the lock.

Steps :

1. Close all editing files from svn folder

2. Close eclipse or any editor which are using folder or file from svn directory.

3. Right click on svn check out folder and click on release lock.

4. Right click on svn check out folder and click on clean.

5. Your SVN is ready for SVN commit and update operation.

Cheers :)

Today I have experienced above issue saying

> svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details)

And here is my solution, got working

1. Closed Xcode IDE, from where I was trying to commit changes.
2. On Mac --> Go to Terminal --> type below command

> svn cleanup <Dir path of my SVN project code>

exmaple:

svn cleanup /Users/Ramdhan/SVN_Repo/ProjectName

3. Hit enter and wait for cleanup done.
4. Go To XCode IDE and Clean and Build project
5. Now I can commit my all changes and take update as well.

Hope this will help.

One reason for this problem I haven't seen in the answers is that an update or checkout may have been done with other user/permissions, like for example with $sudo.

First of all tried many solutions, then I just deleted the folder in which I was having trouble.

And then performed SVN Update.

That worked for me.

I would not recommend it, but nothing worked but this. :(

While doing svn update using tortoise svn, the process got interrupted and stopped complaining the file is in use. Next it asked me to use CleanUp command on the folder. I tried to run CleanUp command but it failed to do so. Then I found a command shell which was using the folder files. So, I closed the command shell and checked if any editor is using the files related to it. We need to close them as well. Again, I tried CleanUp on the folder with options Break locks,revert changes,clear working copy status . The CleanUp went successfully. Then finally able to update my svn folder.

The clean up did not work for me no matter how many ways I tried. Instead from Visual Studio I committed each folder individually. Then I committed the top folder and was successful.

As exactly this answer is not listed here: my solution was to close my IDE (in this case Netbeans). Seems like the IDE had locked the file.

Spotlight is its usual rubbish self at finding the lock files recursively.

EasyFind on Mac App Store works

http://itunes.apple.com/gb/app/easyfind/id411673888?mt=12

search for 'lock'

Select all / Delete

These types of problems can be avoided in the first place by using svn copy and svn move etc commands when making changes to your project structure. Remember svn only checks for changes inside files already added to subversion, not changes to the physical directory structure. Please see http://svnbook.red-bean.com/en/1.7/svn.tour.cycle.html

Further, upon committing changes svn first stores a "summary" of changes in a todo list. Upon performing the svn operations in this todo list it locks the file to prevent other changes while these svn actions are performed. If the svn action is interrupted midway, say by a crash, the file will remain locked until svn could complete the actions in the todo list. This can be "reactivated" by using the svn cleanup command. Please see http://svnbook.red-bean.com/en/1.7/svn.tour.cleanup.html

In my case, a Windows 7 machine running TortoiseSVN failed to rename a folder completely. No combination of cleanup, update, or rename operations would fix the problem. The folder was originally created with different case and Tortoise or Subversion would not change it to what was in the repository.

My solution was to:

1. Copy the folder through Windows Explorer (without Subversion control files) outside the project.
2. Delete and commit the folder through TortoiseSVN.
3. Copy the folder back with the correct (current) name through Windows Explorer.
4. Add the folder back into the repository through TortoiseSVN.

I performed cleanups after each step. Dreadful solution, but it worked for me.

I am sure It working fine for you

Goto top level SVN folder.

Right Click on folder(that has your svn files) -> TortoiseSVN -> CleanUp

This will surely solve your problem.