357

Mercurial リポジトリのクローン作成中に Windows でブルースクリーンが発生しました。

再起動後、ほぼすべての hg コマンドで次のメッセージが表示されるようになりました。

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

Google は役に立ちません。

任意のヒント？

4

11 に答える 11

504

「リポジトリのロックを待機中」の場合は、リポジトリファイルを削除します:(.hg/wlockまたはにある可能性があります.hg/store/lock）

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

于 2008-08-15T23:20:18.820 に答える
350

の場合waiting for lock on working directoryは削除し.hg/wlockます。

于 2010-06-02T18:39:16.287 に答える
47

検出可能なロックファイルがないため、この問題が発生しました。ここで解決策を見つけました：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）古くなったときに自動削除のためにタイムスタンプを付けない。

于 2017-01-07T23:16:34.297 に答える
12

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

  1. 私はこれを実際に見たことがありますが、めったになく、Windows マシンでのみです。
  2. ロック ファイルを削除するのが最も簡単な解決策ですが、他に何もリポジトリにアクセスしていないことを確認する必要があります。(ロックがゼロの文字列である場合、これはほぼ確実に当てはまります)。

(興味深いことに、この問題の原因はまだ特定できていませんが、古いバージョンの Mercurial がリポジトリにアクセスしているか、特定のバージョンの Windows での Python の socket.gethostname() 呼び出しの問題であると思われます。)

于 2011-11-02T13:36:33.463 に答える
7

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

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

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

于 2015-03-12T09:24:12.107 に答える
6

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

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

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

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

プッシュのターゲットに行って、hg プルを実行したところ、問題ありませんでした。

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

2 つのワークスペース (A と B と呼びましょう) には、symlink によって共有されている .hg ツリーがありました。

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

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

于 2014-08-01T22:22:55.170 に答える
2

ロックされたリポジトリが元のリポジトリである場合、それがクローンを作成するように変更されているとは想像できないため、途中で変更してクローンを台無しにすることはできませんでした。ロックを外すと問題ないはずです。

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

于 2008-08-16T20:54:27.880 に答える
1

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

于 2012-07-12T05:20:48.943 に答える