Mercurial stuck “waiting for lock”

Question

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
wai         


        

Answer 1

I am very familiar with Mercurial's locking code (as of 1.9.1). The above advice is good, but I'd add that:

1. I've seen this in the wild, but rarely, and only on Windows machines.
2. 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.)

Answer 2

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.

Answer 3

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

Answer 4

I had the same problem. Got the following message when I tried to commit:

waiting for lock on working directory of <MyProject> 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.

Answer 5

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

Answer 6

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