Working copy XXX locked and cleanup failed in SVN

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.

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

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.

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

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.

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

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

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

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.