SVN says I need to perform cleanup, but the cleanup fails.

Question

!!! This is not a duplicate question since the solutions offered in the other topics didn't work for me.

When I try to commit:

Error: Working copy 'D:\Webs\Drupal 6' locked
Error: Please execute the "Cleanup" command.

When I try to do a cleanup:

Cleanup failed to process the following paths: D:\Webs\Drupal 6

Does anyone know how I can solve this problem?

Answer 1

Does it work if you do

• a new "clean" checkout
• merge the files that you have modified into the new checkout folder(s) using a merge / diff tool
• commit

?

EDIT: Updated point 2 according to derobert comment.

Answer 2

If you haven't modified D:\Webs\Drupal 6, then the easiest thing might just be to nuke it, then let svn co grab it from the server again.

Or, if you have modified files, you can try divo's suggestion, but beware of accidentally reverting other people's changes.

Or, you could look inside the .svn directories and try to clean the locks out by hand.

EDIT: Here is how the nuke/copy procedure can revert other people's changes:

1. Checkout, get r1;
2. Modify foo.c, giving r1 + changes;
3. Someone else checks in a change to foo.c (you don't know they've done this, of course, and the normal way of checking is broken for you), foo.c in the repo is now r2;
4. You now nuke your repository except foo.c (r1 + changes);
5. You do a checkout, get foo.c r2.
6. You replace foo.c with your copy (r1 + changes). Subversion, however, is unaware of this, and thinks you based your changes on r2, not r1.
7. Checkin, foo.c is now r3, which has just lost the other person's changes in r2.

Hope that clarifies how that procedure can accidentally revert other people's changes. It can be avoided, but only if you're aware of how it can happen!

Answer 3

THis stupid bug has been around for a year and keeps wasting my time. how rediculous.

Answer 4

I just went through and deleted all the relevant .svn folders, and then ran a cleanup. works perfectly!