10 年以上にわたって非常に大きなレガシー CVS リポジトリ (66GiB) があり、さらに増加しています。現在、いくつかの下請け会社があり、いくつかのモジュールとブランチに取り組む必要があります。
それらのためにいくつかのブランチを作成し、そのブランチを送信する必要があります。また、それらの変更を時々メイン ブランチにマージする必要があります。
私たちの懸念は次のとおりです。
リポジトリ全体を完全に提供することはできません。主に懸念されるのはセキュリティです。
「HEAD」バージョンのコードだけでなく、何らかの履歴情報を送信する必要があります。
まだいくつかの開発作業を行っているため、時々変更セットを送信する必要があります。
GIT と Mercurial は CVS からの移行に適していますか? GIT/Mercurial は私たちのニーズを満たすことができますか?
編集: 実際には、中央レポの一部に基づいてオフサイト レポを作成する機能を備えた、マルチサイト機能を備えた集中型リビジョン コントロールが必要だと思います。また、サイト間で簡単にマージできます。
Git を使用すると、git subtreeコマンドを使用して下請け業者に提供できるサブディレクトリを「切り取り」、サブコントラクターの変更をメインラインに簡単に再統合できます。必要に応じて定期的に更新することもできます。このgit subtreeコマンドは元はアドオンでしたがcontrib、公式の Git ディストリビューションのディレクトリにロールインされました。
外部ユーザーに提供するリポジトリに含める履歴の量を制限することができます。
ただし、あなたの最大の懸念は、このような大規模な開始リポジトリを持つ DVCS への移行に関するものになると思います。Git はレポを圧縮するので、完了時に 66 GB になることはほとんどありませんが、それでもかなり扱いにくいでしょう (そこに何を保存しているかにもよりますが、おそらく 10 GB のオーダーです)。それが問題だと思わないのなら、それを選んでください。
Mercurial よりも Git に精通しているため、回答を Git に限定しました。
66 GB は多くのように聞こえます。ただし、CVS はあまり効率的にデータを保存しないことが知られています。Git は確かに機能しますが、プロジェクトをいくつかの小さな git リポジトリに分割する必要があります。ほとんどのプロジェクトでは、機能をいくつかの自己完結型サブプロジェクト (多くの場合、サブディレクトリ) に分割することはそれほど難しくありません。通常、任意の git リポジトリのサイズを平均で 1 ～ 2 GB 未満に制限し、5 ～ 10 GB を超えないようにする必要があります。ただし、git はメタデータの圧縮に非常に優れていることに注意してください (たまに実行する限りgit gc)。
ここで、プロジェクトをいくつかのサブプロジェクトに分割したら (「少数」は相対的な用語で、Android には 300 以上あります)、それらを再び首尾一貫したディレクトリ構造に「接着」する方法を見つける必要があります。
これには、次の 2 つの一般的なアプローチがあります。
repoAndroid プロジェクトによって開発されたツールを使用します。サブプロジェクトがどこにチェックアウトされ、どのように結合されているかを追跡する XML ファイル (マニフェストと呼ばれる) を 1 つだけ含む小さな git リポジトリを作成する必要があります。これは Linux と Mac で非常にうまく機能しますが、残念ながら Windows をサポートしていません ( repoOS によるシンボリック リンクのサポートが必要です)。git submoduleます。実際のファイルなしで 1 つの git リポジトリを作成し、元のサブプロジェクトをすべてこのリポジトリにサブモジュールとして追加します。ある意味では、このスーパーgit リポジトリは Android リポジトリ マニフェストと本質的に同じ役割を果たします。このアプローチの利点は、Windows を含むすべての OS でサポートされていることです。現在、巨大なプロジェクトのごく一部のみを共有したい場合は、サブモジュール/サブプロジェクトを標準の git リポジトリとしてパートナーに直接共有することで共有できます。
実際、より便利にするために、Java での git サーバー実装であるGerritをインストールすることを強くお勧めします。これはたまたま非常に強力なコード レビュー エンジンでもあります (Android プロジェクトでも使用されています)。Gerrit のコード レビュー機能は完全にオプションですが (使用したくない場合は使用する必要はありません)、Gerrit の統一されたユーザー認証、ssh キー管理、および git リポジトリごとのアクセス許可を制御する機能を確実に利用できます。これにより、サード パーティとの共有が非常に便利になります。Gerrit を使用して小さなパーツへのアクセスをサード パーティに許可するだけで完了です。
10 年以上にわたって非常に大きなレガシー CVS リポジトリ (66GiB) があり、さらに増加しています。現在、いくつかの下請け会社があり、いくつかのモジュールとブランチに取り組む必要があります。
それらのためにいくつかのブランチを作成し、そのブランチを送信する必要があります。また、それらの変更を時々メイン ブランチにマージする必要があります。
他のすべての人ではなく、下請け業者のみを移行したいようです。これを行わないことを強くお勧めします。全員を改宗させるか、誰も改宗させないかのどちらかです。混合システムを実行することは、特に DVCS の人々から変更を取得することになると、非常に苦痛です。
私たちの懸念は次のとおりです。
- リポジトリ全体を完全に提供することはできません。主に懸念されるのはセキュリティです。
CVS リポジトリに複数のモジュールがあり、それらにすべてのモジュールを提供することはできませんか、またはそれらがアクセスできる履歴を制限したいですか?
DVCS は、モジュールが 1 つのリポジトリに複数のモジュールを格納するのではなく、個別のリポジトリとして格納されている場合にはるかにうまく機能します*。これには多くの理由がありますが、主に異なるモジュールの変更によって不要なマージが発生しないようにするためです。
(* CVCS もそうですが、通常、新しいモジュールを作成するのは非常に面倒で、一度しか実行しない場合があります。分割した場合、66GB にはならないのではないかと思います。)
したがって、変換する場合は、モジュールを分離する必要があります。これにより、一部のモジュールを共有し、他のモジュールを共有できなくなります。Mercurial は、変換中にマルチ モジュール リポジトリ内に設定されたパスからリポジトリを作成できることを知っています。Git にも同様の機能があると思います。
- 「HEAD」バージョンのコードだけでなく、何らかの履歴情報を送信する必要があります。
これはほとんど DVCS を指示します。定義属性です。
- まだいくつかの開発作業を行っているため、時々変更セットを送信する必要があります。
...これが、彼らと同じ VC ツールを使用する必要がある理由です。そうしないと、システム間での変更セットの変換にすべての時間を費やすことになります。
GIT と Mercurial は CVS からの移行に適していますか? GIT/Mercurial は私たちのニーズを満たすことができますか?
はい & はい。ただし、プッシュ ボタンのトランジションではありません。計画、コミットメント、教育が必要です。
編集:実際には、中央レポの一部に基づいてオフサイト レポを作成する機能を備えた、マルチサイト機能を備えた集中型リビジョン コントロールが必要だと思います。また、サイト間で簡単にマージできます。
集中型だが分散型のバージョン管理システム。わかった！
最後に、集中型/分散型の開発手法と集中型/分散型のツールを混同しないでください。分散型 VCS を使用した集中型開発モデルで作業することは完全に合理的です。
git を選択します。プロジェクトとそれぞれのサブプロジェクト間の依存関係をより適切に制御できるため、可能であればツリーよりもサブモジュールを優先してください。
サブツリーとサブヒストリーの質問については、私はよく知らないので、他の投稿者に答えてもらいます。ただし、レポのサイズについていくつかお伝えできます。まず、git リポジトリは CVS よりもはるかに小さい可能性が非常に高くなります (現在の 66GiB の 10 分の 1 から 2 分の 1 になると思います)。
次に、はい、CVS リポジトリ全体を 1 つの git リポジトリに配置すると、社内の開発者が個々の PC にリポジトリ全体のコピーを持つことになります。私が日常的に使用している git リポジトリは 12 GB で、実際の問題は発生しません。作業コピーが大きいためにリポジトリが大きいと仮定すると、ネットワーク経由でそれほど多くのファイルをフェッチしないため、ブランチ間を移動するときに実際にかなりの時間を節約できます。私たちにとって、12 GB の git リポジトリはそれほど大きな問題ではありません。現在の作業コピー (ほとんどのターゲットのビルド オブジェクトを含む) は、git リポジトリ自体の上に追加の 37 GB であるためです。このサイズのリポジトリでは、git のコマンドは、subversion のコマンドよりもはるかに高速に動作します。
したがって、サブツリーやモジュールなどについて他の人が言っていることを必ず読んでください。ただし、必要に応じて、すべてをインポートするだけでよいので安心してください。