ファイルやディレクトリをコピーしたり移動したり名称を変更したりすること、 また、ファイルを作って、一度消したあとにもう一度同じ名前でファイルを作 ること— このようなことはコンピュータを使う上で常に、また当たり前 のようにやっている操作です。Subversion もまた、あなたにその手の操作を 当たり前にやってほしいと思っています。Subversion のファイル管理は非常 に自由であり、バージョン化されていないファイルを操作するときに期待され る動作とほとんど同じような柔軟性を、バージョン管理されているファイルに 対してサポートしています。しかしこのような柔軟性はリポジトリの一生を通 じて、バージョン管理されている資源はいろいろなパス名をとること、逆にあ る特定のパス名がまったく別のバージョン管理された資源を表す可能性がある ことも意味しています。
Subversion はあるオブジェクトのバージョンの履歴がそのような「所在 地の変更」を含むような場合でも、そのことを非常に正確に気づきます。 例えば先週ファイル名を変えた、あるファイルのすべての履歴を表示させよう としても、Subversion はそのログ全体をうまく表示してみせます— つ まり名称変更が実際に起きたリビジョンと、それに関連した名称変更の前と後 にあるすべてのリビジョンについてという意味です。そんなわけでほとんどの 場合、あなたは、何かを特に意識する必要もありません。しかし場合によって は Subversion は、あいまいさを解消するためにあなたの助けを必要とするこ ともあります。
一番簡単な例はバージョン管理下にあるディレクトリやファイルがいったん削除され、
その後おなじ名前のディレクトリやファイルがあらためて作成されてから
バージョン管理項目として追加されたような場合です。とうぜん削除したファイルと
あとから追加したファイルはまったく別のものです。両者は単にたまたま同じパス名を
持っているというだけのことです。このファイル名を /trunk/object
としておきましょう。さてこの場合、/trunk/object
の履歴に関する問い合わせを Subversion にする場合、どんな意味になるので
しょうか? 現にそのパスに存在しているほうのファイルについての問い合わせ
でしょうか、あるいはその場所から以前いったん削除したほうのファイルに
ついての問い合わせでしょうか? あるいは全履歴中で、とにかくそのパスに
あったオブジェクトに対して実行したすべての操作についての意味でしょうか?
確かに Subversion にはあなたが本当に知りたいと思っていることについての
ヒントを与えてやることが必要です。
さらにありがたいことに、ファイル移動の操作によってバージョン管理上の履
歴はさらにずっとややこしいことになります。たとえば、
concept という名前のディレクトリがあって、その中
にはまだ始まったばかりの、ままごとプロジェクトがあったとします。しかし
最終的に、その考えはしっかりしたものになり、プロジェクトは真面目な利用
ができるような状態となったので、そのプロジェクトに聞いたこともないよう
な名前をつけることにしました。[36] そのソフトの名前
を Frabnaggilywort としましょう。ここから先はプロジェクトの新しい名前
にふさわしいようにディレクトリをconcept から
frabnaggilywort に変えるのはもっともな話しです。
開発が進み frabnaggilywort はバージョン 1.0 をリリースすることになり、
それは多くの人々によってダウンロードされ、日々利用され、みんな幸せにな
りました。
いい話しです。まったく。しかしこれで話しが終わるわけではありません。あ
なたは企業家です。すでに次の着想を得ています。あなたは新しいディレクト
リconcept を作り、次の開発サイクルが始まります。
実際にはこのサイクルは何年にもわたって何度も繰り返し発生します。いつも
conceptディレクトリから始め、時にはそのアイディア
を膨らませるためにディレクトリの名称は変更され、時にはそのアイディアを
ボツにするためにディレクトリは削除されます。あるいは、さらにややこしい
場合、いったん concept を別の名前に変えた後、何か
理由があって再びconcept に名前を戻したりすること
もあるでしょう。
この手の話しになったとき、Subversion に対してファイルパス名を再訪問す るように指示するのはシカゴの West Suburbs にいる運転手に east down Roosevelt Road まで行き、そこでメインストリートに左折するように指示す るのと少し似ています。20分もしないうちにWheaton, Glen Ellyn, そして Lombard にある「メインストリート」を横切ることになるでしょ う。しかし、これらはすべて別の道です。私たちの運転手には — そし て Subversion に対しても同様に — 正しい場所に行ってもらうために はもう少し詳しい情報が必要になります。
バージョン 1.1 で、Subversion はどのメインストリートに行きたいかをもっ
と正確に伝える方法を取り入れました。これはペグ・リビジョン
と呼ばれ、Subversion に対して特定の履歴ラインを指定するた
めだけの目的で用意されたものです。ある特定の時点では— あるいはも
う少し正確にはある特定のリビジョンでは— あるパス名はせいぜい一つ
のバージョン管理されたリソースによって利用されるだけなので、パス名とペ
グ・リビジョンの組み合わせはある特定の履歴ラインを指定するのに十分な情
報になります。ペグ・リビジョンは Subversion のコマンドラインクライアン
トからアットマーク構文によって指定されますが、
これはその構文が 「アットマーク」 (@) と
ペグ・リビジョンをパス名の最後につける形になるからです。このパス名はペ
グ・リビジョンに存在しているパス名です。
ではこの本の中でいつも出てくる --revision (-r)で指定
されるほうのリビジョンは何と言われるのでしょうか ? こちらは
操作対象リビジョン(あるいはリビジョンの範囲を指定する場合
には、操作対象リビジョン範囲) と呼ばれます。いっ
たん特定の履歴ラインがパス名とペグ・リビジョンによって指定されると
Subversion は操作対象リビジョンに対して要求された操作を実行します。
この話をシカゴの道順のたとえで説明すると、 606 N. Main Street in Wheaton
に行きたい場合だと
[37]
「Main Street」がパス名に、「Wheaton」がペグリビ
ジョンにあたるものと考えることができます。この二つの情報によって実際に
行ってほしい道順(メインストリートの北、あるいは南)を特定することができ、
行き先を探すのに、間違った別のメインストリートを右往左往せずにすみます。
そして、操作対象リビジョンにあたる 「606 N.」 によって実際
に行きたい場所を正確に知ることができるというわけ
です。
ずっと以前に作っておいたリポジトリがあって、リビジョン 1 で最初の
conceptディレクトリとその中にある
IDEAという名前のファイルを追加したとしましょう。
このファイルは実際のコンセプトについての説明が書いてあります。
実際のソースコードを追加したり修正したりしてたくさんのリビジョンが
追加されたあと、リビジョン 20 でこのディレクトリを
frabnaggilywortに名称変更したとしましょう。
リビジョン 27 で新しい着想を得たので、新規にconcept
ディレクトリを作り、またその中に新規に IDEA
ファイルを置いて、その内容を書いておきます。そして良くできたロマンス
小説よろしくその後 5 年間で 20,000 リビジョンにまで達したと
しましょう。
こうして何年もたってから、リビジョン 1 での IDEA
ファイルがどんな具合であったか知りたくなったとします。しかしこの場合
Subversion は 現在のファイルの過去がリビジョン 1
でどうであったのか、あるいはとにかくそれが何であれ、リビジョン 1 で
concepts/IDEA という名前で存在していたファイルの
内容が知りたいのかを知る必要があります。この二つの質問の答えは明らかに
別のものになりますが、ペグ・リビジョンがサポートされているので
このどちらの質問もすることができます。現在の IDEA
ファイルが過去のリビジョン 1 でどうであったかを知りたい場合には以下の
ようにします:
$ svn cat -r 1 concept/IDEA subversion/libsvn_client/ra.c:775: (apr_err=20014) svn: Unable to find repository location for 'concept/IDEA' in revision 1
この例ではもちろん、現在の IDEAファイルは
リビジョン 1 では存在しなかったので Subversion はエラーを出します。
上のコマンドはペグ・リビジョンを明示的に指定する、より長い形の形式
の略記法です。長い形式は以下のようになります:
$ svn cat -r 1 concept/IDEA@BASE subversion/libsvn_client/ra.c:775: (apr_err=20014) svn: Unable to find repository location for 'concept/IDEA' in revision 1
実際に実行すると、やはり期待したとおりの結果になります。ペグリビジョン
は一般的には作業コピーのパスにつけた場合にはBASEの
値(作業コピーに現在存在するリビジョン) が、また URL につけた場合には
HEAD の値が、それぞれデフォルト値になります。
今度はもう一方の質問をしてみましょう。つまり —リビジョン 1
の時点で、とにかく concepts/IDEAという名前で
存在していたファイルの内容はどんなものでしたか? これを指定する
ために明示的なペグ・リビジョンを使います。
$ svn cat concept/IDEA@1 The idea behind this project is to come up with a piece of software that can frab a naggily wort. Frabbing naggily worts is tricky business, and doing it incorrectly can have serious ramifications, so we need to employ over-the-top input validation and data verification mechanisms.
正しい出力になっているようです。このテキスト中で、 frabbing naggily
worts という単語が出てきているところを見ると、現在 Frabnaggilywort と
いう名前で呼ばれているソフトウェアについて説明したファイルであることは
まず間違いないところでしょう。実際、明示的なペグ・リビジョンと明示的な
操作対象リビジョンの組合せによってこれを確認することができます。
HEAD では Frabnaggilywortプロジェクトが
frabnaggilywortディレクトリにあることはわかってい
ます。それで HEAD で
frabnaggilywort/IDEA というパス名で特定される履歴
ラインが、リビジョン 1 ではどのようであったかを知りたいのだ、というこ
とを指定してみます。
$ svn cat -r 1 frabnaggilywort/IDEA@HEAD The idea behind this project is to come up with a piece of software that can frab a naggily wort. Frabbing naggily worts is tricky business, and doing it incorrectly can have serious ramifications, so we need to employ over-the-top input validation and data verification mechanisms.
そして、ペグ・リビジョンも操作対象リビジョンも、時には非常に重要な意味
を持ちます。例えば、 frabnaggilywortがリビジョン
20 で HEAD から削除されているが、リビジョン 20 では
存在していたことを知っていて、その時の IDEA
ファイルが、リビジョン 4 と リビジョン 10 の間でどのように変化したか
を見たいとします。これには、ペグ・リビジョン 20 を、そのリビジョンで
Frabnaggilywort の IDEAファイルを保持していた
URL の後につけて指定します。また同時に操作対象リビジョン範囲として
4 と 10 を指定します。
$ svn diff -r 4:10 http://svn.red-bean.com/projects/frabnaggilywort/IDEA@20 Index: frabnaggilywort/IDEA =================================================================== --- frabnaggilywort/IDEA (revision 4) +++ frabnaggilywort/IDEA (revision 10) @@ -1,5 +1,5 @@ -The idea behind this project is to come up with a piece of software -that can frab a naggily wort. Frabbing naggily worts is tricky -business, and doing it incorrectly can have serious ramifications, so -we need to employ over-the-top input validation and data verification -mechanisms. +The idea behind this project is to come up with a piece of +client-server software that can remotely frab a naggily wort. +Frabbing naggily worts is tricky business, and doing it incorrectly +can have serious ramifications, so we need to employ over-the-top +input validation and data verification mechanisms.
ありがたいことにほとんどのユーザはこんな複雑な状況に出会うことはありま せん。しかし万一そんなことになった場合には、Subversion がファイル名の あいまいさを解消するにはペグ・リビジョンを追加で指定してやれば良いこと は覚えておいてください。