Subversion によるバージョン管理

Subversion は、フリーなオープンソースのバージョン管理システムで、 時間とともに変化するファイルやディレクトリを管理します。 ファイルの階層構造全体は、リポジトリと呼ばれる 中心的な場所に置かれます。リポジトリは通常のファイルサーバとよく似ていますが メンバーがファイルやディレクトリにしたすべての変更を記録しています。 このため、メンバーは古いバージョンのデータを戻したり、変更履歴を確認したり することができます。この意味で、バージョン管理システムを、 「タイムマシン」の一種と考える人も います。

Subversion はリポジトリにネットワーク越しにアクセスするので、別々の コンピュータで作業する人々によって利用することができます。ある範囲で それぞれの場所からの同じデータの集まりをさまざまな人が修正し管理する 仕組みは共同作業を支援することができます。すべての変更を一つの流れに そって行うわけではないので作業効率をより高めることができます。 さらに作業はバージョン化されているので、作業品質が流れを中断 するかどうかの兼ね合いであるかどうかを心配する必要はありません— データに対して間違った変更をしてしまった場合には単にそれを取り消せばよい のです。

バージョン管理システムのいくつかは、ソフトウェア構成管理システム(SCM) でもあります。そういうシステムは、ソースコードのツリーを管理するために 特別便利に作られています—たとえばプログラム言語をじかに理解する ことができたり、ソフトウェアを構成するのに必要なツールが付属していたり といった具合です。しかし Subversion はそのような種類のシステムでは ありません。 Subversionはどのような タイプのファイルの集合も管理できる一般的なシステムです。あなたにとって それはプログラムのソースコードかも知れません—しかし別の人にとっては 食料品の買い物リストから、デジタルビデオの編集、そしてもっと他のもの ですらあるでしょう。

