Mercurialが「ロック待ち」で立ち往生

Mercurialリポジトリのクローンを作成しているときに、ウィンドウにブルースクリーンが表示されました。

再起動後、ほぼすべてのhgコマンドに対して次のメッセージが表示されます。

c：\ src \> hg commit
'\ x00 \ x00 \ x00 \ x00 \ x00 \によって保持されているリポジトリc：\ src \ McVrsServerのロックを待機しています
x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 '
中断されました！

Googleは役に立ちません。

任意のヒント？

「リポジトリのロックを待っている」ときに、リポジトリファイルを削除します.hg/wlock（またはにある可能性があります.hg/store/lock）

ロックファイルを削除するときは、他にリポジトリにアクセスしていないことを確認する必要があります。（ロックがゼロまたはブランクのストリングである場合、これはほぼ確実に当てはまります）。

ときwaiting for lock on working directory、削除し.hg/wlockます。

検出可能なロックファイルがないため、この問題が発生しました。私はここで解決策を見つけました：http : //schooner.uwaterloo.ca/twiki/bin/view/MAG/HgLockError

これはTortoise Hg Workbenchコンソールからのトランスクリプトです

% 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]

この後、中止されたプルは正常に実行されました。

ロックは2年以上前に、LAN上にないマシン上のプロセスによって設定されていました。a）ロックを適切に文書化していないことに対するhg開発者の恥。b）古くなったときに自動的に削除するためにタイムスタンプを付けない。

同僚は、プッシュしようとしている間のBSoDの後で、この正確な問題を今日抱えていました。彼はしなければならなかった：

• ファイルを削除します.hg/store/lock（承認された回答に従って）
• ファイルを削除します.hg/store/phaseroots（このTortoiseHGバグレポートに従って）

それから彼のレポは再び働いた。

編集： @Marmouteのコメントによる-ロック関連の問題を処理する場合hg debuglock、.hg/store/lockファイルを盲目的に削除するより安全な方法はを使用することです。

Mercurialのロックコードに精通しています（1.9.1以降）。上記のアドバイスは良いですが、私はそれを追加します：

1. 私はこれを実際に目にしたことがありますが、まれにWindowsマシンでのみ見られます。
2. ロックファイルを削除するのが最も簡単な修正ですが、他にリポジトリにアクセスしていないことを確認する必要があります。（ロックがゼロのストリングである場合、これはほぼ確実に当てはまります）。

（奇妙なことに、私はまだこの問題の原因を把握できていませんが、古いバージョンのMercurialがリポジトリにアクセスしているか、特定のバージョンのWindowsでのPythonのsocket.gethostname（）呼び出しの問題であると思われます。）

Win 7でも同じ問題が発生しました。解決策は次のファイルを削除することでした。

1. .hg / store / phaseroots
2. .hg / wlock

.hg / store / lockに関しては-そのようなファイルはありませんでした。

これが勝者となるとは思いませんが、かなり珍しい状況です。私以外の誰かがそれに遭遇した場合に備えて言及します。

今日、hg pushコマンドで「リポジトリのロックを待機しています」が表示されました。

hung hgコマンドを強制終了すると、.hg / store / lockが表示されませんでした

コマンドがハングしているときに.hg / store / lockを探したところ、存在していました。しかし、hgコマンドが強制終了されたときにロックファイルが削除されました。

プッシュのターゲットに行ってhg pullを実行しても問題ありません。

最終的に、hg pushのプロセスIDがロック待機メッセージであり、毎回変更されることに気付きました。「hg push」は、それ自体が保持しているロックを待機してハングしていることがわかりました（またはサブプロセスである可能性があります。これ以上は調査しませんでした）。

2つのワークスペースをAとBと呼び、.hgツリーがsymlinkで共有されていることがわかります。

A/.hg --symlinked-to--> B/.hg

これは、Mercurialを使用するのは良いことではありません。Mercurialは、同じリポジトリを共有する2つのワークスペースの概念を理解していません。ただし、別のVCSからMercurialにアクセスする人がこれをどのように望んでいるかは理解しています（PerforceはDVCSではありませんが、Bazaar DVCSはそうできると報告しています）。シンボリックリンクされたREP-ROOT / .hgがまったく機能することには驚いていますが、このプッシュ以外のようです。

私も同じ問題を抱えていました。コミットしようとしたときに次のメッセージが表示されました。

waiting for lock on working directory of <MyProject> held by '...'

hg debuglock これを示した：

lock:  free
wlock:  (66722s)

そこで、次のコマンドを実行すると、問題が解決しました。

hg debuglocks -W

Win7とTortoiseHg 4.8.7の使用。

ロックされたレポがオリジナルだった場合、それが変更されているとは思えませんしてクローンを作成したので、途中で変更してクローンをめちゃくちゃにするのを防ぐだけでした。ロックを外すと問題ないはずです。

ただし、新しいクローンコピー（ローカルクローンの場合）は、何らかの不正な状態にある可能性があるため、破棄して最初からやり直す必要があります。（それがリモートクローンだった場合、失敗して、すでに不完全なコピーが破棄されていると思います。）

Mac OS X 10.7.5とMercurial 2.6.2でプッシュしようとすると、この問題が発生しました。Mercurial 3.2.1にアップグレードした後、「リポジトリのロックを待つ」のではなく、「変更が見つかりません」というメッセージが表示されました。どういうわけかデフォルトのパスが同じリポジトリを指すように設定されているので、Mercurialが混乱するのはそれほど驚くことではありません。

マップされたドライブでのみ発生する場合は、バグhttps://bitbucket.org/tortoisehg/thg/issue/889/cant-commit-file-over-network-shareである可能性があります。ドライブ文字の代わりにUNCパスを使用すると、問題が回避されるようです。