前回は，Apache Software Foundation（以降，ASF）の開発サーバーの環境について紹介した。そして，リソース管理にはCVS以外に最近ではSubversionが用いられるようになってきたことをお話ししたが，今回はこのSubversionについてもう少し詳しく説明する。

　Subversion はASFが開発したプロダクトではないが，その存在はオープンソース・プロダクトを利用する我々にとって無視できなくなってきている。オープンソース・プロダクトは世界中に分散しているボランティアが作成した，プログラム・ファイルやドキュメント，画像ファイルやデータ・ファイルなどから構成されている。それらリソースが正しく更新されることや更新の競合が解決できるツールすなわち，バージョン管理システムがその開発を支えている。

　多くのオープンソース・プロダクトではCVS(Concurrent Version System)が利用されてきたため，我々オープンソース利用者もプロダクトの最新のソースコードを入手するためにCVSを利用していた。しかし，目的プロダクトのリソースがSubversionで管理されている場合には，当然Subversionから入手するより他はない。Subversionを採用するオープンソースのプロダクトが今後増えてゆくことが予想されるため，我々利用者もそれに対応してゆく必要があるだろう。

多くの点でCVSよりも優れる

　Subversionはオープンソース・プロダクトの開発をサポートするTigris.orgで開発が行われている，オープンソースのバージョン管理システムだ。開発にはCollabNet社が深く関与しているが，Subversionの配布ライセンスは，ApacheおよびBSDスタイルのライセンスであり，変更や再配布に対する制限がなく利用しやすくなっている。

　SubversionはCVSの後継システムを目標に開発され，多くの点で CVS よりも優れている。同様のツールにはGNUのArchなどが存在する。CVSの問題点を克服し，より優れた機能を提供ようとしている点ではどのツールも同様だが，現時点では技術的機能的優位というよりも，利用しやすい配布ライセンスやCVSライクなコマンド・ラインインタフェースなどの政治的な理由によってSubversionが一歩リードしているというのが現状だろう。なかでも，CVSライクなインタフェースを採用したことは，CVSユーザーが戸惑いなくSubversionへ移行できるため，人気に拍車をかけている。

Subversionの概念

　具体的にはどのような機能を提供し，どのような点がCVSより優れているのだろうか。SubversionもCVSと同様にバージョン管理システムだ。そしてCVSと同様のインタフェースを提供している。しかし，その概念や機能，仕組みはCVSのそれとは大きく異なる。まずはSubversionの概念と機能から紹介する。

  • ディレクトリをバージョン管理

    　CVSでは個々のファイルの履歴のみが管理されていたが，Subversionではディレクトリツリー全体としてバージョンが管理される。Subversion管理下のファイル（例えばファイルA）をコミットした場合，ディレクトリ全体のバージョンが上がり，そのバージョンにおけるファイルAの状態が保存されるようになっている。すなわち，CVSのようにディレクトリ全体にタグを付けなくとも，ディレクトリ全体のバージョンが管理可能となる。

  • 不分割なコミット

    　Subversionでは複数のファイルをコミットする場合に，それらが一括して反映されるようになっている。これにより，コミット中の何らかのトラブル（ネットワークやディスクトラブルなど）が発生した場合に一部のみがコミットされて，リポジトリ内の整合性を壊すといったことがなくなる。リポジトリの更新処理は，すべて成功するかすべて失敗するかの２つに１つしかありえないようになり，リポジトリの整合性が保障されやすくなっている。

  • 複数のリポジトリ・アクセス方式

    　Subversionは同一システムからのリポジトリ・アクセス以外に，ネットワーク経由のリポジトリ・アクセスの機能を標準で提供している。CVSのようにネットワーク・アクセスのために別のパッケージを導入する必要はない。その通信方式にはHTTP，独自プロトコルなどが利用可能であり，認証機能やセキュア通信にも当然対応している。また，リポジトリアクセス用の新しいネットワークプログラムを簡単に実装できるようになっており，今後別の方式が提供される可能性もある。

  • コピー・修正・マージ機能

    　複数人による開発を実現するためには，同一ファイルに対する複数人による更新をサポートする必要がある。一番簡単なモデルは，修正前にファイルをロックし，ローカルな作業領域で更新（または修正）を行ったのちに更新をリポジトリに反映し，ロックを解除する方法だ。いくつかのバージョン管理ツールではこの方式を採用している。しかし，この方式ではロック中は他者の作業を止める危険があるなどいろいろと問題がある。

    　SubversionではCVSと同様のコピー・修正・マージモデルを採用し前述の問題を回避している。このモデルではローカルな作業領域にあるリポジトリのコピーはいつでも修正可能な状態となっている。そしてこのコピーに対して行った変更がリポジトリに反映される時に，リポジトリの最新状態とのマージが行われるのだ。このようにすることで，他者の作業を止めることなくファイルの更新が行えるようになっている。

  • 真のバージョン管理機能

    　CVSでは，ファイルの移動や削除が非常に困難であったが，Subversionでは履歴を保持したままファイルの移動やリネームを行うことが可能となっている。また，削除済みファイルと同名のファイルを新規で作成する事も可能となっている。Subversionではこれらの操作はファイルとディレクトリの両者に対して同様に行うことが可能となっており，CVS利用時に発生しがちなリファクタリングによるファイルの移動や，空ディレクトリの削除が簡単に行えるようになっている。

  • データ処理の一貫性

    　Subversion は，バイナリ差分アルゴリズムを使ってファイルの差分を表現しており，テキストファイルもバイナリ・ファイルも同じ方法で管理される。よって，CVSよりもバイナリ・ファイルの管理が容易におこなえる。

  • CVSライクな操作

    　CVSとほぼ同じインタフェースをSubversionのコマンドは提供している。具体的にはcvsコマンドに相当するsvnコマンドはcheckout，update，add，status，diff，mergeといったサブコマンドを提供しており，[svn サブコマンド リポジトリパス]といったCVSユーザーにとって違和感のない型式で利用できる。また，ブランチやタグ，マージといった概念もCVSと同様に存在する。

  • ディレクトリ指定によるチェックアウト

    　Subversionでは，チェックアウト対象をリポジトリパスを示すURLによって指定する。URLにはプロトコルとホスト名に続けてリポジトリ内のディレクトリパスが指定可能で，CVSのようにモジュール定義を必要とせずに，リポジトリ内にあるすべてのリソースを直接チェックアウトすることが可能だ。

    指定例）[svn checkout http://svn.collab.net/repos/svn/trunk/doc/book/tools]

  • ローカル・キャッシュによる差分検出

    　Subversionでは，修正元となるファイルのプライベート・キャッシュを保持しています。このキャッシュがあることで，ネットワーク・アクセスを行わずに修正差分の検出や修正の取り消しなどが行える。コミット時には修正したファイルとの差分を検出するために用いられ，差分情報のみを圧縮して送るようになっている。これにより，ネットワーク非アクセス環境での作業が可能となり，ネットワークへの負荷が軽減されるようになっている。

    　このように，SubversionではCVSの問題点が克服されつつ新しい機能が提供されている。