注:リポジトリの編成に関する他のいくつかの質問を見てきましたが、この依存関係の問題については何も見つかりませんでした
現時点では、いくつかのディストリビューション(それらはmustが独立したリポジトリとして残ります-これらは多かれ少なかれクライアント固有であり、共有できません)はすべてサブモジュールとしてライブラリリポジトリを持っています。これは、さらにいくつかのレイヤーに依存しますが、これらの下位レイヤーはかなり固まっています。
これは、大まかに言うと、現在の構造は次のようになります(Distro
は、増え続ける分布のリストです)。
_Distro
+-Library Collection
+-Utility wrapper
+-Inner core
_
ここでの問題は_Library Collection
_リポジトリです。現在、これには数十のライブラリが含まれていますが、加速的な速度で成長し続けています。その結果、これは維持するのが面倒になりつつあり、私はgitが今後数年でいくつかのパフォーマンスの問題を経験し始めることを期待しています。
さらに、ほとんどのディストリビューションには、将来的に_Library Collection
_になる可能性があるコードが含まれますが、これは予測が難しく、外部要因に大きく依存します。
_Library Collection
_を分割して、各ディストリビューションが必要な個々のライブラリを選択できるようにしながら、プロジェクトの構成(ほとんどの場合CMake)をかなり簡単に保つ方法を見つけたいと思います。理想的には、次のようになります。
_Distro
+-Lib A
+-Lib B
+-Utility wrapper
+-Inner core
_
現在の構造では、すべてのリポジトリは1つ下のレベルに依存しています(まれに、2レベル下にある場合があります)。これが、このリポジトリ構造がそのように進化した理由です。
上記の理想的な構造では、このネストされた依存関係システムは機能しなくなります。 _Lib A
_と_Lib B
_はどちらも_Utility Wrapper
_に依存しています。 _Utility Wrapper
_を_Lib A
_と_Lib B
_の両方のサブモジュールにしたくありません。これにより、Distro
が複製されると、非常に多くの冗長データが生成されます(デバッグ中の頭痛は言うまでもありません) )。
さらに、これはライブラリによって異なりますが、_Lib B
_が_Lib A
_に依存する可能性があります。
ライブラリの分割で最初の亀裂をとっている間、私はディストリビューションリポジトリ内の個々のライブラリで作業することに頼らざるを得なかったので、Distro
レベルは依存関係を解決し、インクルードディレクトリとリンクを把握できます(この場合、CMakeを使用します)何かを変える)。
_Lib A
_および、場合によっては同じレベルの他のライブラリが必要な場合でも、_Utility Wrapper
_をDistro
とは別に開発/テストできるように、これらのリポジトリを整理する最良の方法は何ですか?
ソース管理は依存関係を管理すべきではありません。
Gitサブモジュールは、親と子のリポジトリが一緒に進化する限り、ライブラリコードを共有するのに最適であり、ソース管理でこの関係を管理することが理にかなっていることがよくあります。
あなたの場合、これらを独自に開発する必要があります。特に複数のディストリビューションやクライアントを扱う場合は、重大な変更が導入されないように特に注意する必要があります。
テクノロジースタックを指定していませんが、この問題の解決策は依存関係の管理です。これが.NETの場合、NuGetが頼りになるツールです。 Javaの場合、Mavinのようなものになります(他にもあります)。JavaScriptにはNPMがあり、RubyにはRubyGemsがあります。
各ライブラリを独自のリポジトリに保持しますが、親子のソース管理の組み合わせを壊します。各ライブラリには、パッケージリリースとそれに関連付けられたバージョン番号が必要です(関連: セマンティックバージョニング )。各ディストリビューションは、必要な最上位のライブラリのバージョン番号を正確に指定する必要があります。そのライブラリは、次に下のライブラリに必要なバージョンを指定する必要があります。
Distro A
Distro B
優れたパッケージマネージャーは、依存関係グラフを解決して、各ライブラリの正しいバージョンをインストールできます。
ソース管理と依存関係管理は非常に異なる動物であり、異なるツールが必要です。