サブリポジトリ (「内部」) を持つ Mercurial リポジトリ (「外部」) を操作する場合、多くの場合、外部でマージしようとしても「コミットされていない変更」が原因で失敗するという問題が発生する可能性があります。明らかな変化がない場合（hg st外側は変化がないため）。
問題はサブリポジトリの状態にあります。.hgsubstateファイルには、実際にはサブリポジトリの作業コピーの変更セットとは異なるサブリポジトリの変更セット ID が含まれています (または、自明なことですが、サブリポジトリにコミットされていない変更があります)。
発生した場合は修正できますが、この問題を常に回避するプルとマージの Mercurial ワークフローを推奨できる人はいますか? テストリポジトリなどで遊んで解決できますが、誰かが私や他の人がすでに知っていれば、時間を節約できるかもしれません。
これは 1 人だけではなく小さなチーム向けであるため、ワークフローはシンプルであるほど良いです。
問題の例:
更新 - .hgsubstate の動作に関するメモ
ファイルを更新する唯一の 2 つのアクション.hgsubstate(コマンド ラインを使用する場合) は次のとおりです。
外側のプロジェクトのバージョンを取得すると、チェックインされた .hgsubstate がすべて取得されます (明らかに)
外部プロジェクトをコミットする
.hgsubstateと、内部プロジェクトの現在の親変更セットに更新されます
サブレポを更新しても外側のプロジェクトに変更を加えない場合、外側のプロジェクトには変更が表示されませんhg status。ただし、を実行するhg status -Sと、サブリポジトリ (および外部プロジェクト) のファイル ステータスが取得されます。表示されるサブリポジトリのファイル ステータスは、次のものが混在しています。
a)サブレポ内のファイルに対するコミットされていない作業コピーの変更
b)の変更セット ID よりも新しいサブレポへのコミットされた変更.hgsubstate
外部プロジェクトをコミットしようとすると、hg st変更が表示されなくても、サブレポに実際に新しいヒント変更セットがある場合は、.hgsubstate ファイルの更新されたバージョンをコミットできます。したがって、重要な戦略はhg st -S、作業コピーの変更や で指定された ID よりも新しい変更セットなど、サブレポに保留中のものがあるかどうかを示す whichを使用すること.hgsubstateです。