次の（Visual Studio）プロジェクト（簡略化）があるとします。
- base-lib-1
- base-lib-2
- product-1 ： base-lib-1に依存
- product-2：base-lib-1およびbase-lib-2に依存
- product-3：base-lib-1とbase-lib-2に依存し、 product-2のコンポーネントとして使用されます
- product-4：product-3のように
このプロジェクト構造を1つまたは複数のMercurialリポジトリに編成するための良い方法は何でしょうか。現在、Subversionを使用しており、依存ライブラリを外部として含めています。
1つの方法は、product-1以外のすべてを単一のリポジトリに配置することです。これらの製品はすべて、常に1つのパッケージとして一緒にリリースされるためです。私はこのソリューションに最も満足していると思います。そうすれば、リポジトリの処理方法についてかなり確信が持てるようになります。しかし、 base-lib-1を複製せずに、このスキームにproduct-1をどのように適合させるのでしょうか。
別の方法として、次のように編成されるサブリポジトリを使用することを考えました。
- product-package-A
- base-lib-1
- product-1
- product-package-B
- base-lib-1
- base-lib-2
- product-2
- product-3
- product-4
このアプローチの問題は、サブリポジトリを使用したことがないため、このソリューションで発生する落とし穴についてはよくわかりません。
たとえば、サブリポジトリは、各サブリポジトリの最新リビジョンと固定リビジョンのどちらを常に使用するかを決定できるという点で、SVN外部のように動作しますか？
たとえばbase-lib-1とproduct-2を同時に変更した場合、サブリポジトリはどのように動作しますか？それらは同じステップでMercurialによって処理されますか、それともすべてを手動でコミット/プッシュおよびプル/更新する必要がありますか？この場合、 base-lib-1のサブリポジトリはproduct-package-Aでどのように動作しますか？
複数のサブリポジトリでの変更が必要な新しい機能ブランチを開発する場合、このシナリオでブランチはどのように機能しますか？すべてのリポジトリを手動で分岐してマージする必要がありますか、それともMercurialによって処理されますか？
サブリポジトリを使用して大規模なプロジェクトを編成することについて、他に落とし穴はありますか？Mercurialで多くの依存関係を持つ大規模なプロジェクトを処理するための好ましい方法は何ですか？