2000年の初め、CollabNet, Inc. (http://www.collab.net)は CVS の置き換えを 書く開発者を探し始めていました。CollabNet は CollabNet Enterprise Edition (CEE) ^[2] という 共同作業用のソフトウェアを提供しています。それはバージョン管理システムをその 一部として含んでいました。CEE は最初のバージョン管理システムと して CVS を利用していましたが、CVS の持っている制限は最初から明らかで あり、CollabNet は最終的にもっと良いものを見つけなくてはならないと悟り ました。不幸にも CVS はオープンソースの世界において 事実上の標準となって いましたが、それは単に、少なくともフリーライセンスの下ではそれより良いも のが何もなかったというのが理由の大部分でした。 そこで CollabNet は一から新しいバージョン管理システムを開発することを決め ました。ただし、CVS の基本的な考え方は保持したまま、バグやまずい実装を 含まないようにする形で、です。

2000年の 2 月、彼らはOpen Source Development with CVS (Coriolis, 1999)の著者である Karl Fogel に連絡をとり、この新しい プロジェクトに参加する気はないかどうかたずねました。ちょうど同じころ Karl は既に新しいバージョン管理システムの設計について友人の Jim Blandy と 議論していました。1995 年に二人は CVS のサポート契約を提供する会社、 Cyclic Software を設立し、後にそのビジネスを売却しはしましたが、やはり 自分たちの日常の作業に CVS を利用していました。CVS に関する不満がもと で Jim はバージョン化されたデータの管理について、より良い方法を注意深く 考えることになり、「Subversion」 という名前だけではなく、Subversion リポジトリ の基本的な設計についても既に思いついていました。CollabNet が Karl を 呼ぶと彼はすぐにそのプロジェクトで働くことに同意し、また Jim は 雇用主である Red Hat Software が、不定期の期間にわたって彼を事実上 そのプロジェクトに無償で送り込ませることに成功しました。CollabNet は Karl と Ben Collins-Sussman を雇い、5月から詳細設計が始まりました。 CollabNet の Brian Behlendorf と Jason Robbins、そして Greg Stein (当時はWebDAV/DeltaVの仕様決めを独立した開発者として行っていました が) からのタイミングの良い刺激に助けられ、Subversion は急速に活発な 開発者コミュニティの注意を引きました。多くの人々は CVS について不満を 持っていたことがわかり、最終的に自分たちがその企画に対して何らか貢献 できることを歓迎しました。

最初の設計チームはいくつかのシンプルな目標を決めました。それはバージョン 管理手法の新しい地平を切り開くようなことを目的とはせず、単に CVS の 不具合を修正するものであるとされました。Subversion は CVS の機能に合致し、 同じ開発モデルを踏襲するが、CVS のほとんどの明らかな不具合については 繰り返さないと決められました。そしてそれは CVS を単純な置き換えである必要 はないにせよ、CVS ユーザがわずかな労力によって移行できる程度には十分 似ているべきであるとされました。

14ヶ月のコーディングの後、Subversion は 2001/8/31 に 「自分で自分自身のソースコード管理」が できるようになりました。Subversion開発者は、Subversionの自身のソースコード 管理にCVSを使うのをやめてSubversion自身を使えるようになったということです。

CollabNet がこのプロジェクトを始め、いまだに作業の大部分に出資している わけです(Subversion のフルタイム開発者の給料を払っています)が、Subverion は大部分のオープンソースプロジェクトのように実力主義を促進するような緩やかで オープンないくつかの規則によって成り立っています。CollabNet のコピーライト ライセンスは Debian Free Software Guidelines に完全に合致したものです。 言い換えると、 誰でも自由にSubversionをダウンロードし、修正し、再配布できるということです。 CollabNet や他の誰かの許可を得る必要はありません。

Subversion がバージョン管理の問題に提供しようとする機能についての議論 は CVS のデザインをどのように改良したかという観点から話しをすることが しばしば有用です。CVS になじみがないのであればこれらのすべての機能を 理解する必要はありません。そしてバージョン管理についてまったく知らない のであれば、眠くなるだけかも知れません。まず最初に第2章 基本概念を読んでください。バージョン管理システム一般 についての親切な手引きを用意してあります。

Subversion は以下の機能を提供します:

図 1.1. 「Subversion の構成」は Subversion の「概略」と でも呼べるようなものです。

図 1.1. Subversion の構成

一方の端はバージョン化されたすべてのデータがある Subversionリポジトリ です。もう一方はクライアントプログラムで、バージョン化されたデータの ローカルマシン上のコピー(これを「作業コピー」と言います)を 管理します。この二つの間にさまざまなリポジトリアクセス(RA)層を通じた 通信路があります。そのいくつかはコンピュータネットワークをまたいで リポジトリにアクセスするためのネットワークサーバ越しに通信します。 他のものはネットワークを利用せず直接リポジトリにアクセスします。

Subversion はAPR (the Apache Portable Runtime library)と呼ばれる 可搬性のあるインターフェースの上に作られています。これで Subversionは Apache の httpd サーバが使えるオペレーティングシステムならどれでも 実行させることができます: Windows, Linux, すべての BSDの変種、Mac OS X, ネットウェア、その他です。

Subversion is built on a portability layer called APR—the Apache Portable Runtime library. The APR library provides all the interfaces that Subversion needs to function on different operating systems: disk access, network access, memory management, and so on. While Subversion is able to use Apache as one of its network server programs, its dependence on APR does not mean that Apache is a required component. APR is a standalone library useable by any application. It does mean, however, that like Apache, Subversion clients and servers run on any operating system that the Apache httpd server runs on: Windows, Linux, all flavors of BSD, Mac OS X, Netware, and others.

Subversionを手に入れる一番簡単な方法は自分のオペレーティング システム用のバイナリパッケージをダウンロードすることです。Subversionの ウェブサイト(http://subversion.tigris.org) には、ボランティアによって作られたダウンロード可能なパッケージが たくさんあります。このサイトには普通、Microsoft Windows のための グラフィックインストーラパッケージもあります。Unix系のオペレーティング システムを使っているなら、(RPMs, DEBs, ports tree などといった、)システム 固有のパッケージ配布システムを使うこともできます。

あるいは直接ソースコードからSubversionを作ることもできます。Subversion ウェブサイトから最新のソースコードリリースを取得してください。解凍した あとINSTALL ファイル中の説明に従って作ってください。ソースパッケージには リモートリポジトリにアクセスするためのコマンドラインクライアントを 作るのに必要なものはすべてそろっていますが、(特に apr, apr-util, そして neon ライブラリなど)、Subversionのオプション部分は Berkeley DB や、 潜在的にはApache httpd など、ほかのいろいろなソフトに依存していることに 注意してください。もし完全に ビルドしようとするなら、INSTALLファイルに書かれた すべてのパッケージが手元にあることを確認してください。既にある Subversion リポジトリの上で作業するなら、クライアントプログラムを使っ て、最新の一番新しいソースコードを取得することができます。 このやり方はソースコードの取得の項 の章に書いてあります。

Subversion はさまざま部品からできています。以下はその簡単な概要です。 ここでの簡単な説明で混乱してもあわてないでください; —混乱を 減らすために非常に多くのページがこの後に用意して ありますので。

Subversionが正しくインストールされていれば、これで利用できるようになって いるはずです。次の二つの章では、コマンドラインクライアントプログラム、 svnの使い方を説明します。

人によってはこの本での「トップダウン」的なアプローチによって 新しい技術を習得するのが困難かも知れません。この節では Subversion の 非常に短い導入方法を用意し、「ボトムアップ」的な読者にも挑戦の機会を与える ことにします。あなたが経験によって学ぶやり方を好むようなタイプの人であ れば、以下のやり方がうまくいくでしょう。途中、この本の関連した章へのリ ンクをつけてあります。

バージョン管理モデルや CVS と Subversion の両者で利用される 「コピー・修正・マージ」モデルについて全く聞いたことがない のであればまず第2章 基本概念を読んでから先に進んだほうが よいでしょう。

Subversion はすべてのバージョン化されたデータを中心的な リポジトリに格納します。最初に新しいリポジトリを作りましょう:

$ svnadmin create /path/to/repos
$ ls /path/to/repos
conf/  dav/  db/  format  hooks/  locks/  README.txt

このコマンドはSubversion リポジトリを含む新しいディレクトリ /path/to/reposを作ります。 この新しいディレクトリには(他のファイルに混じって)データベースファイルの 集まりを含んでいます。内部を詳細に知る必要がないのであれば このバージョン化されたファイルを見る必要はないでしょう。 リポジトリ生成と保守についてのより詳しい情報は 第5章 リポジトリの管理を見てください。

Subversion には「プロジェクト」という概念はありません。 リポジトリは単なる仮想的にバージョン化されたファイルシステム であり、どんなデータも含むことのできる大きなツリー構造です。 管理者によってはひとつのリポジトリにひとつのプロジェクトだけを 入れることを好みますが、他の管理者はディレクトリを分割した形で 複数のプロジェクトを格納することを好みます。両者のメリット、 デメリットについてはリポジトリレイアウトの選択の項 で議論します。どちらの方法でもリポジトリは単にファイルとディレクトリ を管理するだけなので、特定のディレクトリを「プロジェクト」 であると解釈するかどうかは人間にまかされています。それでこの本をつうじて プロジェクトを参照するときには、リポジトリに存在する、いま言ったような形 のいくつかのディレクトリ(あるいはディレクトリの集まり)についてだけ話を することに注意してください。

この例では、新しく作った Subversion リポジトリにインポートを済ませた 何かのプロジェクト(ファイルとディレクトリの集まり)があるものと 仮定しています。このデータ内容は myproject という単一のディレクトリに編成されているものとしましょう( もちろん実際には好きな名前にすることができます)。 後で説明する理由により(第4章 ブランチとマージ 参照)、ツリーの構造はbranches, tags, そして trunkという 名前の三つの最上位ディレクトリを含む必要があります。 trunkディレクトリはすべてのデータを含んでいる はずですが、branchesとtags ディレクトリは空です:

/tmp/myproject/branches/
/tmp/myproject/tags/
/tmp/myproject/trunk/
                     foo.c
                     bar.c
                     Makefile
                     …

branches, tags, trunkサブディレクトリは実際には Subversion に 必要なものではありません。後で利用する時におそらくもっとも便利になる ように考えられた、よく利用される命名規約にすぎません。

ツリー中にデータを作ったらsvn import コマンドでリポジトリにインポートします(svn importの項を見てください):

$ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import"
Adding         /tmp/myproject/branches
Adding         /tmp/myproject/tags
Adding         /tmp/myproject/trunk
Adding         /tmp/myproject/trunk/foo.c
Adding         /tmp/myproject/trunk/bar.c
Adding         /tmp/myproject/trunk/Makefile
…
Committed revision 1.
$ 

これでリポジトリにツリーのデータが入りました。この時点で trunkディレクトリの「作業コピー」 を作ります。ここが実際の作業を行う場所になります:

これでリポジトリにツリーのデータが入りました。 すでに注意したように、リポジトリ中のファイルやディレクトリを詳しく 調べる必要はありません; すべてはデータベース中に格納されているもの だからです。しかしリポジトリの仮想的なファイルシステムを考えると、 いまの場合、最上位にディレクトリmyprojectが あり、その下にあなたのデータが含まれている形になります。

もとの /tmp/myprojectにはなにも変更がないことに注意してく ださい。(実際、必要ならこのディレクトリを消してしまうこともできま す)。リポジトリのデータを操作するためには、このデータのために、一種の 個人用の作業領域となる新しい「作業コピー」を作らなくてはな りません。Subversion に、リポジトリのmyproject/trunkディレ クトリ用の作業コピーを「チェックアウト」するように指示して みましょう:

$ svn checkout file:///path/to/repos/myproject/trunk myproject
A  myproject/foo.c
A  myproject/bar.c
A  myproject/Makefile
…
Checked out revision 1.

これでmyprojectという名前の新しい ディレクトリ中にリポジトリのプライベートなコピーを手にしたことに なります。作業コピー中のファイルを編集し、その変更点をリポジトリに 書き戻すためにコミットすることができます。

作業コピーに対してできるすべてのことについての完全な手引き については第3章 同伴ツアーを読んでください。

この時点で、ネットワーク越しに別の人々にリポジトリを 利用可能にすることもできます。 第6章 サーバの設定を読んで利用可能ないくつかのサーバプロセス の違いについて把握し、どのように設定すれば良いかを理解してください。

Subversion は共有情報の一元管理システムです。最も重要なのは リポジトリと呼ばれる、データの格納庫 です。リポジトリは情報をファイルシステムツリー —一般的なファイルとディレクトリの階層構造—の形で格納します。 任意の数のクライアントがリポジトリにアクセスし このようなファイルの読み書きをします。データを書き込むことでクライアントは 他の人たちがその情報を使えるようにします。データを読み出すことでクライアントは 他の人たちの情報を受け取ります。図 2.1. 「典型的なクライアント/サーバシステム」はこれ を表したものです。

図 2.1. 典型的なクライアント/サーバシステム

どうしてこんなことが興味深いのか? ここまでのところでは、典型的なファイルサーバの 定義にすぎないように思います。そして実際、リポジトリはファイルサーバの 一種です。が、普通言うようなものとは少し 違います。Subversionのリポジトリの特徴はそれまで書き込まれた すべての修正をすべて憶えているところ です。すべてのファイル変更についても、また、ディレクトリツリーの自身の変更に ついてもそうです。このような変更は、ファイルやディレクトリの追加、削除、 再配置、などによって起こります。

クライアントがリポジトリからデータを読み出すときには、普通はファイルシステム ツリーの最後のバージョンだけが見えます。が、ファイルシステムの 以前の状態も閲覧することができます。 たとえばクライアントは、 「先週の水曜日にこのディレクトリにはどのファイルがあったの?」、とか 「最後にこのファイルを変更したのは誰で、その人は何を変更したの?」 といった履歴に関する質問をすることができます。 この手の質問はすべてのバージョン管理システム のキモになるような質問です。つまりバージョン管理システムとは時間と共に 修正されるデータを記録したり、修正内容を追跡したりするようにデザイン されています。

バージョン管理システムの中核となる役割は共同作業での編集とデー タの共有を可能にすることです。しかしこれにはシステムごとに違った戦略が必要 になります。

ファイル共有の問題

あらゆるバージョン管理システムはどれも基本的な一つの問題を解かなくてはなりません: どうやってユーザに情報を共有させつつ、お互いの変更点が重ならないようにするか、です。 リポジトリ上の別の人の変更を間違って上書きしてしまうことは簡単に 起こりえます。

図 2.2. 「避けなくてはならない問題」に示したこんな状況を考えてみてください: 二人の同僚、Harry と Sally がいます。 二人は同時に同じリポジトリ内のファイルを編集することにしました。 もし Harry が先に彼の変更をリポジトリに書き込めば、多分、(その少し あとで) Sally は間違って彼女の新しいバージョンでそれを上書きしてしまう でしょう。Harry のバージョンは永久に失われることはありません(と、いうのは バージョン管理システムはすべての変更を記録しているため)が、 Harry がやった修正は、どれも Sally の新しいバージョンには 現れることがありません。編集時には 彼女は Harry の変更を見ることはできないからです。Harry の作業は、 実質的には失われてしまい、—あるいは少なくとも最新のバージョンからは 失われてしまい、— しかもおそらくそれは二人が意図したことではないで しょう。これこそわれわれが避けなくてはならない状況です。

図 2.2. 避けなくてはならない問題

ロック・修正・ロック解除の解法

多くのバージョン管理システムでは、 ロック・修正・ロック解除のモデルを使ってこの問題 を扱います。そのようなシステムでは リポジトリ中のファイルを変更できるのは一度に一人だけです。 最初 Harry はファイルに変更を加える前に、「ロック」しなくては なりません。ファイルのロックは、図書館から本を借りるのにいろんな意味で よく似ています。もし Harry がファイルをロックすると、Sally は同じ ファイルに変更することができなくなります。ロックしようとすれば、 リポジトリはその要求を拒否します。彼女ができるのはそのファイルを 読むことと、Harryが仕事を終えてロック解除してくれるのを待つことだけ です。Harry がロックを解除したあと、彼の番は終わり、今度はSallyが ロックして編集することができる番になります。図 2.3. 「ロック・修正・ロック解除の解法」はこの単純な解法の例です。

図 2.3. ロック・修正・ロック解除の解法

ロック・修正・ロック解除のモデルの問題は、ファイル管理が少し厳しすぎる ことで、しばしば、ユーザとって作業の障害になります:

• ロックすることは管理上の問題を起こすかも知れません。 ときどきHarryはファイルをロックしたあとでそのことを忘れてしまいます。 いっぽう Sally はずっと自分の番を待っているので、その間何もすることが できません。そしてHarryはそのままバカンスに行ってしまい、Sallyとしては 管理者に対してHarryのロックを解除してもらうように頼まなくてはならなく なります。この状況は不要な遅れと、時間の無駄を起こします。

• ロックは不要な直列化を起こすかも知れません。 Harryはそのテキストファイルの先頭の部分を修正して、Sally は同じファイルの 最後の部分を修正したいだけだとしたら? 二人の修正はまったく重なって いません。適当な形でマージされることさえ保証できれば、二人は同じファイル を同時に編集することができ、それが大きな問題にはならないでしょう。

• ロックは間違った意味の安心感を与えてしまう場合 があります。 HarryがファイルAをロックしてから編集し、一方Sallyは同時にファイルBを ロックしてから編集しているとします。しかしここでAとBとは意味的に 依存しあっていて、それぞれに対する独立した変更は両立しないとしましょう。 突然 A と B はもう一緒に動作しなくなります。ロックを使ったシステムは このような状況には無力です。— これはある意味で、間違った意味の 安心感を与えてしまっています。HarryやSallyが、ファイルをロックする ことでそれぞれ安全な状態に入り、自分の作業は他人から分離されていると 錯覚することは簡単に起こりえます。このことが、最初に述べたような 実は両立しない変更についての議論を妨げてしまうかも知れません。

コピー・修正・マージの解法

Subversion, CVS, その他のバージョン管理システムはロックに変わる アイディアとしてコピー・修正・マージモデルを 使います。このモデルではユーザごとのクライアントプログラムはプロジェクト リポジトリにアクセスして自分だけの作業コピーを 作ります—それはリポジトリにあるファイルやディレクトリをローカルに コピーしてきたものです。それからユーザは ひとりひとりが平行して作業をし、自分の作業コピーを修正します。 最後に自分のコピーは最終的な新しいバージョンにマージされます。 このバージョン管理システムは大部分のマージを手伝いますが 最終的には正しいマージかどうかについては人が責任を持ちます。 ユーザは平行して作業し、変更を同じファイル、ただしそれぞれの作業コピー である"A"に対して行います。

例をあげます。 Harry とSally が同じプロジェクトに対するそれぞれの作業コピーをリポジトリ の内容をコピーして作ったとします。 彼らは平行して作業し、変更をまずは自分の作業コピーの同じファイルAに対して 行います。Sally は自分の変更を先にリポジトリに保存します。 Harry が変更をあとで保存したいと思ったとき、リポジトリは、彼に対して Aは既に最新ではないことを伝えます。 言い換えると、リポジトリにあるファイルAは彼がそれをコピーした後で 別の人によって修正されていることを伝えます。そこで Harry は、Subversion のクライアントプログラムに、自分の作業コピーAに対して、リポジトリにある 新しい変更点をマージするように要求します。 Sally の変更が彼のもので上書きされることはありえません。ひとたび彼が 両方の変更を統合してしまえば、自分の作業コピーをリポジトリに書き戻す ことができます。図 2.4. 「コピー・修正・マージの解法」と 図 2.5. 「コピー・修正・マージの解法(続き)」 はこの処理を示しています。

図 2.4. コピー・修正・マージの解法

図 2.5. コピー・修正・マージの解法(続き)

しかし、Sallyの変更点がHarryのと重なって いたら? そのときはどうなるのでしょう? この状況は衝突と 呼ばれ、普通はあまり大きな問題にはなりません。 Harry がSubversionクライアントプログラムにリポジトリの最新の変更を 自分の作業コピーにマージするように要求したとき、彼のAファイルの作業 コピーは、衝突の状態としてマークされます。彼は両方の変更の衝突した 部分を見ることができ、どちらを選ぶかを選択します。ソフトウェア自体が 自動的に衝突を解決することはできないのに注意してください; 人間だけが 理解し、正しく選択する力を持っています。Harry がいったん重なっている 部分の修正を手で解消したら—たぶんSallyと衝突について話し合った あと—マージされたファイルをリポジトリに安全に書き戻すことが できます。

コピー・修正・マージのモデルは少々混沌としているように 思うかも知れませんが、実際にはとてもスムーズに行きます。 ユーザは平行して作業することができ、相手の修正を待つことはありません。 同じファイルに対して変更するときでも、ほとんどの変更は、まったく重ならない ことがわかります。そして、衝突を解消するのにかかる時間は、ロックする システムで失われる時間よりもずっと短いのです。

最終的に、これは一つの重要な要因に行き着きます: ユーザ間の コミュニケーションです。ユーザがお互いにあまり意見のやり取りをしなければ、 両方の構文上の、また意味の上の衝突は増えます。どんなシステムも ユーザに完全な意思の疎通を強制することはできないので、意味上の衝突を 検出することはできません。そういうわけで、ロックするシステムが衝突を 回避することができるという間違った保証に安心する理由はありません。 実際には、ロックは生産性を落とす以外のなにものでもないように見えます。

ロックが必要な場合

ロック・修正・ロック解除のモデルは一般的には複数で協力して作業する場合には 有害だと考えられていますが、場合によってはロックが有効なこともあります。

コピー・修正・マージモデルはファイルが文脈を考慮した上でマージ可能である という前提に基づいています: つまり、リポジトリ中の大部分のファイルが 行単位のテキストファイルである場合を想定しています(プログラムのソース コードなどがその典型です)。しかしバイナリ形式のファイル、たとえば画像や 音声などの場合、衝突した部分の変更点をマージすることは不可能なのが 普通です。そのような場合に必要なのは、ユーザはファイルを変更する上で、 厳密に自分の順番を確保したいということです。順序性を保った形でのアクセス がなければ、最終的には捨ててしまうことになるある人の修正によって時間が 無駄になってしまいます。

CVS と Subversion は原則としてはコピー・修正・マージのシステムですが 両者とも場合によってはファイルにロックする必要があることを認め その仕組みを用意しています。 ロックの項 を見てください。

そろそろ抽象論から具体的な議論に移るときがきました。この章で はSubversion が利用される実際の例をお見せします。

作業コピー

既に作業コピーについて読んできたことと思いますので、Subversionのクライアント プログラムが作業コピーを作ったり使ったりする様子を見てみます。

Subversion 作業コピーは、自分のローカルシステム上の普通の ディレクトリツリーで、その中には複数のファイルがあります。あなたは 望むファイルを編集することができ、ソースコードファイルなら、それを 普通にコンパイルすることができます。作業コピーは自分だけの作業領域 です: Subversion はほかの人の変更を持ち込んだりしませんし、明示的に そうしてくれと言うまで、自分の変更を他の人に見せたりすることも ありません。同じプロジェクト用に一人で複数の作業コピーを持つことさえできます。

作業コピーのファイルに変更を加え、それがうまく動作することを 確認したあとで、Subversion はその変更を同じプロジェクトであなたと一緒に 作業しているほかの人に「公開」するためのコマンドを(リポジトリに 書き込むことで)用意します。もし他の人が自分自身の変更を公開したとき にはSubversionはその変更を自分の作業コピーにマージするコマンドを用意します。 (リポジトリの内容を読み出すことで。)

作業コピーには、Subversionによって管理される、いくつかの特殊な ファイルもあり、その助けによって(読み出し、書き込みなどの)コマンドを 実行します。特に作業コピー中のディレクトリには.svn という名前の、管理ディレクトリとして知られる サブディレクトリがあります。管理ディレクトリのそれぞれのファイルは Subversionがどのファイルにまだ公開していない変更があるか、どのファイルが 他の人の作業によって最新でなくなっているか理解するのを助けるものです。

典型的な Subversion リポジトリは複数のプロジェクトのファイル (またはソースコード)をつかんでいます。普通、それぞれのプロジェクトは リポジトリのファイルシステムツリー中のサブディレクトリになっています。 この構成によって、ユーザの作業コピーは普通、リポジトリの特定の 部分木に対応しています。

たとえば二つのソフトウェアプロジェクト、paintと calcを含むリポジトリが あるとします。それぞれのプロジェクトはそれぞれの最上位サブディレクトリ にあります。図 2.6. 「リポジトリのファイルシステム」のような状況です。

図 2.6. リポジトリのファイルシステム

作業コピーを持ってくるため、リポジトリ中のどれかのサブツリーを チェックアウトしなくてはなりません。 (「check out」 という言葉は何かをロックしたり保護したり するような響きがありますがそうではありません; それは単に自分のための プロジェクトのコピーを作るだけです。) たとえば/calcをチェックアウトするとこんな 感じで作業コピーを手に入れることができます:

$ svn checkout http://svn.example.com/repos/calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c
Checked out revision 56.

$ ls -A calc
Makefile  integer.c  button.c  .svn/

Aの文字で始まる一覧はSubversionがあなたの作業コピーにいくつかの ファイルを追加したことを示しています。これでリポジトリにある /calcディレクトリの作業コピーを 持ってくることができました。最初に言ったように、この取得時に は、もう一つ、.svnが 作成されますが、これがSubversionに必要な追加情報を格納する ための場所になります。

リポジトリのURL

Subversion のリポジトリにはいろいろな方法でアクセスすることができます —それはローカルディスクにあるかも知れませんし、さまざまなネット ワークプロトコルを通じてかも知れません。しかしどのような場合でも、リポ ジトリの場所は、常にURLによって表現されます。 表 2.1. 「リポジトリにアクセスするためのURL」 はどのようにして異なる URL が適切なアクセ ス方法に結び付けられるかを示しています。

表 2.1. リポジトリにアクセスするためのURL

Schema	アクセス方法
file:///	リポジトリへの直接アクセス (ローカルディスク上)
http://	Subversionを考慮したApacheサーバへのWebDAVプロトコル経由でのアクセス
https://	http://と同じだが、SSLによる暗号化
svn://	svnserve サーバに対する独自TCP/IPプロトコル経由での アクセス
svn+ssh://	svn://と同じですが、SSH トンネルを利用します。

Subversion が URL をどのように構文解析するかについてのより詳しい情報は Subversion リポジトリの URLの項を見てください。

button.cに変更を加えることを考えてみます。 .svnディレクトリがファイルの修正時刻と もともとの内容を記憶しているので、Subversionはあなたがファイルを 変更したかどうかを見分けることができます。しかしSubversionは明示的に そうしてくれと言われるまでその変更を公にはしません。 自分の変更を公開する操作のことを変更点のコミット (あるいは チェックイン)と言います。

変更点を他の人に公開するにはSubversionのcommit コマンドを使います:

$ svn commit button.c
Sending        button.c
Transmitting file data .
Committed revision 57.

これでbutton.cへの変更はリポジトリに コミットされました。もし別のユーザが/calc の作業コピーを作るのにチェックアウトすれば、最新バージョン中に あなたの変更点を見ることになるでしょう。

一緒に作業している Sally が、あなたがチェックアウトしたのと同じ時刻に /calc の作業コピーを自分用にチェックアウト したとしましょう。あなたがbutton.cへの自分の 変更をコミットしても、Sallyの作業コピーは変更されない状態のままです。 Subversionはユーザの要求によって初めて作業コピーの内容を変更します。

作業内容をプロジェクトの最新の状態にするには、SallyはSubversionに 自分の作業コピーを更新 するように依頼しなくては なりません。これにはupdate コマンドを使います。 これはあなたの変更を彼女の作業コピーにマージしますし、彼女がチェック アウトしたあとで他の人がコミットしたすべての部分についてもマージします。

$ pwd
/home/sally/calc

$ ls -A 
.svn/ Makefile integer.c button.c

$ svn update
U    button.c
Updated to revision 57.

svn updateコマンドからの出力は Subversionがbutton.cの内容を 更新したことを示しています。Sally はどのファイルを更新 するかを指定する必要がないのに注意してください。Subversion は .svnディレクトリの情報と リポジトリの情報を使って、どのファイルを更新しなくてはならないか を決定します。

リビジョン

svn commit操作は一つのトランザクション として任意の数のファイル、ディレクトリに対する変更点を公開する ことができます。作業コピー中で、ファイルの内容を変えたり、新しい ファイルを作ったり、削除したり、名前を変えたり、ファイルや ディレクトリをコピーしたあと、それらの変更点の全体を完全なひと かたまりのものとしてコミットすることができます。

リポジトリでは、それぞれのコミットは、一つの分割できないひと かたまりのトランザクションとして扱います。すべてのコミットに よる変更は、完全に実行されるか、まったく実行されないかの どちらかです。Subversionは、この不分割の性質を、プログラム 障害、システム障害、ネットワーク障害、その他の操作があった 場合でも保とうとします。

リポジトリがコミットを受け付けるときは常に リビジョンと呼ばれるファイルシステム ツリーの新しい状態を作ります。それぞれのリビジョンには 一意な自然数が割り当てられます。前のバージョンよりも 後のバージョンのほうが数が大きくなります。 リポジトリ新規作成時の最初のバージョンはゼロで、ルートディレクトリ 以外には何も含まれていません。

図 2.7. 「リポジトリ」はリポジトリを視覚化するうまい方法 を示しています。0から始まるリビジョン番号が、左から右に追加されていく 状況を想像してください。それぞれのリビジョン番号には対応した ファイルシステム木があり、それぞれの木はコミット 後のリポジトリの状態を示す「スナップショット」 です。

図 2.7. リポジトリ

グローバルリビジョン番号

他の多くのバージョン管理システムとは違って、Subversionのリビジョン番号は 木全体に対して付けられるもので、 個々のファイルに付けられるものではありません。それぞれのリビジョン番号は 木全体を指定し、あるコミットによる変更後のリポジトリの特定の状態を示す ものです。これを想像するための別の方法はリビジョンNは、N番目のコミット 後のリポジトリファイルシステムの状態をあらわしていると考えることです。 Subversionユーザが、「foo.cのリビジョン」 と言うときそれが実際に意味するものは、「リビジョン5に現れる foo.c」です。 一般的に、あるファイルのリビジョンNとMは、異なっている必要は ありません! CVSはファイルごとのリビジョン番号を使うので、この違いを詳しく知りたい人は 付録 A. CVSユーザのためのSubversionを見てください。

作業コピーは常にリポジトリのどれか一つのリビジョン対応しているとは 限らないことに注意してください。複数の異なるリビジョンのファイル を含んでいるかも知れません。たとえば、最新リビジョン番号が4である リポジトリから作業コピーをチェックアウトしたとします:

calc/Makefile:4
     integer.c:4
     button.c:4

この時点では、作業コピーはリポジトリのリビジョン4と完全に一致しています。 しかし、ここで button.cに変更を加え その変更をコミットしたとします。他にコミットした人がいない場合、 今回のコミットはリポジトリのバージョンを5にあげ、作業コピーの内容は 以下のようになります:

calc/Makefile:4
     integer.c:4
     button.c:5

この時点でSallyがinteger.cに対する修正を コミットし、リビジョンを6にあげたとします。ここでもし、svn update コマンドであなたの作業コピーを更新すると、次のようになるでしょう:

calc/Makefile:6
     integer.c:6
     button.c:6

Sallyのinteger.cへの変更は あなたの作業コピーに現れますが、button.c に対するあなたの変更はそのままです。この例では、 Makefileのテキストは、リビジョン4,5,6で まったく同一のものですが、Subversionはあなたの作業コピー中の Makefileのリビジョンを6として、 それが最新であることを表現します。それで自分の作業コピーに きれいなアップデートをかけたときには、一般に作業コピーは リポジトリのある特定のバージョンと完全に一致します。

この章では、さまざまなSubversionの基本的な概念を扱いました:

ここでは、最も一般的な意味で、Subversionがどのように動作するかについての 良い考え方が身に着いたはずです。この知識をもとに、次の章に進むことが できます。ここは、Subversionのコマンドと機能についての詳しいツアーに なっています。

読み進める前に、Subversionを使うときに必要な一番重要なコマンドを載せて おきます: svn help Subversionコマンドラインクライアントは、自分自身の中にドキュメントを 持っています。—いつでも svn help <サブコマンド>とやれば 構文、オプションスイッチ、その サブコマンドの振る舞いを見ることができます。

svn importで、Subversionのリポジトリに新しいプロジェクトを インポートできます。Subversionサーバを設定するときには、一番最初に 実行するコマンドかも知れま