Mercurialは使用していませんが、始めたいので読んでいます。私が広く使用している唯一のSCMシステムはCVSです。Mercurialについて私が読んだことのほとんどは理にかなっており、良さそうです。しかし、私はそれがタグを行う方法に交互にショックを受け、当惑しています。
タグは、チェンジセットの単なるニックネームです（「チェンジセット」とは、実際にはチェンジセットの結果として生じる状態を意味します）。涼しい。タグからチェンジセットIDへのマッピングは.hgtagsファイルに保存されます。またかっこいい。.hgtagsファイルはバージョン管理されています。
何？
これは直感に反する結果をたくさんもたらします。たとえば、タグ付けしたいチェンジセット（たとえば、リリース1.0を形成するコード）をコミットした場合、タグ付け後に再度コミットして、更新されたタグファイルをリポジトリに配置する必要があります。そして、後日、そのタグ付きチェンジセットに更新すると、作業コピーにはそのタグに関する知識が含まれなくなります。私が何らかの作業を行って、新しいブランチを作成した場合（たとえば、バグ修正の場合は1.1に向かって）、そのブランチは、それが成長したタグについての知識を持っていません。手動でコピーしない限り、つまり。
また、元のトランクと新しいブランチの両方で開発が継続され、重要な変更セット（トランクの2.0リリース、ブランチの1.1および1.2バグ修正リリース）をマークするタグが作成されるため、両方のブランチは他方を無視して続行しますブランチのタグ。したがって、あるブランチでの作業を終了し、別のブランチで特定のチェンジセットに切り替えたい場合（たとえば、1.2のバグ修正リリースを終了しましたが、2.0に基づく2.1のバグ修正で開始する必要があります）、今は詰め込まれています。私の現在のチェンジセットは2.0について知りません！
私に何ができる？
- 2.xブランチで作業している人に、2.0の実際のチェンジセットIDを読み取って、それを明示的に使用するように依頼することはできますが、これは恐ろしいことです。
- タグを使用するだけでなく、ブランチに名前を付けることもできます。これにより、2.xブランチの先頭に移動して、新しいタグについて学習し、2.0タグにスキップして戻ることができます。タグとは異なり、ブランチが普遍的に見えると仮定すると、そうですか？たとえそうだとしても、これは不格好なようです。
- リポジトリの外部に単一のグローバル
hgtagsファイルを維持し、いくつかのフックを使用して、更新時にコピーをプルし、ローカルコピーを上書きし、コミット時に変更をコピーして戻すことができます。開発者が共有リポジトリに変更をプッシュしているマルチユーザー環境でこれがどのように機能するかはわかりません。ファイル専用の別のリポジトリが必要になる場合がありhgtagsます。 - バージョン管理メカニズムの外部にあるローカルタグを使用できるので、問題全体を回避できます。
localtags共有グローバルタグと同様に、開発者間でファイルを同期するメカニズムを導入する必要があります。
これらのソリューションはどれも完全に優れているようには見えません。私は何をすべきか？
ここでの前提は、ブランチごとのリポジトリではなく、単一のリポジトリで名前付きブランチを使用してブランチを管理していることです。私が後者をした場合、状況はもっと良くなるでしょうか？