多数のプロジェクトを含むかなり大きなリポジトリがあるとします。私は実際にほとんどのプロジェクトに取り組んでいます。スパースディレクトリ機能を利用して必要なものを取得する「1つの大きな作業コピー」をローカルに作成する必要がありますか、それともすべてのプロジェクトに独自の作業コピーを作成する必要がありますか。長所と短所は何ですか?
4 に答える
どのアプローチを採用するかに影響を与える最大の要因は、次の 2 つです。
- すべてのプロジェクトが大量のライブラリ コードを共有していますか?
- すべてのプロジェクトで同じブランチで作業していますか?
すべての個々のプロジェクトが多くのライブラリ コードを共有し、同じソフトウェア スイートの一部であると見なされる場合、再構築の量を最小限に抑え、1 つのプロジェクトで行われた変更が別のもの (ビルドが壊れる可能性を最小限に抑えます)。
一方、これらのプロジェクトのそれぞれが異なるクライアント向けであり、それぞれに異なるタイムスケールがあり、異なるブランチで実行する必要がある場合 (プロジェクト A は RC フェーズにあり、重大なバグ修正のみが必要な場合、プロジェクト B ははアルファ段階にあり、大幅に変更される可能性があります)、個別のスパース作業コピー アプローチに進みます。
私は同じシナリオを持っています。まばらなディレクトリを使用する代わりに、すべてのプロジェクトを 1 つの構造でチェックアウトしました。次に、目的のフォルダーを選択してコミット/更新するだけで、すべてのプロジェクトを一度に更新するか、一度に 1 つのプロジェクト/フォルダーだけを更新するのが非常に簡単です。そうすれば、必要なときにスペースディレクトリの利点を得ることができます。または、1 つずつ行うのではなく、完全な更新/コミットを行うことができます。私のコレクションは約 5GB、60,000 個のファイルであり、プロジェクト レベルごとでも完了でも、まだ非常に高速です。
各コミット(およびロールバック)がそのプロジェクトに固有になるように、それぞれ1つのプロジェクト。capistranoまたはその他のデプロイツールを使用する場合にも重要です。また、プロジェクトごとにアクセスを制限します。
@the_mandrill が言ったように、プロジェクトが一貫した全体の一部であるかどうかによって異なります。たとえば、単一の Java EE Web アプリケーションに結合された jar ファイルなどです。
同様の状況で、全体的なビルド構成を保持するアンブレラ プロジェクトを使用し、 を使用して子プロジェクトを取り込みますsvn::externals
。Java の世界では、いくつかの欠点はありますが、これは Maven ベースのビルド プラクティスにうまく対応しています。
Visual Studio のプロジェクトとソリューションで同様のアプローチを試す予定ですが、これまでのところ簡単な実験しか行っていません。