CVSは、Open Source なバージョン管理システムのデファクトスタンダードである。オープンソースプロジェクトが最も多く集うSourceForgeにおいて、プロジェクトのソースコードを管理するためにCVSを用いているが、これは数千という開発者がこのシステムに親しんでいるということを意味している。しかし、CVSが長い間使われ続け、新しいソース管理システムの準備が出来た。3年という開発期間を経て、Subversion 1.0 がリリースされた。
このガイドは、Subversionの新機能についてもっと知りたいCVSユーザを対象にかかれている。しかし、このガイドは他のソース管理システムに慣れたユーザがSubversioが何を提供するを理解する際にも有用である。我々は、Subversionの思想と設計や、CVSと比べて何が改善されたのか、そしてどのようにして使いはじめればよいかについて解説する。
もともとは、CollabNetがKarl Fogelに対してCVSにかわるバージョン管理システムを開発しないか?と持ちかけたところに端を発している。
CVSは、歴史的な経緯を引きずっているのに対して、Subversionはそういうしがらみは一切ない。また、CVSは基本的にはファイルベースの管理であるのに対し、SubversionはDBによるデータ管理が行われているのもポイントである。
Subversionには、CVSに実装されているタグ、ブランチ、マージは全て実装され、さらに新しい機能も追加されている。具体的には以下のようなものが実装されている。
Subversionは、高性能なBerkeleyDBのフロントエンドとして実装されており、多くのファイルを効率的に操作するのに適している。CVSは、バージョン管理されている各ファイルを操作するために、個々のファイルへのアクセスを実施するが、このことは複数の操作が介在することを意味する。最も顕著なのは、履歴関係の処理やタグ関係の処理の場合であり、このような操作を実施する場合には目に見えて処理が遅くなる。Subversionの場合は、これらのファイルを全てデータベースの管理化に置くことで、CVSに比べて複数ユーザによるリポジトリ操作に関する性能面での改善が行われている。具体的には、遅くて扱いにくいロックファイルの操作が必要なくなっている。後述する不可分なコミットも、データベースをバックエンドとする実装とすることで実現可能となった。Subversionサーバは、サーバのshutdownを行うことなく一貫性があって信頼性の高いバックアップが取得できるようになっている。
Subversionは、リポジトリ中のファイルの状態を記録します。その状態には、ファイルやディレクトリ両方の履歴も保持します。CVSは、ディレクトリに関する履歴を保持することは出来ません。Subversionで管理されるディレクトリは、ファイルなどと同じくバージョン管理可能なオブジェクトなため、こういうことが可能になります。Subversionは、リポジトリ中に存在するバージョン管理されるオブジェクトのバージョントラッキングを可能にします。プロパティは、リポジトリ中のあらゆるバージョン管理対象に対して、ユーザがメタデータを付加することが可能な強力な特徴です。メタデータは、ファイルやディレクトリなどと同じくバージョン管理されます。プロパティは、mime-typeやファイルが実行可能であるべきかどうか、というような情報を格納するのに使われます。プロパティはユーザが定義可能であるため、Subversionを拡張可能にしています。- グラフィックデータのサムネイルのようなバイナリデータをプロパティ中に保持することさえも可能です。
CVSにおいては、ヒストリを損なうことなくファイルを移動させるためには、リポジトリの手動での操作が必要になります。それとは対照的に、移動/コピー/名前変更の操作はSubversion配下では一級のサポートをしており、ブランチやマージなどと同様に、それらの操作の履歴は残ります。
ユーザがSubversionのリポジトリに対する変更をコミットするときには、全ての変更が受け入れられるか、ロールバックされるかのいずれかであり、それは処理が完了した時に他のユーザにも見えるようになる。
リポジトリの変更は、データベースのトランザクションのように動作し、コミット処理は不可分なものとして実施される(全てが一度に行われる)か、何も行われないかのどちらかである。CVSでは、処理が完了するまでの間に個々のファイルを変更する。ネットワークがコミット中に切断された場合には、部分的に変更された状態になり、その状態にされたコードは使えない状態によく追い込まれる。さらに、もしあるユーザが、他のユーザがコミットしている最中にワーキングディレクトリをアップデートしていたら、CVSサーバに「部分的に」コミットされた内容を取得することになる。Subversionは、これらの問題の両方を解決する。
Subversionの不可分なコミット機構は、変更を1つの論理的なグループに単一のコミットメッセージ(リビジョンもしくは変更セットと呼ばれる)とともに保持し、その論理的なグループに対してリビジョン番号を割り当てる。リビジョン番号は、実際には全てのリポジトリに適用され、その番号はリポジトリの状態を表現したり、ある時点でのリポジトリの状態を再生成するのに使われる。開発者は、「オレはrevision 646でそれをFIXした」と言ったならば、他の開発者はただちにその変更を見ることができる。CVSでは、バージョン履歴とコミットメッセージは個々のファイルに記述されている。このため、リポジトリの長々としたスキャンなしには他のどのファイルが更新されたかというのをわかる手段がない。これとは対照的に、Subversionにおける履歴の閲覧は高速である。
変更セットは、PerforceやBitkeeper,Archのようなシステムを使っている人には良く知られており、その概念は非常に強力なものである。複数のファイルに対する変更をひとまとめにし、1つの論理的な単位にすることで、開発者はそれらの変更をよりよく系統立て、その変更を追跡可能になる。変更セットは効果的なコミュニケーションツールでもある。開発の特定のブランチに対するパッチ適用について議論する際に、この議論に必要なのは単一のリビジョン番号である。全員はどの変更が議論されているかがはっきりわかる。さらに変更セットを用いることで、長いタイムスタンプ(それらは多くの場合正しくない)に頼る必要なしに変更を適用することを容易にする。
Subversionは、リポジトリの格納場所としてデータベースを採用しており、ファイルの"lazy copy"を高速に実行可能である。Subversionは、lasy copyをブランチやタグとして利用するが、これは単純に作業している内容(トランク/trunk)を、ツリー上の新しい場所にコピーするだけだ。Subversionは、共通の履歴上でそれをトラッキング可能である。この方法でタグやブランチを実現した場合、サーバ上のディスクスペースはほとんど消費せず、操作も簡単に実現可能だ。一方、CVSでは履歴をバージョン管理されているファイルに保存し、ブランチを作成する際にはリポジトリの全てのファイルについて更新が成功していることが必要である。Subversionでは、タグは単に読み出し専用で更新されないブランチとして表現されるだけだ。
lazy copyのしくみを使うことで、Subversionは変更をマージを非常に高速に実施できる。全てのブランチについて、単純なデータベースへのクエリを発行することで変更を追跡することが出来、正確なマージのための情報を非常に高速に生成することが可能である。
Subversionの設計者は、この数年でディスクスペースが爆発的に増加している一方でネットワークの帯域はそうでもないということに着目し、Subversionではユーザのワーキングコピーにリポジトリに格納されるファイルの完全なコピーを保存し、これらを活用することでネットワークの使用率を可能な限り減らすようにしている。Subversionは、ネットワークを経由することなく差分を取ったり(訳注:これは、作業してる内容とそのもとになった内容の差分を指すと思われる)作業した内容を元に戻したりする処理をネットワークを経由せずに実施することが可能であり、サーバ上から更新された情報をもってきたり、サーバに対して発生した変更をコミットする際には差分情報をやりとりしている。CVSではそれとは対照的に、コミットを実施する際には対象となるファイル全てを送っている。
Subversionは、整然とした、階層化された設計をなされており、リポジトリにアクセスするための複数のしくみを許している。最もシンプルなのは、file://プロトコルであり、ローカルディスク上のリポジトリを操作するためのものである。svnserveプログラムは、svn://プロトコルによるネットワーク越しのリポジトリアクセスのためのシンプルなサーバ機能を提供する。これはCVSにおける pserverに似ているが、パスワードなどについて平文での送信は行わない。さらにセキュアなアクセスが必要なユーザは、svn+ssh://プロトコルを使用することが可能だ。これは、SSHによるトンネルを開設し、その上でsvnプロトコルを使う。これは、SSH越しでCVSコネクションを使うのに似ている。
Subversionは、HTTPやHTTPSプロトコルを用いたリポジトリアクセスのためにApache Webサーバの力を借りることも可能だ。Subversionを使うにあたってApacheを必要としないことを理解することは重要だが、もしWeb経由でリポジトリを操作したいならば、Apacheのセキュリティや認証のしくみを使えるのは大きな利点となるだろう。
Apacheと組み合わせた場合、SubversionはWebDAVおよびDeltaVプロトコルを使ってバージョン管理されるファイルシステムを表現することになる。多くのOSがこれらのプロトコルをサポートするようになっている。 -- 例えば、Windows XP の「Webフォルダ」は、Subversionのリポジトリにアクセスすることが可能である(訳注:Windows XPのWebフォルダを使ってSubversionのリポジトリにアクセスする場合には、WebClientサービスを停止しなければエラーになることがある)。
CVSは、バイナリファイルの各バージョンを個々に保存している。これは、100kバイトのバイナリファイルについて10のバージョンを保存している場合には、1MBのディスクスペースがサーバ上に必要であることを意味する。Subversionは、全てのファイルをバイナリとして保存し、それらのバージョン間について効果的な差分取得アルゴリズムを適用して差分化し、保存している。ファイルをバイナリで保存することは、テキストファイルの行の終了にまつわる多くの問題を回避することにもなる。Subversionでは、行末の符合を、リポジトリからの更新や、リポジトリへのコミットの両方で変換するように設定することが可能である。
Subversionは、さまざまなプラットフォームの上で使うことができる。
バイナリは、Windows用のものや、多くのLinuxディストリビューション用、Solaris用、そしてMac OS X 用のものが用意されている。あなたが使ってるOS用のパッケージが用意されていなければ、ソースコードをダウンロードしてコンパイルすればよい。それはたやすい作業である。Subversionが実際にCVSに勝るところは、、Windowsでの堅牢なサーバサポートであろう。Subversionサーバは、Windows 2000, Windows Server 2003, Windows XP の上で問題なく走行させることが可能だ。その一方、CVSサーバをUNIX以外のあらゆるプラットフォーム上で動作させるためには、かなり大変である。重要なことに、このサポートはSubversionを利用しはじめるにあたり、そして「Windowsのみの」開発チームにて使えるようになるための障壁を下げている。
CVSのためには多くのツールがあり、それらのツールがあることで、利用可能なバージョン・コントロール・ソフトウェアの中で最もサポートが充実したものとせしめている。SubversionがCVSを置き換えられるようになるためには、そういうようなツールによるサポートが不可欠である。幸いなことに、多くのツールがすでに利用可能である。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家