「バージョンコントロールシステムの比較」の版間の差分

2016年11月7日 (月) 10:27時点における版

このページはまだ正式に公開されていない下書きです。

まだ、間違いや嘘がたくさん混じっているはずです。

ご注意ください！！！

バージョンコントロールシステム(VCS)の基本

まずここではバージョンコントロールシステム(以降VCS)の基本的な考え方と用語について解説します。

リポジトリ

VCSは様々なファイルやディレクトリをひとまとめにしてそのバージョンを管理します。このひとまとめにしたファイルやディレクトリなどの内容を集めたものをリポジトリといいます。

単にファイルやディレクトリを集めただけでは、それは単なるファイルシステムですが、 リポジトリの中のファイルやディレクトリには「歴史」が含まれており、ファイルやディレクトリがいつ誰によって作られ、どのように変更されて行ったかが全て保存されています。

リポジトリの中には様々な時点のファイルやディレクトリの状態が、何らかの方法で全て保存されており、ファイルやディレクトリを任意の時点の状態に復元することが可能です。

スナップショット

VCS はリポジトリにファイルやディレクトリの様々な時点の「状態」を再現することができますが、特定の時点のファイルやディレクトリの状態のことを、ここでは「スナップショット」 と呼ぶことにします。

「スナップショット」にはファイルやディレクトリの状態の他に、スナップショットを登録した人や登録日時など様々な情報が追加されています。

スナップショットは

Subversion では リビジョン、
Git では スナップショットやコミット、
Mercurial ではコミットやチェンジセット

と呼ばれます。

スナップショットの実態は、隣の世代のスナップショットとの差分情報やファイルへのポインタ情報を中心にした小さなものであることが多いため、Mercurial のようにまるで変更履歴のように言うこともあります。しかし、スナップショットとは、その実装という観点では、リポジトリに含まれる、ある時点での全てのファイルとディレクトリを復元するのに必要な情報にたどり着くための情報のことです。

スナップショットとは論理的にはある時点での全てのファイルとディレクトリの状態＋αとと考えてよいものです。 つまり、「スナップショット」という言葉通り、フォルダとファイルのある時点での状態を切り取ったスナップ写真(記念写真)です。

Tip: Mercurial はフォルダ情報を保持しないため、空のフォルダは再現できず消えてしまいます。

リポジトリの歴史

歴史の形

リポジトリはスナップショットの集合体ですが、それだけでは VCS としてあまり役に立ちません。

我々が VCS を使うのはリポジトリの歴史をリポジトリに刻み、またリポジトリの歴史を辿りたいからです。リポジトリに歴史があるので、われわれはVCSのなかから目的のスナップショットを選ぶことができるのです。

リポジトリの歴史とは、どのスナップショットを元に、次のスナップショットが作られていったかを示す一連の情報です。

上図はリポジトリの歴史を模式的に表したものです。図中の丸はひとつのスナップショットを表しています。

左端の「開始」とかかれたスナップショットは、リポジトリに最初に登録されたスナップショットです。利用者はこのスナップショットをベースにファイルやディレクトリを修正/追加/削除して次々に新しいスナップショットを作成してリポジトリに登録してゆきます。

図ではスナップショットAは開始のスナップショットを修正して、スナップショットBはスナップショットAを修正して作られたものです。

矢印のバルーンコメントにどのような修正が有ったか書いてありますが、これも歴史に含まれる情報のひとつです。この情報ももちろんとても有用な情報ですが、最も肝心な歴史の情報は、どのスナップショットがどのスナップショットから作られたかということです。これが歴史全体の構造を決めます。

分岐

歴史は基本的にはスナップショットA、Bのように直線的に延びて行きますが、スナップショットCとDのように、同じスナップショットを修正して作られるものもあります。このように枝分かれすることを、この記事では「分岐」と呼び、分岐する際の起点となるスナップショットを 「分岐点」と呼ぶことにします。

マージ

スナップショットEのように、２つのスナップショットを元に作られるスナップショットもあります。これをこの記事では 「マージ」と呼ぶことにします。マージとは２つのスナップショットを分岐点まで遡ってそれぞれのそれまでの修正を把握し、両方の修正を反映するように作ったスナップショットのことです。

スナップショットの作成は人手によるものですが、マージも例外ではありません。 マージの作成は、その大部分は VCS が自動的に行います。しかし、必ずしも全てを自動的に行えるものではなく、時に両立しない修正を選んだり、新たにコードを編集しなおしたりしてコードの整合性を保つ人による作業が必要になることがあります。

矢印の向き

既にお分かりかと思いますが、スナップショットを結ぶ矢印の方向は過去(修正前)への方向になっています。これには大きな意味はありません。GitというVCSが最近のスナップショットから過去に向かって歴史をさかのぼれるようにリポジトリが作られているので、それを図に採用したに過ぎません。

このドキュメントでは、Gitに敬意を表し、この矢印の方向(過去方向)を採用することにします。

VCSの紹介

この記事では３種類のVCSについて考えます。

Subversion
Git
Mercurial

です。

Subversion

略称

SVN

歴史

21世紀に入る直前、バージョン管理システムと言えば CVS でしたが、多くの問題を抱えるシステムでした。

Collabnet Inc. は 2000年、 Karl Fogel を含む数人を雇って、CVSの改善版の開発に乗り出し、 2001年の夏には、自分自身をバージョン管理できるほどの完成度に達しました。

Subversionは革新的な新しい VCS を目指しませんでしたが、CVSの抱える多くの問題を解決し、CVSの代替として広く普及しました。

特徴

Sunversion は中央リポジトリを提供するサーバと、ファイルやディレクトリを修正してリポジトリに登録するクライアントが有り、クライアント/サーバシステムになっています。

完全なリポジトリはサーバ側にしかなく、クライアント側には、

リポジトリの最新のスナップショットの一部分(サブツリー)を保持するミニリポジトリ
ミニリポジトリから取り出された編集中のファイルやフォルダがある作業フォルダー

が有ります。

クライアントは作業フォルダとミニリポジトリの比較結果をサーバの中央リポジトリに送り、スナップショットを登録する仕組みになっています。

このようにSVNは中央集権型のVCSですが、ローカルなミニリポジトリも持っており、ミニリポジトリを更新(update)すると、作業用フォルダも自動的に更新(人手によるコンフリクト処理もを含む)をするあたりは分散型のVCSと少し似ています。

基本的に「分岐」という考え方はなく、SVNのブランチは、リポジトリのサブツリーをコピーすることで実現しています。つまり「分岐」を含むリポジトリ全体はひとつのスナップショットですが、コピーされたサブツリーの中は 別のスナップショットと使う側がみなすという疑似的な分岐でしかありません。

この方式の大きな欠点は、スナップショットの持つ歴史を全く分離できていないことでしょう。スナップショットは分離されていないので、各ブランチに対する記録はいっしょくたに、一直線の歴史に記録されてしまいます。つまり一直線の歴史の中に多数の分岐の情報が混じっており、後のブランチのマージをひどく困難にします。