今日は、議論の余地のあるやや挑発的な問題-分散バージョン管理システムについてお話します。 このようなシステムはHabraの住民の間で人気があることを知っているので、事前に議論する準備ができています。 さらに、ケースについて何か言いたいことがある場合は、通り過ぎて発言しないことをお勧めします。
そのため、プロジェクトとその中に、このプロジェクトを実装する複数のチームにサービスを提供するバージョン管理システムがあります。 バージョン管理システム-すべてに1つ。 一連のメモを続けていることを思い出させてください。以前、特定の実装をバイパスして、バージョン管理全般について説明しました。 したがって、サブジェクト領域も単純なものから複雑なものへと徐々に進化しています。
そのため、ある時点で、開発センターの1つで中央リポジトリをローカルで使用可能にする必要があります。作業を高速化し、トラフィックまたは帯域幅の制限をバイパスするためです。 地理的に異なる場所とタイムゾーンに配置された2つのチームがあるとします。たとえば、ロシアの極東とアメリカの中央タイムゾーンは、世界の半分だけ離れています。 1つのプロジェクトで作業が進行中であり、製品の同じ部分を変更する必要があります。 バージョン管理システムサーバーが米国にあるとします。したがって、ロシアの開発者は、新しいバージョンを作成するために、世界中の半分に変更を送信する必要があります。 また、選択した構成全体を使用して別のブランチに移動するなどの操作は、pingのサイズを考えると、非常に時間がかかります。 一般に、このような状況では、中央リポジトリは最も便利なオプションではありません。
問題は新しく関連性がないため、時間をかけて問題を解決するためのさまざまなアプローチが策定されてきました。 より正確には、分散制御システムの構築に対する2つのアプローチ。
オープン配布は、構成の各作業コピーが独自の子バージョンのセットを持つことができ、作成されたバージョンが変更作成者の裁量で交換される構築原則です。
このようなシステムの利点は、別のワークステーションでの作業が他のストレージインスタンスから独立して実行できることです。 実際には、ストレージがない場合があります-コピーの数、ストレージの数。 そのようなシステムが主にオープンソースでアプリケーションを見つけたのは驚くことではありません。 別のサーバーを維持する必要がないため、必要な情報のみを交換でき、誰かが決して必要としない可能性のあるデルタでストレージとトラフィックを過負荷にすることはできません。
このアプローチの欠点は、デルタ作業成果物の交換を一元管理することが難しいことです。 集中化に慣れている多くのマネージャーが好まない可能性のあるブラウンデルタの動きが判明しました。
そのようなシステムの例は、BitKeeper、git、Mercurial（Hg）です。
レプリケーションによる配布では、すべての分散サーバー上に中央データウェアハウス（またはその一部）の同等のコピーを作成する必要があります。 ここで、データベースとその複製について類推できます。 各開発者にとって、彼が接続するバージョンのリポジトリが主なものです。 すべてのバージョンとブランチは、中央リポジトリまたはレプリカに作成されます。 データを配布するために、リポジトリのコピーが他の利用可能なサーバーに作成され、一部の開発者は作成されたコピーに切り替えます。 作業結果を交換する必要がある場合、ストレージの複製が発生します。両方のサーバーがメタ情報を交換します。
このアプローチの利点は、同じチームロケーション内での作業の集中化と考えることができます。 また、蓄積された情報の一部を他のチームと同期させないようにすることもできますが、同時にローカルチーム全体で同時に利用できるようにすることもできます。 これは、開発されたサブシステムのコードが外に出てはならない場合、同じ製品で作業している他のチームであっても重要です。
欠点は、複製メカニズムを構成する必要があることです。 ただし、原則として、このアプローチを使用するシステムは、効率的なデータ交換のためのツールを提供します。 さらに、一部の人にとっては、すべてのバージョン操作が開発者のローカルコンピューターではなく同じサーバーで実行されるという事実はマイナスになる可能性があります。 つまり、システムの「配布」はチームとその場所のレベルで現れますが、単純な開発者のレベルでは現れません。
複製されたシステムの例は、ClearCaseおよびPerforceです。
両方のタイプ（オープンとレプリケーション）は互いに類似しています。どちらの場合も、同じ要素セットとバージョンの異なるコピー間で情報が交換されます。 それらの違いは「スケール」にあります。 レプリケーションを使用するシステムでは、原則として、最小レプリカ単位はリポジトリまたはその重要な部分であり、全体として処理されます。 オープンな配信システムでは、情報交換の最小単位は、単一のアイテムの別個のバージョンです。
両方のタイプの分布は、共通の問題によって特徴付けられます。 これは、要素とそのブランチの命名、および結果の構成を示すラベルに関する明確な合意を導入する必要があります。 作業の結果を結合する場合、同じ名前とメタ情報（ブランチ、タグ、属性）を持つ異なるファイルを取得しないでください。 したがって、互いに別々に作業するすべての開発者とチームは、共通の標準に従う必要があります。 異なるシステムには、この状態を提供するメカニズムがあります。 たとえば、ClearCaseを使用する場合、標準への準拠をチェックするメタ情報を作成するためのトリガーが作成されます-作成されたすべてのブランチについて、ブランチの名前にブランチが作成されたサイト（コマンド）のコード（または識別子）が必要です
さらに、オープンディストリビューションを備えたシステムは、実際には個々の開発者の裁量に委ねられています。開発者がデルタの形でチームに提供するものと、公開されないものです。 良くも悪くも、プロジェクトで採用されている文化に依存します。 レプリケーションリポジトリを使用するより集中化されたシステムの場合、この問題は異なる角度から見られます。 全員が（チームの）中央バージョン管理システムに変更を加える必要がある場合、メタ情報ベースのサイズは急速に増大します。これは、ストレージのコストと空間に分散したデータベースの複製速度の両方に影響します。
もちろん、どのアプローチがより良いかは、すべてのプロジェクトですぐに言うことはできません。 gitのブラウン運動を仕事に適合させるか、より安定した状態で停止するかは、各プロジェクトの管理次第です。 すべてのチームとプロジェクトに単一のソリューションはありません。 異なるシステムとモデルの違いに関心がある人-リンク[1]を参照してください。
ところで、バージョン管理システムだけでなく、変更要求の追跡システムも配布できます。 仕事の論理は完全に似ています。 作業の主なモデル-複製のみを次に示します。 例はIBM Rational ClearDDTSです。 そのようなシステムはあまり一般的ではないので、それらについて詳しくは説明しません。
伝統的に、独立した研究に使用され、推奨される情報源：
- en.wikipedia.org/wiki/Comparison_of_revision_control_software-バージョン管理システムの比較。
- lib.custis.ru/index.php/The_Risks_of_Distributed_Version_Control-分散バージョン管理システムに関連するリスクを冷静に見ます。
異なるバージョン管理システムの実装の問題に関する記事をもう1つお勧めします。
lib.custis.ru/index.php/Version_Control_and_%E2%80%9Cthe_80%25%E2%80%9D
少々挑発的ですが、プログラミングコミュニティの進歩的な部分であると考えている人にとっては、まず読む価値があります。 そして、事前に質問に答えてください。いいえ、私はSVNとgitのどちらのファンでもありません。
今日は以上です。 通り過ぎないで、声を出してください。 Perforceを使用している人々の意見を聞くのは興味深いことです。
git / Hg /などのファン-デルタを交換するときに発生する明らかでない問題について聞くのは興味深いことです（デルタはあるべきであるため、何もスムーズかつ完全には起こりません）。
SVNまたはCVSでリポジトリの複製を行った人がいれば、感謝します。
さて-継続する。