Commit failed: already locked

Question

I just tried to add & commit about 25,000 files to VisualSVN using TortoiseSVN.

The commit dialog locked up (to be expected I guess), but after a while of the thread being blocked, I killed Tortoise, hoping to commit smaller chunks of files at a time.

Now I get this error:

Error: Commit failed (details follow):

Working copy 'C:\INTERNAL\Icons\Oxygen 4.10.1' locked.

'C:\INTERNAL\Icons\Oxygen 4.10.1\scalable\places\PaxHeaders.14455' is already locked

I've killed TortoiseProc.exe and restarted VisualSVN a couple of times, but I'm still getting the error.

I've also right-clicked the folder and chose Release lock, but I get:

There's nothing to unlock. No file has a lock in this working copy.

When I run svn st, I get a huge long output of all the files waiting to be added.

Even when I try to commit something unrelated (a couple of dirs up), I get the same error.

I am able to commit successfully to a separate repo on the same server.

How can I release the lock and commit these files?

Solution 1

Try doing a SVN Cleanup. I had the same issue and after doing that the locks cleared up.

Specifically from the Tortoise SVN Cleanup Documentation:

If a Subversion command cannot complete successfully, perhaps due to server problems, your working copy can be left in an inconsistent state. In that case you need to use TortoiseSVN → Cleanup on the folder. It is a good idea to do this at the top level of the working copy.

In the cleanup dialog, there are also other useful options to get the working copy into a clean state.

Clean up working copy status As stated above, this option tries to get an inconsistent working copy into a workable and usable state. This doesn't affect any data you have but only the internal states of the working copy database. This is the actual Cleanup command you know from older TortoiseSVN clients or other SVN clients.

Here is a screenshot of the recommended SVN Cleanup options:

Solution 2

Just a small addition to Jordan's answer, I had the same issue but cleanup on the offending folder was failing due to the lock. To fix it I had to do an SVN cleanup on the parent directory, then on the offending directory.

Solution 3

If you use svn on eclipse try clean up but it will fail I guess so install Tortoise then clean up with break locks checked

Comments

[Leo Chapiro]

Have you already tried svn cleanup ?

[Developer]

If cleanup didn't works you need to have a fresh checkout

[jordanhill123]

@DannyBeckett Those are the ones that I chose for mine. That is the minimalist approach so see if that works. Should be all you need.

[Danny Beckett]

Will this affect any other files that are waiting to be committed? I.e. unrelated files that are newer in the WC than the SVN server (files with a red x, instead of a green check mark).

[jordanhill123]

@DannyBeckett The Revert and Delete Options could cause the loss of changes in your local copy if they aren't in SVN so avoid those. It will not affect the content, using that option, it will just cleanup the svn cached data in the _SVN folder to my knowledge.

[jordanhill123]

@DannyBeckett It just cleans up the Status of the Working Copy as stored in the _SVN local file and doesn't change the content of your working copy

[Danny Beckett]

Thanks Jordan. I did the cleanup, then tried to commit 1 subdir - failed with a different error. Tried a few other things, like deleting/updating etc - different errors again. Now I'm doing the full commit of the affected folder, and it seems to be committing ok. I'll accept if all goes well; thanks for your help! :)

[jordanhill123]

@DannyBeckett Make sure to do the cleanup on the affected folder(s) and not a sub directory. SVN only applies the cleanup to the folder from which Cleanup was selected and below and not the full checkout.

[Danny Beckett]

Yeah that's what I did cheers... still committing, almost done. So it looks as though this worked!

[Danny Beckett]

That worked - now my repo is all back in order sigh of relief - thanks again Jordan!

[zeeshan]

I don't use Tortoise, but same clean up option worked for me.