wakatonoの戯れメモ

はてなダイアリーから引っ越してきました。

CVSユーザのためのSubversionガイド

Subversion

Subversion for CVS Usersの邦訳っす。ちなみに原文はMike Masonによるものです。

訳はwakatonoによるものですが、原文に忠実でなかったり、はしょってたりします（汗）。


CVSは、Open Source なバージョン管理システムのデファクトスタンダードである。オープンソースプロジェクトが最も多く集うSourceForgeにおいて、プロジェクトのソースコードを管理するためにCVSを用いているが、これは数千という開発者がこのシステムに親しんでいるということを意味している。しかし、CVSが長い間使われ続け、新しいソース管理システムの準備が出来た。3年という開発期間を経て、Subversion 1.0 がリリースされた。

このガイドは、Subversionの新機能についてもっと知りたいCVSユーザを対象にかかれている。しかし、このガイドは他のソース管理システムに慣れたユーザがSubversioが何を提供するを理解する際にも有用である。我々は、Subversionの思想と設計や、CVSと比べて何が改善されたのか、そしてどのようにして使いはじめればよいかについて解説する。

  • Subversionの歴史

    もともとは、CollabNetがKarl Fogelに対してCVSにかわるバージョン管理システムを開発しないか？と持ちかけたところに端を発している。

    CVSは、歴史的な経緯を引きずっているのに対して、Subversionはそういうしがらみは一切ない。また、CVSは基本的にはファイルベースの管理であるのに対し、SubversionはDBによるデータ管理が行われているのもポイントである。


    Subversionには、CVSに実装されているタグ、ブランチ、マージは全て実装され、さらに新しい機能も追加されている。具体的には以下のようなものが実装されている。

    • ディレクトリ、ファイル、メタデータのバージョニングサポート
    • 移動や複製、そして名前の変更も含めた（操作）履歴の追跡
    • 真に不可分の（アトミックな）コミット
    • 手軽なブランチ／マージ操作
    • 効果的なネットワーク利用
    • オフライン環境での差分取得やリポジトリ内容のrevert（編集前の内容の復帰）
    • バイナリファイルの効果的な操作

  • Subversionで使用される用語


    • リポジトリ(repository)

      バージョン管理される全てのファイルが格納されるところ。CVSのdepotに似ている。

    • ワーキングコピー(working copy)

      Subversionからチェックアウトされ、ユーザのローカルディスクに保存されるファイルセット。CVSのワーキングディレクトリに似ている。

    • タグ(tag)

      Subversionのタグは、ディレクトリツリーの読み出し専用のコピーである。

      一方、CVSのタグやラベルは、depot中の各ファイルのプロパティである。

      どちらもバージョンコントロール配下にあるファイルの「既知の状態」を取得するのに使われる。

    • プロパティ(property)

      ファイルと関係した任意の（もしかしたらバイナリ値かもしれない）メタデータである。

      プロパティは、ファイルの内容と同じようにバージョン管理される。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ではそれとは対照的に、コミットを実施する際には対象となるファイル全てを送っている。

  • Networking Options

    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のみの」開発チームにて使えるようになるための障壁を下げている。

  • Subversion Tools

    CVSのためには多くのツールがあり、それらのツールがあることで、利用可能なバージョン・コントロール・ソフトウェアの中で最もサポートが充実したものとせしめている。SubversionがCVSを置き換えられるようになるためには、そういうようなツールによるサポートが不可欠である。幸いなことに、多くのツールがすでに利用可能である。

  • さらなる情報

    • subversion.tigris.orgは、Subversionの公式なホームである。ここからはプロジェクトに関連したさらなる情報や、あなたの使用しているOS向けのパッケージが取得可能である。そして、FAQも取得可能だ。

    • svnbook.red-bean.comには、公式な Subversion book があり、2004年の半ばに出版される予定である。これはSubversionの主なリファレンスマニュアルであり、あなたが持っている疑問に答えるものである。

    • users@subversion.tigris.orgは、他のSubversionユーザから助けを得られる（訳注：得られるかもしれない）MLである。FAQから答えが得られないようならば、メッセージを送ってみるといいだろう。リアルタイムなchatを他の方々と実施したいならば、irc.freenode.netの チャンネル #svn に join してみるといいかと思う。

    • collab.netは、開発およびSubversionのホスティングのための資金を提供し、複数のSubversion開発者をフルタイムで雇用している。

Subversionの大きな利点の1つ

WebDAV Subversion

そういや、WindowsでCVSサーバって聞かないなぁ…とか思ってたら、考えてみれば死ぬほどめんどくさそう（汗）。
ファイルベースのバージョン管理だから、ファイルの命名規則とかファイルシステムの制限にびしばし引っかかりそうだし（NTFSもこのあたりは変わらないか）。
Subversionは、ファイルベースじゃなくってDBベースのリポジトリだから、リポジトリに採用するDBの内部管理さえちゃんと実装されていれば、ファイルシステムでの名前の制限とかは無縁。
実は気づいてる範囲の制限（というか問題点）はいくつかあるんだけど、それはまだ確認取れてないんでまたそのうちに（汗）。

2004/12/28（火）〜30（木）

予定

冬祭り。ここ数年、29〜30の日程で冬祭りなので、仮メモ。
設営こみで3日になるのか、当日が3日になるのかは知りませんが（昨年末は、12/28が日曜日だったから3日間だったのかな、と考えると、今年は設営が28、当日が29〜30になるかな？）。