1.1 はじめに - バージョン管理について

多くの人々が選択するバージョン管理方法は、ファイルを別のディレクトリ（賢い場合はタイムスタンプ付きディレクトリ）にコピーすることです。このアプローチは非常にシンプルであるため非常に一般的ですが、非常にエラーが発生しやすいという欠点もあります。どのディレクトリにいるかを忘れ、誤って間違ったファイルに書き込んだり、意図しないファイルをコピーしたりすることは簡単です。

この問題に対処するために、プログラマーは長い間、改訂管理下にあるファイルへのすべての変更を保持する単純なデータベースを持つローカルVCSを開発してきました。

最も人気のあるVCSツールの1つはRCSと呼ばれるシステムで、現在でも多くのコンピューターに配布されています。RCSは、パッチセット（つまり、ファイル間の違い）を特別な形式でディスクに保持することで機能します。その後、すべてのパッチを追加することで、任意の時点でのファイルの外観を再作成できます。

次に人々が遭遇する大きな問題は、他のシステムの開発者と共同で作業する必要があることです。この問題に対処するために、集中型バージョン管理システム（CVCS）が開発されました。これらのシステム（CVS、Subversion、Perforceなど）には、すべてのバージョン管理されたファイルを含む単一のサーバーと、その中央の場所からファイルをチェックアウトする多数のクライアントがあります。長年にわたり、これはバージョン管理の標準となっています。

この設定は、特にローカルVCSと比較して多くの利点があります。例えば、プロジェクトの全員がある程度、互いの作業内容を把握できます。管理者は、誰が何ができるかを細かく制御でき、すべてのクライアント上のローカルデータベースを扱うよりも、CVCSの管理ははるかに容易です。

しかし、この設定にはいくつかの深刻な欠点もあります。最も明らかなのは、中央サーバーが単一障害点となることです。そのサーバーが1時間停止すると、その間は誰も全く共同作業ができず、作業中の変更をバージョン管理して保存することができません。中央データベースが格納されているハードディスクが破損し、適切なバックアップが保存されていない場合、プロジェクトの全履歴が完全に失われます。クライアントマシン上にたまたま存在するスナップショットを除くすべてです。ローカルVCSもこの同じ問題に悩まされます。プロジェクトの全履歴が単一箇所に存在する時はいつでも、すべてを失う危険性があります。

ここで、分散型バージョン管理システム（DVCS）が登場します。DVCS（Git、Mercurial、Darcsなど）では、クライアントはファイルの最新のスナップショットをチェックアウトするだけでなく、その完全な履歴を含むリポジトリ全体を完全にミラーリングします。したがって、サーバーが停止した場合でも、これらのシステムがそのサーバーを介して連携していた場合、クライアントリポジトリのいずれかをサーバーにコピーして復元することができます。すべてのクローンは、実際にはすべてのデータの完全なバックアップです。

さらに、これらのシステムの多くは、複数のリモートリポジトリをうまく処理できるため、同じプロジェクト内で同時に異なるグループの人々と異なる方法で共同作業を行うことができます。これにより、階層モデルなど、集中型システムでは不可能な、いくつかのワークフローを設定できます。