依存関係追跡ソリューションとしてのサブリポジトリ（サブモジュール）-はいまたはいいえ
SCMベース（Mercurialのサブリポジトリ、Gitのサブモジュール）の依存関係管理についてどう思いますか？
依存関係を管理するのに間違いなく良い方法ですか？または間違いなく悪い方法？
サブリポジトリよりもビルドシステム（ant/phing/rake）を優先する必要がありますか？
コンテキストを持つ特定の例：
再利用可能なコンポーネント間で共有するいくつかのWebアプリケーションがあります（jqueryプラグインなど）。
オプションがある場合は、SCMを使用する代わりに、専用ツールを使用してください。私は SOについてこれについて書かれています ですが、議論は結局カップリング、特に過度に密なカップリングに要約されます。柔軟なソフトウェア開発は、本当に必要でない限り密結合を回避することであり、MercurialサブリポジトリとGitサブモジュールの両方が非常に密な結合を導入します。
さらに、サブレポ/サブモジュールは、日常のワークフローをさらに複雑にします。人々がすでにSCMに精通している場合、これは許容できるかもしれません。しかし、Mercurialとサブリポジトリを同時に導入しようとする多くの組織を見てきました。すべてが非常に複雑に見えるだけなので、間違いだと考えています。
Mercurial wiki には、サブレポの使用方法に関する一連の推奨事項があります。これらには、シンシェルリポジトリの使用が含まれます。これにより、コンポーネントの結合が回避されます。必要に応じていずれかのサブリポジトリで作業し、それらを更新するためにプッシュ/プルできます。たまに誰か（たぶんビルドエンジニア、たぶん継続的インテグレーションサーバー）がコンポーネントの新しい設定をテストするでしょう。テストに合格すると、シェルリポジトリに新しいコミットが作成され、作業に使用する新しいベースが提供されます。
1年前にSVNからKiln（Mercurial）に切り替えたときに、サブリポジトリも再実装しました。正直言って、私がそうしなかったといいのですが。サブリポジトリは、依存関係が変更されたときにサブリポジトリを最新の状態に保つために、すぐに対処する面倒になります。これは、活発に開発されている内部の「サードパート」ライブラリを扱うときに特に当てはまります。
現在、TeamCityサーバーによってビルドおよびホストされるNuGetパッケージに、依存関係を徐々に変換しています。
推奨されるソリューションの選択肢としてサブリポジトリを推奨する前に、サブリポジトリを支持して良い議論を見る必要があります。
Mercurialを使用し、すべての依存関係（GLEW、GLM、Boost、Assimp、Bullet）にサブリポジトリを使用していますが、それが常に良いことであるとは確信していません。ビルド済みのライブラリとリンクするだけの方が理にかなっていると思うことがあります。
私にとって、デバッグのために使用しているすべての外部コードをビルドしてステップスルーできるのはいいことです。さらに、独自のブランチを作成してカスタム変更を行い、サブリポジトリの更新をプルすることもできます。
Mercurialのドキュメントでは、独自のプロジェクトと依存関係をサブリポジトリとして持つマスターリポジトリを推奨していますが、すべてのサブリポジトリをプロジェクトルートのすぐ下のDependenciesディレクトリに保持しています。
git submodulesこれに最適です。すべてのコードをバンドルに保持し、簡単にアップグレードし、プロジェクトごとにそれを実行し、他のコードを気にすることなく、基本的にすべてを正常に保つことができます。
いくつかの注意点：
git pull && git submodule init && git submodule update---これらはSTANDARDワークフローの一部である必要があります。人々がサブモジュールを変更して競合を引き起こしている場合、サブモジュールは困難です。それほど難しくはありませんが、取得できるのは2つのSHA1だけであり、最適なものを選択するか、手動でそれらをマージしてベースリポジトリをアップグレードする必要があります。
Githubは、すべてのgitを置くのに最適な場所です。これは余談ですが、私はオープンソースサブモジュールのパブリックリポジトリとメインプロジェクトのプライベートリポジトリを組み合わせて使用しています。
お役に立てれば！