Re: [mercurial-ja:1771] [thg] hg pull 実行時に作業領域のロックの開放を待ち続ける
850 views
Skip to first unread message
Message has been deleted
Katsunori FUJIWARA
Apr 20, 2017, 4:24:58 AM4/20/17
to mercurial-ja
藤原です。
2017年4月20日 14:02 ohira <shin....@gmail.com>:
> いつもお世話になっております。
> おおひらです。
>
> hg pull 実行時に作業領域のロックを待ち続けるという現象が発生しました。
>
> Windows 7 Professional
> TortoiseHg 4.1.2
>
>
> 他のプログラムが動作しているためかとしれないので、他のプログラム
> を全て終了してみましたが状況に変化なし。
>
> OSの再起動を行って、再度 hg pull を実行しましたが状況に変化あり
> ませんでした。
>
> (設定ファイルをnulでクリアする設定も試したのですが、
「設定ファイルをnulでクリア」というのが「.hg/wlock ファイルの空ファ
イル化」を意味するものと仮定して話を進めます。
「作業領域の排他」や「リポジトリの排他」(履歴管理領域)は、基本的に
「ファイルの存在の有無」＝「排他の有無」です。
せめて、存在しないプロセスの PID が格納されていれば、「プロセス終
了済み」扱いで、解放を待たずに獲得処理に移行するのですが、現状の実
装では「空の排他ファイル」は解放待ちの無限ループを生じる筈です (後
述しますが、この実装が問題の原因である可能性もあります)
実装内情を確認せずに、内部管理情報を不用意に手動編集するのは避けた
方が良いでしょう（後述する hg debuglocks を使用してください）。
> 設定ファイル
> を読まないとssh経由のアクセスができないため再現するところまでい
> きませんでした)
これは:
"hg pull" 実行前に「設定ファイル (= .hg/wlock) をnulでクリアす
る」処理をしたら、そもそも SSH 経由で履歴情報を取得する処理が
（排他解放待ちで）実行されない
という理解で合っていますか？
現在、"hg pull" は常に作業領域排他を必要としていますので、上記のよ
うな手順だと、単に排他解放を待ち続けるだけになってしまいます。
bookmark 周りが「履歴管理領域排他」傘下でさえあれば、-U/--update
無しの "hg pull" では作業領域排他が必要なかった筈なんですけどねぇ
(歴史的経緯から止むを得ないのですが……)
> 実行したコマンド
> --debugを付けて実行
上記2つは末尾の「中断されました!」以外は特に違いが無かったのですが、
実行ログのコピペミスでしょうか？
> C:\Users\ohira\repos\trunk\sps_20_static>hg pull --debug
> ssh://h...@escm11.mxfw.net/trunk/sps_20_static から取り込み中
> running "C:\Program Files\TortoiseHg\lib\TortoisePlink.exe" -ssh -2
> h...@escm11.mx
> fw.net "hg -R trunk/sps_20_static serve --stdio"
> sending hello command
> sending between command
> remote: 329
> remote: capabilities: lookup changegroupsubset branchmap pushkey known
> getbundle
> unbundlehash batch stream
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%
> 2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgt
> agsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
> unbundle=HG10
> GZ,HG10BZ,HG10UN
> remote: 1
> C:\Users\ohira\repos\trunk\sps_20_static の作業領域 のロック ('' が保持) の解放
> を待っています
> 中断されました!
上記の実行ログは、元々の「hg pull 実行時に作業領域の排他解放を待ち
続ける」問題が発生するリポジトリでのものでしょうか？
それとも「設定ファイルをnulでクリアする」設定を行った場合のもので
しょうか？
「作業領域 のロック ('' が保持) の解放」メッセージで、排他保持プロ
セスの情報が表示される筈のところに空文字列が表示される点から推測す
るに:
- 「元々の問題発生リポジトリでの実行」ケース
以前 Mercurial を実行した際の排他解放において、何らかの理由か
ら、「.hg/wlock ファイルの削除」が「.hg/wlock ファイルの空化」
になってしまった可能性があります。
先述したように、現状の実装では「空 .hg/wlock ファイル」は解放
待ちの無限ループになります。
4.2 向けに修正パッチを提案しようと思います。
- 「設定ファイルをnulでクリアする」ケース
内部管理ファイルの手動編集は止めましょう (笑)
「設定ファイルをnulでクリアする」に関しては「再現できませんでした」
との言及があったので、前者だとは思いますが、ログの出力を見る限りで
はどちらとも解釈可能なので、念のため……
非公開ではありますが、排他情報の参照／操作向けに "hg debuglocks"
コマンドが提供されています。
デフォルト動作が「排他保持プロセスに関する情報表示」なので、今後同
様の現象が発生した際には、まずは排他を保持しているプロセスの死活確
認を行ってください。
獲得済みの排他解放など、使用方法の詳細は "hg help debuglocks" でオ
ンラインヘルプを参照してください。
> hg verifyの実行
「履歴管理領域の整合性」をチェックする "hg verify" は、作業領域を
排他せずに（＝ 作業領域の排他が他のプロセスによって獲得済みでも）
実行されます。
ですので、"hg verify" は排他関連の整合性確認用途には適していません。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2017年4月20日 14:02 ohira <shin....@gmail.com>:
> いつもお世話になっております。
> おおひらです。
>
> hg pull 実行時に作業領域のロックを待ち続けるという現象が発生しました。
>
> Windows 7 Professional
> TortoiseHg 4.1.2
>
>
> 他のプログラムが動作しているためかとしれないので、他のプログラム
> を全て終了してみましたが状況に変化なし。
>
> OSの再起動を行って、再度 hg pull を実行しましたが状況に変化あり
> ませんでした。
>
> (設定ファイルをnulでクリアする設定も試したのですが、
「設定ファイルをnulでクリア」というのが「.hg/wlock ファイルの空ファ
イル化」を意味するものと仮定して話を進めます。
「作業領域の排他」や「リポジトリの排他」(履歴管理領域)は、基本的に
「ファイルの存在の有無」＝「排他の有無」です。
せめて、存在しないプロセスの PID が格納されていれば、「プロセス終
了済み」扱いで、解放を待たずに獲得処理に移行するのですが、現状の実
装では「空の排他ファイル」は解放待ちの無限ループを生じる筈です (後
述しますが、この実装が問題の原因である可能性もあります)
実装内情を確認せずに、内部管理情報を不用意に手動編集するのは避けた
方が良いでしょう（後述する hg debuglocks を使用してください）。
> 設定ファイル
> を読まないとssh経由のアクセスができないため再現するところまでい
> きませんでした)
これは:
"hg pull" 実行前に「設定ファイル (= .hg/wlock) をnulでクリアす
る」処理をしたら、そもそも SSH 経由で履歴情報を取得する処理が
（排他解放待ちで）実行されない
という理解で合っていますか？
現在、"hg pull" は常に作業領域排他を必要としていますので、上記のよ
うな手順だと、単に排他解放を待ち続けるだけになってしまいます。
bookmark 周りが「履歴管理領域排他」傘下でさえあれば、-U/--update
無しの "hg pull" では作業領域排他が必要なかった筈なんですけどねぇ
(歴史的経緯から止むを得ないのですが……)
> 実行したコマンド
> --debugを付けて実行
上記2つは末尾の「中断されました!」以外は特に違いが無かったのですが、
実行ログのコピペミスでしょうか？
> C:\Users\ohira\repos\trunk\sps_20_static>hg pull --debug
> ssh://h...@escm11.mxfw.net/trunk/sps_20_static から取り込み中
> running "C:\Program Files\TortoiseHg\lib\TortoisePlink.exe" -ssh -2
> h...@escm11.mx
> fw.net "hg -R trunk/sps_20_static serve --stdio"
> sending hello command
> sending between command
> remote: 329
> remote: capabilities: lookup changegroupsubset branchmap pushkey known
> getbundle
> unbundlehash batch stream
> bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%
> 2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgt
> agsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
> unbundle=HG10
> GZ,HG10BZ,HG10UN
> remote: 1
> C:\Users\ohira\repos\trunk\sps_20_static の作業領域 のロック ('' が保持) の解放
> を待っています
> 中断されました!
上記の実行ログは、元々の「hg pull 実行時に作業領域の排他解放を待ち
続ける」問題が発生するリポジトリでのものでしょうか？
それとも「設定ファイルをnulでクリアする」設定を行った場合のもので
しょうか？
「作業領域 のロック ('' が保持) の解放」メッセージで、排他保持プロ
セスの情報が表示される筈のところに空文字列が表示される点から推測す
るに:
- 「元々の問題発生リポジトリでの実行」ケース
以前 Mercurial を実行した際の排他解放において、何らかの理由か
ら、「.hg/wlock ファイルの削除」が「.hg/wlock ファイルの空化」
になってしまった可能性があります。
先述したように、現状の実装では「空 .hg/wlock ファイル」は解放
待ちの無限ループになります。
4.2 向けに修正パッチを提案しようと思います。
- 「設定ファイルをnulでクリアする」ケース
内部管理ファイルの手動編集は止めましょう (笑)
「設定ファイルをnulでクリアする」に関しては「再現できませんでした」
との言及があったので、前者だとは思いますが、ログの出力を見る限りで
はどちらとも解釈可能なので、念のため……
非公開ではありますが、排他情報の参照／操作向けに "hg debuglocks"
コマンドが提供されています。
デフォルト動作が「排他保持プロセスに関する情報表示」なので、今後同
様の現象が発生した際には、まずは排他を保持しているプロセスの死活確
認を行ってください。
獲得済みの排他解放など、使用方法の詳細は "hg help debuglocks" でオ
ンラインヘルプを参照してください。
> hg verifyの実行
「履歴管理領域の整合性」をチェックする "hg verify" は、作業領域を
排他せずに（＝ 作業領域の排他が他のプロセスによって獲得済みでも）
実行されます。
ですので、"hg verify" は排他関連の整合性確認用途には適していません。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
Message has been deleted
Katsunori FUJIWARA
Apr 20, 2017, 5:39:48 AM4/20/17
to mercurial-ja
藤原です。
2017年4月20日 17:42 ohira <shin....@gmail.com>:
> 回答ありがとうございます。
> おおひらです。
>
> 2017年4月20日木曜日 17時24分58秒 UTC+9 FUJIWARA Katsunori:
>
> https://groups.google.com/forum/#!msg/mercurial-ja/Wusf8_SwBcg/LOs6yJuDAgAJ
了解しました。
「設定ファイルをnulでクリア」だと、多分に「ファイル書き換え」なニュ
アンスを帯びてしまいますので、「HGRCPATH を nul 設定することで、設
定ファイル読み込みを無効化」等の表現をしてもらえると助かります。
なお、設定ファイル読み込みを無効化しても、以下の要領で SSH 経由で
の pull ができる筈です。
- 連携先リポジトリの URL を明示的に指定
- --config ui.ssh=xxxxx オプション指定で SSH クライアントを明示的に指定
※ 以下の実行例の場合、TortoisePlink のための入れ子のクオート
指定が幾分面倒かな？
>> > C:\Users\ohira\repos\trunk\sps_20_static>hg pull --debug
>> > ssh://h...@escm11.mxfw.net/trunk/sps_20_static から取り込み中
>> > running "C:\Program Files\TortoiseHg\lib\TortoisePlink.exe" -ssh -2
>> > h...@escm11.mx
>> > fw.net "hg -R trunk/sps_20_static serve --stdio"
>> > sending hello command
>> > sending between command
>> > remote: 329
>> > remote: capabilities: lookup changegroupsubset branchmap pushkey known
>> > getbundle
>> > unbundlehash batch stream
>> > bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%
>> >
>> > 2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgt
>> > agsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
>> > unbundle=HG10
>> > GZ,HG10BZ,HG10UN
>> > remote: 1
>> > C:\Users\ohira\repos\trunk\sps_20_static の作業領域 のロック ('' が保持) の解放
>> > を待っています
>> > 中断されました!
>>
>> 上記の実行ログは、元々の「hg pull 実行時に作業領域の排他解放を待ち
>> 続ける」問題が発生するリポジトリでのものでしょうか？
>>
>> それとも「設定ファイルをnulでクリアする」設定を行った場合のもので
>> しょうか？
>
> 設定ファイルをnulでクリアすると ロック待ちの前にsshの接続エラー
> が発生するようです。
ということは、SSH 接続が実行されいることから見て、添付されている実
行例は、前者のものである、という理解で良いのですね？
であれば:
>> - 「元々の問題発生リポジトリでの実行」ケース
>>
>> 以前 Mercurial を実行した際の排他解放において、何らかの理由か
>> ら、「.hg/wlock ファイルの削除」が「.hg/wlock ファイルの空化」
>> になってしまった可能性があります。
>>
>> 先述したように、現状の実装では「空 .hg/wlock ファイル」は解放
>> 待ちの無限ループになります。
>>
>> 4.2 向けに修正パッチを提案しようと思います。
ということになりますね。
同様の問題が発生した場合、とりあえず当面は、"hg debuglocks" で対処
してください。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2017年4月20日 17:42 ohira <shin....@gmail.com>:
> 回答ありがとうございます。
> おおひらです。
>
> 2017年4月20日木曜日 17時24分58秒 UTC+9 FUJIWARA Katsunori:
>>
>> 藤原です。
>>
>> 2017年4月20日 14:02 ohira <shin....@gmail.com>:
>>
>> > いつもお世話になっております。
>> > おおひらです。
>> >
>> > hg pull 実行時に作業領域のロックを待ち続けるという現象が発生しました。
>> >
>> > Windows 7 Professional
>> > TortoiseHg 4.1.2
>> >
>> >
>> > 他のプログラムが動作しているためかとしれないので、他のプログラム
>> > を全て終了してみましたが状況に変化なし。
>> >
>> > OSの再起動を行って、再度 hg pull を実行しましたが状況に変化あり
>> > ませんでした。
>> >
>> > (設定ファイルをnulでクリアする設定も試したのですが、
>>
>> 「設定ファイルをnulでクリア」というのが「.hg/wlock ファイルの空ファ
>> イル化」を意味するものと仮定して話を進めます。
>
>
> nul でクリアしたのは、ロックファイルではなくて設定ファイルの読み込みです。
>> 藤原です。
>>
>> 2017年4月20日 14:02 ohira <shin....@gmail.com>:
>>
>> > いつもお世話になっております。
>> > おおひらです。
>> >
>> > hg pull 実行時に作業領域のロックを待ち続けるという現象が発生しました。
>> >
>> > Windows 7 Professional
>> > TortoiseHg 4.1.2
>> >
>> >
>> > 他のプログラムが動作しているためかとしれないので、他のプログラム
>> > を全て終了してみましたが状況に変化なし。
>> >
>> > OSの再起動を行って、再度 hg pull を実行しましたが状況に変化あり
>> > ませんでした。
>> >
>> > (設定ファイルをnulでクリアする設定も試したのですが、
>>
>> 「設定ファイルをnulでクリア」というのが「.hg/wlock ファイルの空ファ
>> イル化」を意味するものと仮定して話を進めます。
>
>
>
> https://groups.google.com/forum/#!msg/mercurial-ja/Wusf8_SwBcg/LOs6yJuDAgAJ
了解しました。
「設定ファイルをnulでクリア」だと、多分に「ファイル書き換え」なニュ
アンスを帯びてしまいますので、「HGRCPATH を nul 設定することで、設
定ファイル読み込みを無効化」等の表現をしてもらえると助かります。
なお、設定ファイル読み込みを無効化しても、以下の要領で SSH 経由で
の pull ができる筈です。
- 連携先リポジトリの URL を明示的に指定
- --config ui.ssh=xxxxx オプション指定で SSH クライアントを明示的に指定
※ 以下の実行例の場合、TortoisePlink のための入れ子のクオート
指定が幾分面倒かな？
>> > C:\Users\ohira\repos\trunk\sps_20_static>hg pull --debug
>> > ssh://h...@escm11.mxfw.net/trunk/sps_20_static から取り込み中
>> > running "C:\Program Files\TortoiseHg\lib\TortoisePlink.exe" -ssh -2
>> > h...@escm11.mx
>> > fw.net "hg -R trunk/sps_20_static serve --stdio"
>> > sending hello command
>> > sending between command
>> > remote: 329
>> > remote: capabilities: lookup changegroupsubset branchmap pushkey known
>> > getbundle
>> > unbundlehash batch stream
>> > bundle2=HG20%0Achangegroup%3D01%2C02%0Adigests%3Dmd5%
>> >
>> > 2Csha1%2Csha512%0Aerror%3Dabort%2Cunsupportedcontent%2Cpushraced%2Cpushkey%0Ahgt
>> > agsfnodes%0Alistkeys%0Apushkey%0Aremote-changegroup%3Dhttp%2Chttps
>> > unbundle=HG10
>> > GZ,HG10BZ,HG10UN
>> > remote: 1
>> > C:\Users\ohira\repos\trunk\sps_20_static の作業領域 のロック ('' が保持) の解放
>> > を待っています
>> > 中断されました!
>>
>> 上記の実行ログは、元々の「hg pull 実行時に作業領域の排他解放を待ち
>> 続ける」問題が発生するリポジトリでのものでしょうか？
>>
>> それとも「設定ファイルをnulでクリアする」設定を行った場合のもので
>> しょうか？
>
> が発生するようです。
ということは、SSH 接続が実行されいることから見て、添付されている実
行例は、前者のものである、という理解で良いのですね？
であれば:
>> - 「元々の問題発生リポジトリでの実行」ケース
>>
>> 以前 Mercurial を実行した際の排他解放において、何らかの理由か
>> ら、「.hg/wlock ファイルの削除」が「.hg/wlock ファイルの空化」
>> になってしまった可能性があります。
>>
>> 先述したように、現状の実装では「空 .hg/wlock ファイル」は解放
>> 待ちの無限ループになります。
>>
>> 4.2 向けに修正パッチを提案しようと思います。
同様の問題が発生した場合、とりあえず当面は、"hg debuglocks" で対処
してください。
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
ohira
Apr 20, 2017, 6:00:11 AM4/20/17
to mercurial-ja
回答ありがとうございます。
おおひらです。
特に変わった処理をしたつもりはないです。
リポジトリ間でのpush, pull してるときにロック待ち続ける現象が発生しました。
先ほどのもので書き忘れましたが、
藤原さんの回答にあった ./hg/wlockがなぜかサイズ0バイトのファイルになっていました。
そのため今回の現象ではhg debuglocksでも発生原因の特定に繋がるような情報は得られませんでした。
しかしロックファイルを使ったロックとは想定外でした。
移植性が良くなるでしょうが、安定正に不安が残るような気が、、
ロックファイルだとOS再起動してもロック残ったままですね。
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%AD%E3%83%83%E3%82%AF#.E3.83.AD.E3.83.83.E3.82.AF.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB
2017年4月20日木曜日 18時39分48秒 UTC+9 FUJIWARA Katsunori:
2017年4月20日木曜日 18時39分48秒 UTC+9 FUJIWARA Katsunori:
Katsunori FUJIWARA
Apr 20, 2017, 6:50:52 AM4/20/17
to mercurial-ja
藤原です。
2017年4月20日 19:00 ohira <shin....@gmail.com>:
> 回答ありがとうございます。
> おおひらです。
>
> 特に変わった処理をしたつもりはないです。
> リポジトリ間でのpush, pull してるときにロック待ち続ける現象が発生しました。
>
> 先ほどのもので書き忘れましたが、
> 藤原さんの回答にあった ./hg/wlockがなぜかサイズ0バイトのファイルになっていました。
> そのため今回の現象ではhg debuglocksでも発生原因の特定に繋がるような情報は得られませんでした。
>
確かに「hg debuglocks でロック保持プロセスの情報が表示されない」こ
とは、排他解放に失敗した原因の特定にはつながりません。
しかし、「./hg/wlock が 0 バイト」という情報と合わせることで、「想
定される排他の再獲得処理が実施されない」障害の原因は特定できました
ので、無駄ではないです。
> しかしロックファイルを使ったロックとは想定外でした。
> 移植性が良くなるでしょうが、安定正に不安が残るような気が、、
> ロックファイルだとOS再起動してもロック残ったままですね。
> https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%AD%E3%83%83%E3%82%AF#.E3.83.AD.E3.83.83.E3.82.AF.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB
>
その wiki ページでも言及されていますが、POSIX 環境であっても、NFS
のようなリモートファイルシステムとかへの配慮を考えると、OS レベル
で提供されるファイル排他機構は、可搬性／安定性の点で選択しづらいの
ですよ。
その上、Windows の SMB/CIFS 共有等への配慮も必要となると……
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
2017年4月20日 19:00 ohira <shin....@gmail.com>:
> 回答ありがとうございます。
> おおひらです。
>
> 特に変わった処理をしたつもりはないです。
> リポジトリ間でのpush, pull してるときにロック待ち続ける現象が発生しました。
>
> 先ほどのもので書き忘れましたが、
> 藤原さんの回答にあった ./hg/wlockがなぜかサイズ0バイトのファイルになっていました。
> そのため今回の現象ではhg debuglocksでも発生原因の特定に繋がるような情報は得られませんでした。
>
とは、排他解放に失敗した原因の特定にはつながりません。
しかし、「./hg/wlock が 0 バイト」という情報と合わせることで、「想
定される排他の再獲得処理が実施されない」障害の原因は特定できました
ので、無駄ではないです。
> しかしロックファイルを使ったロックとは想定外でした。
> 移植性が良くなるでしょうが、安定正に不安が残るような気が、、
> ロックファイルだとOS再起動してもロック残ったままですね。
> https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%83%AD%E3%83%83%E3%82%AF#.E3.83.AD.E3.83.83.E3.82.AF.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB
>
のようなリモートファイルシステムとかへの配慮を考えると、OS レベル
で提供されるファイル排他機構は、可搬性／安定性の点で選択しづらいの
ですよ。
その上、Windows の SMB/CIFS 共有等への配慮も必要となると……
--
----------------------------------------------------------------------
FUJIWARA Katsunori(flying...@gmail.com)
ohira
Apr 20, 2017, 10:00:09 PM4/20/17
to mercurial-ja
2017年4月20日木曜日 19時50分52秒 UTC+9 FUJIWARA Katsunori:
> 特に変わった処理をしたつもりはないです。
> リポジトリ間でのpush, pull してるときにロック待ち続ける現象が発生しました。
>
> 先ほどのもので書き忘れましたが、
> 藤原さんの回答にあった ./hg/wlockがなぜかサイズ0バイトのファイルになっていました。
> そのため今回の現象ではhg debuglocksでも発生原因の特定に繋がるような情報は得られませんでした。
>
確かに「hg debuglocks でロック保持プロセスの情報が表示されない」こ
とは、排他解放に失敗した原因の特定にはつながりません。
しかし、「./hg/wlock が 0 バイト」という情報と合わせることで、「想
定される排他の再獲得処理が実施されない」障害の原因は特定できました
ので、無駄ではないです。
発生時に行っていた処理内容について
関連するリポジトリは以下の三個(作業前はpullして同期済み)
ssh://h...@escm11.mxfw.net/trunk/sps_20_static(サーバー上の共有リポジトリ)
C:\Users\ohira\repos\trunk\sps_20_static(ローカルPC上の個人利用リポジトリ)(サーバー上の共有リポジトリからcloneされたもの)
C:\Users\ohira\repos\work\sps_20_static(ローカルPC上の個人利用作業用リポジトリ)(ローカルPC上の個人利用リポジトリからcloneされたもの)
ローカルPC上の個人利用作業用リポジトリでpromoteの処理をまとめて実施
その後promote処理のサーバー上の共有リポジトリへpromote結果反映のため以下のようなことを行いました(正確な順番や実行回数ははっきりしません)
ローカルPC上の個人利用リポジトリ (hg pull)
ローカルPC上の個人利用作業用リポジトリ (hg pull)
ローカルPC上の個人利用作業用リポジトリ (hg push)
ローカルPC上の個人利用リポジトリ (hg pull) ここでロック待ち発生
Message has been deleted
ohira
Nov 9, 2017, 9:37:05 PM11/9/17
to mercurial-ja
いつもおせわになっております。
おおひらです。
TortoiseHG 4.3.1 にバージョンアップしてから、
この現象が多発するようになりました。。。
0バイトのロックファイルを消せば復旧するとはいっても
自動で複数の作業を行う場合に、途中で止まってしまいますのでかなり不便ですね。
その後気がついたのですが、
発生するリポジトリと発生しないリポジトリがあり、まとまって発生する傾向があるようです。
アイコンツールは止めてあり、ウイルス対策はアンインストール状態で発生しています。
Reply all
Reply to author
Forward
0 new messages