Got a bluescreen in windows while cloning a mercurial repository After reboot I now get this message for almost all hg commands c src hg commit waiting for lock on repository c src McVrsServer held by x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 x00 interrupted Google is no help Any tips

I had the same problem on Win 7 The solution was to remove following files hg store phaseroots hg wlock As for hg store lock - there was no such file

I encountered this problem on Mac OS X 10 7 5 and Mercurial 2 6 2 when trying to push After upgrading to Mercurial 3 2 1 I got no changes found instead of waiting for lock on repository I found out that somehow the default path had gotten set to point to the same repository so it s not too surprising that Mercurial would get confused

If it only happens on mapped drives it might be bug https bitbucket org tortoisehg thg issue 889 cant-commit-file-over-network-share Using UNC path instead of drive letter seems to sidestep the issue

When waiting for lock on repository delete the repository file hg wlock or it may be in hg store lock When deleting the lock file you must make sure nothing else is accessing the repository If the lock is a string of zeros or blank this is almost certainly true

I am very familiar with Mercurial s locking code as of 1 9 1 The above advice is good but I d add that I ve seen this in the wild but rarely and only on Windows machines Deleting lock files is the easiest fix BUT you have to make sure nothing else is accessing the repository If the lock is a string of zeros this is almost certainly true For the curious I haven t yet been able to catch the cause of this problem but suspect it s either an older version of Mercurial accessing the repository or a problem in Python s socket gethostname call on certain versions of Windows

Coworker had this exact problem today after a BSoD while trying to push He had to delete the file hg store lock as per the accepted answer delete the file hg store phaseroots as per this TortoiseHG bug report Then his repo worked again EDIT As per Marmoute s comment - when dealing with lock-related issues using hg debuglock is a safer alternative to blindly deleting the hg store lock file

I had this problem with no detectable lock files I found the solution here http schooner uwaterloo ca twiki bin view MAG HgLockError Here is a transcript from Tortoise Hg Workbench console hg debuglocks lock user None process 7168 host HPv32 114213199s wlock free command returned code 1 Sat Jan 07 18 00 18 2017 hg debuglocks --force-lock command completed successfully Sat Jan 07 18 03 15 2017 cmdserver Process crashed PaniniDev hg debuglocks hg debuglocks lock free wlock free command completed successfully Sat Jan 07 18 03 30 2017 After this the aborted pull ran sucessfully The lock had been set more than 2 years ago by a process on a machine that is no longer on the LAN Shame on the hg developers for a not documenting locks adequately b not timestamping them for automatic removal when they get stale

I do not expect this to be a winning answer but it is a fairly unusual situation Mentioning in case someone other than me runs into it Today I got the waiting for lock on repository on an hg push command When I killed the hung hg command I could see no hg store lock When I looked for hg store lock while the command was hung it existed But the lockfile was deleted when the hg command was killed When I went to the target of the push and executed hg pull no problem Eventually I realized that the process ID on the hg push was lock waiting message was changing each time It turns out that the hg push was hanging waiting for a lock held by itself or possibly a subprocess I did not investigate further It turns out that the two workspaces let s call them A and B had hg trees shared by symlink A hg --symlinked-to-- gt B hg This is NOT a good thing to do with Mercurial Mercurial does not understand the concept of two workspaces sharing the same repository I do understand however how somebody coming to Mercurial from another VCS might want this Perforce does although not a DVCS the Bazaar DVCS reportedly can do so I am surprised that a symlinked REP-ROOT hg works at all although it seems to except for this push

I had the same problem Got the following message when I tried to commit waiting for lock on working directory of lt MyProject gt held by hg debuglock showed this lock free wlock 66722s So I did the following command and that fixed the problem for me hg debuglocks -W Using Win7 and TortoiseHg 4 8 7

If the locked repo was the original I can t imagine it was modifying it to clone it so it was only preventing you from changing it in the middle and messing up the clone It should be fine after removing the lock The new cloned copy if it was a local clone could be in any sort of malformed state though so you should throw it out and start it over If it was a remote clone I would hope it failed and already threw out the incomplete copy

[mercurial] Mercurial stuck "waiting for lock"

I had the same problem on Win 7. The solution was to remove following files:

.hg/store/phaseroots
.hg/wlock

As for .hg/store/lock - there was no such file.

Examples related to mercurial

• Convert Mercurial project to Git • Mercurial: how to amend the last commit? • Discard all and get clean copy of latest revision? • Mercurial undo last commit • How to save username and password with Mercurial? • Mercurial — revert back to old version and continue from there • Is there any way to delete local commits in Mercurial? • How to correctly close a feature branch in Mercurial? • How can I switch to a tag/branch in hg? • What is the difference between hg forget and hg remove?