12

導入と背景

私たちはソース管理システムを変更する過程にあり、現在 git と mercurial を評価しています。総コード ベースは約 600 万行のコードなので、大規模でもなく、それほど小さくもありません。

まず、現在のリポジトリの設計がどのように見えるかについて、非常に簡単な紹介から始めましょう。

完全なコード ベース用の 1 つのベース フォルダーがあり、そのレベルの下には、いくつかの異なるコンテキストで使用されるすべての種類のモジュールがあります。たとえば、「dllproject1」と「dllproject2」は完全に別のプロジェクトと見なすことができます。

私たちが開発しているソフトウェアは、お客様のさまざまなニーズに合わせて無限にカスタマイズできるコンフィギュレーターと呼ばれるものです。合計で、おそらく 50 の異なるバージョンがあります。ただし、1 つの共通点があります。それらはすべて、いくつかの必須モジュール (mandatory_module1 ..) を共有しています。これらのフォルダーには、基本的にカーネル/コア コードと共通言語リソースなどが含まれます。すべてのカスタマイズは、他のモジュール (module1 ..) 間の任意の組み合わせにすることができます。

現在 cvs を使用しているため、CVSROOT/modules ファイルにエイリアスを追加しました。それらは次のようになります。

core –a mandatory_module1 mandatory_module2 mandatory_module3
project_x –a module1 module3 module5 core

したがって、誰かが project_x で作業することを決定した場合、必要なモジュールを次の方法ですばやくチェックアウトできます。

base>cvs co project_x

質問

直観的には、ベース フォルダーを単一のリポジトリとして持つのは間違っていると感じます。プログラマーとして、作業中の現在のプロジェクトに必要な正確なコード サブセットをチェックアウトできるはずです。これについてどう思いますか？

一方、これらの各モジュールを別々のリポジトリに置く方が適切だと感じます。しかし、これにより、プログラマーが必要なモジュールをチェックアウトすることが難しくなります。単一のコマンドでこれを実行できるはずです。だから私の質問は: git/mercurial でエイリアスを定義する同様の方法はありますか?

その他の質問、提案、ポインタは大歓迎です!

PS。同様の質問を検索しましたが、私の状況に 100% 当てはまるものはありませんでした。

4

2 に答える 2

13

簡単なコメントで次のことを思い出してください。

  • これらの移行では、多くの場合、ソースを再編成する機会が提供されます。これは、モジュールごと (それぞれに 1 つのリポジトリーがある) ではなく、機能ドメインの分割 (同じ特定の機能ドメインの複数のモジュールが同じリポジトリーに配置されている) に沿って行われます。

次に、構成を定義する方法として、サブモジュールを使用します。

[...] CVS です。つまり、「一度に 1 つのファイル」モデルにかなり指向することになります。

これは、100 万個のファイルがあり、そのうちのいくつかだけをチェックアウトできるという点で優れています。他の 999,995 個のファイルの影響を確認することさえできません。

Git は基本的に、リポジトリ全体よりも少ないものを実際に見ることはありません。物事を少し制限しても (つまり、一部だけをチェックアウトするか、履歴を少しだけさかのぼらせます)、git は常に全体に気を配り、知識を持ち歩くことになります。

したがって、すべてを 1 つの巨大なリポジトリとして見なすように強制すると、git のスケーリングは非常に悪くなり ます。おそらく改善できるでしょうが、その部分は本当に修正可能だとは思いません。

そして、はい、「大きなファイル」の問題があります。巨大なファイルについて何をすべきか本当にわかりません。私たちは彼らを嫌っています、私は知っています。

前述の 2 つのポイントは、大規模なシステム (および大規模なレガシー リポジトリ) に対して、よりコンポーネント指向のアプローチを提唱しています。

Git submoduleを使用すると、プロジェクトでそれらをチェックアウトできます (2 段階のプロセスであっても)。ただし、サブモジュールの管理を容易にするツールがあります (たとえば git.rake )。

複数のプロジェクト間で共有されているモジュールのバグを修正することを考えているとき、バグを修正してコミットし、すべてが更新を行うだけです

それが私がVendor Branchの投稿で「システム アプローチ」として説明していることです。全員がすべての最新 (HEAD) に取り組み、少数のプロジェクトに効果的です。
ただし、多数のモジュールの場合、「モジュール」の概念は依然として非常に便利ですが、その管理は DVCS と同じではありません。

  • 密接に関連するモジュール (別名、「同じ機能ドメイン内」、「PNL - 利益と損失 - または「リスク分析」、金融ドメインに関連するすべてのモジュール) の場合、最新 (HEAD) で作業する必要があります。関係するすべてのコンポーネント.これは、サブツリー戦略
    を使用して達成されます, 他のサブモジュールの修正を公開 (プッシュ) するためではなく, 他のチームによって行われた作業を追跡するため. Git はそれを可能にします.この「追跡」は、リポジトリと 1 つの「中央」リポジトリ間で行う必要はありませんが、他のチームのローカル リポジトリとの間で行うこともできます。同様の性質のプロジェクト。

  • ただし、機能ドメインに直接含まれていないモジュールの場合、サブモジュールはモジュールの修正バージョン (コミット) を参照するため、より適切なオプションです。
    低レベルのフレームワークが変更された場合、それを伝播させたくない即座に、他のすべてのチームに影響を与えるため、コードをその新しいバージョンに適応させるために行っていた作業を中止する必要があります (ただし、他のすべてのチームがこの新しいバージョンを認識できるようにする必要があります)。その低レベルのコンポーネントまたは「モジュール」を更新することを忘れないでください)。
    これにより、他のモジュールの正式に安定した識別されたバージョンのみを使用でき、潜在的に不安定な HEAD または完全にテストされていない HEAD を使用することはできません。

于 2009-05-22T18:54:40.783 に答える
5

Mercurial 側に関しては、大規模なレガシー CVS/SVN リポジトリをより小さなコンポーネントにリファクタリングすることも推奨されます。共通コードは独自のライブラリに配置する必要があり、アプリケーション コードは、他のライブラリに依存する方法と同様に、それらのライブラリに依存します。

Mercurial には、「ソース ツリー」の「フォレスト」を管理できるフォレスト拡張機能があります。このアプローチでは、複数の小さなリポジトリを 1 つの大きなリポジトリに結合します。CVS では逆のことを行います。大きなリポジトリの小さな部分をチェックアウトします。

私は個人的にフォレスト拡張機能を使用したことがなく、そのページには、Mercurial にバンドルされているものと比較して、更新されたバージョンを使用する必要があると書かれています。ただし、OpenJDK プロジェクトで Sun のような大きな組織によって使用されています。

Mercurial wiki のネストされたリポジトリ ページの設計に従って、サブリポジトリ レポートを Mercurial のコアに直接追加する作業も現在進行中です。

于 2009-05-24T18:40:10.327 に答える