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

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

Answer 4

/*

I ran into a similar problem. The suggestion to use svn cleanup was useless, because cleanup gave the same error (a recursive one, in this case). Eventually, I realized that I had imported a workspace checked out from a remote repo into my local one, so I replaced the checkout with an export, deleted the repo path, recreated it, and checked it in. After one failed checkout, caused by the ambiguity of path levels on both the sending and receiving end (!), I was able to checkout with no problems. This suggests to me that maybe the old .svn components were part of the import and were confusing subversion, and it didn't know enough to ignore them. Every time I try to create a repository, it's a relearning experience.

*/

Never mind. I made the following mistakes: 1) edited the export command, not the checkout one; 2) omitted the full path from the destination and ended up in a cygwin subdirectory hidden from Windows!