GNU arch Book

バージョンを管理するのに一番原始的な方法は、もちろんバックアッ プをとることだ。バックアップファイルの名前の後ろに通し番号をつけて 整理したフォルダに入れておけばこれは立派なバージョン管理の役割をは たすことができる。冒頭の画像の話を例にして考えてみよう。いま、 image.tiff という画像ファイルを編集しているとしよう。tiff というの は精細な画像を扱うときによく利用される形式だ。これが雑誌の表紙にな るはずのデータだとしよう。この最初の版を作ったのがたとえば 2004/03/11 の 11:30 だとする。君はまずは手始めに image.tiff を、 image-0.tiff という名前で保存する。それから背景色を変えて、少し縮 小した次の版が 13:45 分にできあがったら、これを image-1.tiff とい う名前でまた保存する。そのあと知らぬ間にボスがやってきて、さんざん ケチをつけたあと、気をとり直して次の版ができたのが 19:12。ではこれ を image-2.tiff にしよう。こんな具合だ。

図 1.1. image.tiff の縄文式バージョン管理

ファイル名を通し番号じゃなく、時刻そのものにするのも一案だ。 たとえば、image-0.tiff のかわりに、2004-03-11-11-30.tiff のような 名前にする。これだとファイル名を見ただけで、いつバックアップをとっ たかまで一目瞭然だ。欠点としてはファイル名がすごく長くなってしまう ことで、これから説明していくにはちょっと都合がわるい。大抵のシステ ムでは、ファイルの時刻を調べる機能がちゃんとついているので、ファイ ル名自体に時刻を埋め込まなくてもそれほどは困らない。

この方法の利点と欠点について、すこし考えてみよう。まず利点。 なんといっても話が単純なことだ。それからこの手法は—これだっ て立派な手法だ—どんなデータにだって使えることだ。今は画像で 説明したけれど、同じことは見積り用の表計算のデータにだって、プレゼ ン用の提案書にだって、FAX で送る予定のお悔やみの文書にだって、校正 中のマサイ語の辞書にだって使える。1 + 1 = 2 が、りんごにも、みかん にも、象にもサイにも使えるのと同じだ。このことを示すために、 image.tiff という具体的なファイル名のかわりに R という一文字でファ イルを表して、その後にバックアップの順番を示す番号を振ろうと思う。 R はリビジョンの略だ。ファイル名を番号だけ表すのはさすがに寒いので 先頭につけてみた。あまり深く考えないでほしい。

図 1.2. 一般的なファイルの縄文式バージョン管理

次は欠点。版を重ねるごとにデータサイズが大きくなることだ。い まみたいな話だとかなり複雑なデータになっているはずだから、数メガバ イトもあるかも知れない。そんなんもんじゃない? オーケー。10メガバイ トだとしよう。修正は、全体のサイズに対してわずかだろうから、版を重 ねた後もだいたい 10メガバイトだとすれば、N 回バックアップすれば N * 10 メガバイトのディスクを食うことになる。10回バックアップすれば 100メガだ。たしかにこれはあまり嬉しい状況じゃない。考えてもみてほ しい。お互いほんの少ししか違っていない良く似たデータが、いくつもい くつも自分のディスクの中で雪だるまみたいに増えていくのだ。でも、と 君は言うかも知れない。それは対した問題じゃない。最近のハードディス クの容量を見ろよ、と。数百ギガバイトの容量を持つようなものがザラじゃ ないか。3年後には、きっとテラバイト級のやつが店に並ぶぜ。100 メガ と言えばこのてのディスクの 1/1000 か、1/10000 の容量しかない。ケチ なこと言いっこなしだ。好きなだけ版を重ねても問題なんかおこりゃしな いぜ、と。

なるほど説得力がある。しかし、だ。このまるごとコピー作戦には もう一つ重大な欠点があるのだ。それは、ある版とその前後の版での修正 点が何であるかがバックアップデータを見ただけでは簡単にはわからない、 という問題だ。これはちょっと画像では説明しにくい。ワープロで作った 非常に大きなドキュメントを例にとろう。業務中にテトリスをやりすぎて クビになった君の新しいアルバイト先での第一日目。自己紹介もすまない うちに渡された巨大なワープロのドキュメントは全部で 500 ページ。行 数にして 15000行もある。何かの標準化資料という話なのだが、内容を見 てもさっぱりわからない。でも心配はない。「我々は、この文書の 内容を理解させようと君を雇ったわけではない」からだ。君の仕事 はこの文書を管理することと、レビューに出席して、丸テーブルの前で黒 いスーツとサングラスに身を固めた七人の男たちが低い声で語る修正案を 文書に反映させることだけだからだ。「ただし、正確にやりたまえ 」。君はさっそくドキュメントのバックアップをとり、最初の版、 R-0 として管理する。これでひと安心だ。次の日に最初のレビューがある。 レビューはあまり盛り上がらない。1320行目から 2 行削除してくれ、と言 われる。それから 14015 行目から 3 行追加してくれ、と。これで全部だ。 君は会議の後、修正後のドキュメントのバックアップをもう一度とる。こ れで二つ目のバージョン、R-1 ができた。次の日も、そのまた次の日もレ ビューは続く。君のリビジョンも R-2, R-3, ... と増えていく。

こんな感じでレビューが 5 回ほど続いた一週間後、ひとりの男が 重苦しい沈黙を破って「我々は、話の最初から何かとんでもない重要な条 項を削除してしまったのではないかね」と言う。一瞬、皆に緊張が走る。 最初のレビューでの変更点は何だったかね、ほら、君がやってきた、あの 日のレビューだよ、とすぐ隣の男が君の耳もとでささやく。とたんに君は 困った状況に追い込まれる。君はこの日のレビュー前のバックアップ (R-0) と、レビュー後のバックアップ(R-1)の、両方のデータを保管して いる。だから、「あの日のレビュー前の状態にすみやかに戻したまえ」と か、「あの日のレビュー後のデータを印刷して、ウクライナの国境近くに いるエージェント・ケファに直ちに送りたまえ」とかいう要求に答えるこ とはできる。しかし「ではそのレビューでの変更点は何だったのか?」と なると話は別だ。二つのファイルとは別に「1320、2行削除、14015、3 行 追加」のようなメモを管理しない以上、15000 行もある二つのファイルの 内容を一行づつ目チェックしながら追いかけていくより他ないわけだが、 もちろんこれは人間のやる仕事ではないし、君の仕事でもない。君は人間 なのだ。^[1]

問題を整理しよう。第一の疑問は、こうだ。「ある良く似た ふたつのデジタルデータがあるとき、その違いを常に計算することができ るか? 」、もう一つは、こうだ、「もしそうなら、その違い を人間がわかる形式で表現できるか? 」 この二つだ。ここでいう 「違い」のことを、コンピュータの世界では「差分 」と言ったり、「デルタ」と言ったりする。後者は耳 慣れない言葉だが、差分は英語で difference と言い、頭文字のd はギリ シャ文字でデルタという文字になるところから来ている。この本ではいつ でも差分と言うことにする。ここはアメリカでもギリシャでもウクライナ でもない。日本なのだ。

第一の疑問にはあっさり答えることができる。つまり、イエス、 だ。どんな場合にでも、どんな形式のデジタルデータでも、差分を計算 することができる。ドキュメントデータもデジタルデータの一種だから、 もちろん差分を計算することができる。問題は第二の疑問だ。これは非常 に難しい。R-0とR-1の差分をせっかく求めても、人間がわかる形で表現でき るとは限らないのだ。いまの例で言えば、最初の日の修正前のドキュメン トと修正後のドキュメントを指定して、その両者の差分を出力するプログ ラムを書くことはできるが、その差分が、「1320、2行削除、14015、3行 追加」とか、そこまで親切な形ではなくても、とにかく人間が解読できる ようなデータにできるとは限らないのだ。その差分データにせいぜいでき ることといえば、変更前のドキュメントと、一緒に渡して、変更後のデー タを復元するようなプログラムの存在を必ず保証できることだけなのだ。

ずいぶんと悲観的な話をしてしまったようだが、単に私は「デジタ ルデータ一般についてはノー」と言っただけだ。すべての女性にピアスが 似合わなくても、ピアスの似合う女性はたくさんいるし、すべての政治家 が公正廉直でなくても、公正廉直な政治化だって、いるにはいる。たぶん。 そんな女性や政治家を探してみよう。いま問題になっているのは、「ドキュ メントファイル」だ。しかしドキュメントファイルにもいろいろある。ワー プロのドキュメントはたいてい、行によってフォントの大きさが違ってい たり、イタリックになっていたり、段幅が微妙に違っていたり、文字その もの以外のデザインに関係したデータがたくさん入っている。これとは逆 に、単なる文字情報だけが入っていて、それ以外の情報が一切入っていな いようなものもある。豊富な情報が入っているデータにもいろいろある。 たとえばあるソフトウェア会社の作ったデータは、その会社独自のデータ かも知れない。他の会社のワープロのデータと互換性があれば、自分のと ころのソフトウェアが売れなくなる可能性があるから、わざとそうしてい るのかも知れないし、互換性の問題に気づくことができない単に無能なソ フトウェア集団なのかも知れない。いま言った、文字だけの情報が入った ファイルのことを、テキストファイル、と言う。そしてそれ以外のファイ ルをバイナリファイルと言う。さて第二の疑問の答えは、こうだ、「もし 君のドキュメントがテキストファイルであれば、差分を計算できて、その 結果を人間が把握する形式で表示することもできる。もしそうでなければ、 つまり君のドキュメントがバイナリファイルであれば、うまくいくかどう かは、そのバイナリファイルの性質による」。

君のドキュメントが運よくテキストファイルであったとしよう。す ると、二つのドキュメントの差分を以下のように表示するためのプログラ ムがある。具体的にどうやるんだよという話は、ちょっと端折らせてほし い。狭くて深いクレバスの谷底までいちいち降りていたんじゃいつになっ ても頂上には着けない。あとで詳しく説明するが、GNUdiff、グニューディ フと呼ばれるプログラムを使うと、とにかく以下の出力を手にできる。ディ フは、さっきも出てきた difference つまり差分の意味だ:

--- R-0       2004-04-12 09:52:47.000000000 +0900
+++ R-1       2004-04-12 09:52:56.000000000 +0900
@@ -1317,6 +1317,8 @@
     てまで解釈されるものではない。
 XI. 特別工作員間の通信はすべて非対称暗号方式を利用するものとし、
     具体的な形式は以下のいずれかとする。
-イ.楕円暗号
-   楕円暗号は他方法によることができない場合にのみ使用することを許可する。
 ロ.量子暗号のうち、二粒子相関系を用いたもの。
 ハ.オメガ・チャンネル(推奨)
    オメガ・ディテクターを携帯している特別工作員は常にオメガ・チャ
@@ -14012,9 +14014,6 @@
   し、又はこの条約で捕虜に与える権利を制限する恐れがある場合に限り
   行うことを認められる。但し、当該紛争当事国が外交上及び領事業務上の
   慣習及び条約に従って通常行う任務を行うことを妨げない。
+第17条の2
+  第1条から第16条までの規定にかかわらず、関係諸機関にはジュネーブ第一条
+  約、第二条約、第三条約、第四条約の各条項が厳格に適用されるものとする。

 第18条
   第3条、第12条、第14条及び第15条に掲げる特別工作員は、次の標示に関し

いったい何の話かわからないだろう。実を言うと私にもさっぱりだ がここで注意したいのは、データの内容ではなく、このファイルの構造だ。 大雑把に言って、先頭の二行を除けば、@@ -1317,6 +1317,8 @@ のような行で始まる大きく二つの部分に区 切られていることがわかると思う。これをハンクと言い、@@ の行をハン クヘッダー、と言う。ハンクとは英語で「ちょっとした大きさのかたまり」 程度の意味らしい。最初のハンクヘッダーは次のように読む「修正前のファ イルの 1317 行目から始まる 6行は、修正後の 1317 から始まる 8 行に 対応しています。対応の仕方は以下です」。次のものは、「修正前のファ イルの 14012 行目から始まる 9 行は、修正後の 14014 行目から始まる 6 行に対応しています。対応の仕方は以下です」。最初のハンクには '-' 文字で始まっている行が 2 行ある。これは行が削除されたことを示して いる。一方二番目のハンクには '+'文字で始まっている行が 3 行ある。 これは行が追加されたことを示している。先頭に記号のない行は変更があっ たまわりの様子を示すための手がかりとして置かれた行で、修正の前後で 変化がなかった行を示している。それぞれの変更がどんな内容だったのか は一目瞭然だろう。君は救われたのだ。

少し話をはぐらかしてしまったような気がして恐縮している。デジ タルデータ一般についての差分の話をしておきながら、テキストファイル とバイナリファイルに分類して、いつのまにかテキストファイルに限定し た差分の話をしてしまった。実はバイナリファイルにはテキストファイル の差分のようなうまい一般論はない。バイナリファイルに属するもっと個 別の具体的なファイル形式について議論するより他なくて、それはこの本 の内容を超えているのだ。ではこんな限定した議論に意味がないかという とそうでもない。テキスト形式のデータもたくさんあるからだ。まずまっ さきにあげなくてはならないのが、プログラムのソースコードだ。これは 何十年もの間、ずっとテキストファイルだった。そうでないコンピュータ 言語や開発処理系もあるのかも知れないがとても主流だとはいえない。そ れからドキュメント文書の一部、たとえば TeX と呼ばれるドキュメント 形式は、やはりテキストファイルだ。それから電子メールなんかもテキス トファイルだし、HTML のホームページもそうだ。他にもいろいろある。 一部の表計算のソフトなんかでも、ファイルの保存形式を選択することで テキスト形式で保存できるものもある。自分のお気に入りのプログラムが あれば、マニュアルなんかで調べてみると思わぬ発見があるかも知れない。

君の回りで、便利なソフトを使わず、わざわざテキストファイルを 使っている人がいたら要注意だ。彼は本当の便利さを理解しているのかも 知れないのだ。

ここまでのところをまとめさせてほしい。まず、デジタルデータに は時間の経過と共に変化するタイプのものがあって、それを管理したい場 合にはバックアップを随時とって名前をつければ良いのだが、それだとバー ジョン間の差分をすぐに知ることができない。でも一部のデジタルデータ は良い性質を持っていて、いつでも二つのバージョン間の差分を人間が理 解できる形に計算することができる。こういうファイルのことをテキスト ファイルと呼ぶ。そういうことだった。ここから先は、議論の対象になる ファイルはいつでもテキストファイルであるとする。それから、バージョ ンのことをリビジョンといいXXX、それぞれのリビジョンを、R-0, R-1, R-2 ととおし番号で呼ぶことにする。混乱してきたら、R-0 とかは日付と時間 の入ったファイル名のことだと思い出してほしい。たとえば ... という 具合だ。

さて、前の節で示した、二つのリビジョンの間の差分をとるプログ ラムの話だが、別にこれは私が作ったプログラムじゃない。何十年も前に ハッカーたちが協力して知恵を出し合ってつくったもので、GNUdiff とい う名前のプログラムだ。「グニューディフ」と読む。何でこんな奇妙な名 前なのかは話すと長い。単に「ディフ」と言っても通じる。それから、こ のディフとペアになったもう一つの有名なプログラムがある。それは GNUpatchと言う。「グニューパッチ」と読む。こちらも「パッチ」と言え ばその手の人たちには通じる。ディフの方はもう説明した。パッチはこれ とちょうど逆のことをするプログラムだ。つまり、あるリビジョンと、差 分を与えて、変更後のリビジョンを復元するプログラムだ。つまり:

図 1.3. 一列に並んだリビジョン

のようになっているとき、R-0 と R-1 を GNUdiff に渡すと、R-0 とR-1の差分を計算してくれる。これを diff(R-1,R-0)と書くことにする。 R-1 のほうを先に書くのは、差分をとる処理がちょうど引き算に似ている から、R-1 引く R-0 という目で見たいからだ。GNUpatch　は GNUdiffの ちょうど逆のことをする。つまり diff(R-1,R-0)とR-0 を渡すと、R-1 を 復元してくれるのだ。

図 1.4. GNUdiff の処理イメージ

図 1.5. GNUpatch の処理イメージ

diff(R-1,R-0)なんて書いても、ピンとこないかも知れないが、前の 節のドキュメントの差分を思い出してほしい。あの形のものを指している だけだ。いちいちあの表示を書いていたら紙が持たない(本当は紙じゃな いけど)し話がまわりくどくなってしまうので、ご勘弁願いたい。R-0 とか R-1も、例の 15000行のドキュメントにちょこちょこ修正が入ったようなものを イメージしてほしい。ああいうものを指している記号だ。話は脱線するが、 シンボルの力は偉大だと思う。「車」と書けば、実際の車を用意しなくて も車について語ることができるし、「宇宙」と書けば、実際に宇宙を用意 しなくてもとりあえずは宇宙について語ることができる。時には話をは しょった見返りに、実物にでくわした時に、手痛いしっぺ返しを受けるこ ともあるわけだがそれはまた別の話だ。

さてここまで道具立てがそろうと、この章の最初のバージョン管理 の手法、つまり単なるバックアップファイルの蓄積より、もう少しスマー トな管理手法をとることができる。バックアップファイルほどディスクを 消費しないし、同時にリビジョン間の差分を即座に見てとれるという一石 二鳥の方法だ。それをこれからお見せしよう。

まず、元のバックアップ手法のリビジョンを一列に並んだところを もう一度思い浮かべてほしい。各リビジョンでの修正量が少なければ、こ れらのデータはよく似ているのだった。これらのリビジョンの隣り合う二 つに対して、GNUdiff を呼び出して、差分を求める:

図 1.6. 隣り合うリビジョン間への GNUdiffの実行

そして、命知らずにも、R-1 から R-3 までのファイルを削除する。 すると以下のようなファイルが残る

図 1.7. 最初のリビジョンと差分の集まりだけを残したところ

d(rN,rN+1)の形のファイルは普通はとても小さい。前の例の行数を 実際に数えてみてほしい。30行にも満たない。これに対して、R-0, ... R-3 のようなファイルは非常に大きい。修正の量にもよるが、どれも大体 15000行 くらいだろう。だから、バックアップ方式だと 15000 × 6 = 90000行のデータを保管しなくてはならない。一方、差分は普通はどれも 小さい。余裕を見て平均 60 行としておこう。それでも R-0 と差分の全体 では、15000 + 5 * 60 = 15300 行にしかならない。ほとんど R-0 そのも ののサイズではないか。差分の内容はすぐにわかるし、データサイズも小 さくて済む。あとは各リビジョンをうまく復元できるかどうかなのだが、 GNUpatchを使えば求めることができる。まず R-0 はすでに手にしている。 R-1 は、R-0 と diff(R-1,R-0)をGNUpatchに渡せば求めることができる。R-2 はいま求めた R-1 とdiff(R-2,R-1)を再び GNUpatchに渡せばいい。こんな風 に繰り返しGNUpatchを呼び出せば、リビジョンの数がどんなに増えてもい つかは欲しいリビジョンが求まる。図で書くとこうだ。

図 1.8. GNUpatchによる各リビジョンの復元

でも、R-0 と diff(R-1,R-0)... などから次の R-4 を作るにはど うしたらいいんだろうか? それにはこうする。まず今いった方法で何回も 繰り返し GNUpatch を呼び出して R-3 を作る。そしてこれを R-4 という 名前にコピーする。このままではまだ R-4 は R-3 と一緒だ。それから、 例の冷や汗もののレビューで君はこの R-4 に修正を加えて保存する。こ れで晴れて R-4 ができた。それからさっきよけておいた R-3 と R-4 の 差分 diff(R-4,R-3) を GNUdiff を使って計算する。これを差分のリスト に追加して R-3 と R-4 を削除する。これでおしまい。

今回の差分作戦の基本は以上だが、この発想の上でいろいろな改良 を加えることはできる。たとえば、差分ファイルでディレクトリやフォル ダが一杯になってしまうのを防ぐために、R-0 と残りの差分全体を一つの ファイルにまとめてしまえるような、新しいファイルの形式を定義してや る。そしてGNUpatchとGNUdiffをうまく改造して、この新しいファイルか らデータを取り出したり、好きなリビジョンを取り出せるようにしてやる。 複数のファイルをアーカイブというソフトを使って一つにまとめた経験は ないだろうか、ちょうどあんな感じだ。

図 1.9. 差分の集まりをひとつのファイルにまとめた様子

これでいくら差分ファイルが増えていっても、その新しいファイル の内容がどんどん増えるだけで、ディレクトリがファイルで一杯になった りすることはなくなる。それから、差分の内容をすぐに思い出せるように、 差分のそれぞれに小さなメモつけることができるようにしておく。バージョ ン管理システムの世界では、このようなメッセージをログメッセージとか、 単にログとか呼ぶ。ちょうど好きなカセットテープのケースに「いとしの あゆ」とか書くのと一緒だ。こうしておけば、この一つのファイルの中に、 このファイルが最初のリビジョンから現在にいたるまで辿ってきた、すべ ての歴史が刻まれていることになる。そしてインディージョーンズが謎の 古代文字を解読するように、君はすべての過去にアクセスし、そこに流れ る人の思いを辿ることができるのだ。このような仕組みを作るための具体 的なプログラムをイメージできないとしても、おおよその雰囲気はわかっ てもらえるのではないかと思う。

さらにいろいろな改良を加えることができる。いままでの例ではたっ た一つのファイルをバージョン管理してきたが、一般には複数個のお互い に関連のあるファイルを一緒に管理することが多いだろう。たとえば 15000行の一つのドキュメントはいかにも大きすぎる。このドキュメント が 3 章からできているのなら、三つのファイルに分けて管理したほうが 楽だろう。ディレクトリ中にはファイルごとの差分がどんどんできていく が、いま述べたようにもとのファイルとそのファイルの差分を一つのファ イルにまとめる手法を使えば、いつまでたってもディレクトリのファイル の数は 3 個のままだ。こうしてバージョン管理の対象は単一のファイル からあるディレクトリ全体という、より豊富なデータ構造に移ることにな る。そして単一ファイルのバージョン管理は、たまたまバージョン管理す るディレクトリに一つのファイルだけが存在するという特殊なケースとみ なすことができる。

細かい、と君は言うかも知れない。あんたの言うことは細かい。要 するに、こう言いたいんだろう。バックアップファイルをたくさんとるか わりに、もっと効率が良くて、変更点もすぐにわかる一石二鳥の方法があ ると。それを使うにはなんとかって言う二つのプログラムを使えばいい、 と。やり方はこれこれ、こうだ、と。あとはこのやり方にしたがって、そ のグニューなんとか をうまく組み合わせたプログラムを作ってくれ、と。 しかし、だ、これじゃ、エンジンのパーツ一式とドライバとスパナを俺に 渡して、はい、さようならって言ってるようなもんだ。いいか、言っとく けど俺はプログラムのことなんてぜんぜん知らない。あんたには簡単かも 知れないけど、俺はそんなもん組み立てたことなんてない。できるやつに 頼めって? なるほど、会社にはすごい詳しいやつが二人いる。特にその一 方はすごいらしい。俺には二人とも同じように、なんだかすごい連中だと しか見えないが、その滅多に口を利かない片方が、もう一方のことを天才 と言うんだ。だからおそらく相当すごいやつなんだろう。しかし、だ。俺 はこいつが気に入らない。ピカイチ気に入らない。人を見下してばかりい る嫌な野郎だ。俺にはわかる。ああいう奴にはプログラムが組めない人間 はみんなバカに見えるんだ。なにさまのつもりだ。はっきりいってこんな 男にモノを頼むくらいなら、舌を噛み切って死んだほうがよっぽどましだ。

なるほど、かなり深刻そうだ。しかし、実際には油まみれになって エンジンを組み立てる必要もないし、少なくともこの件では君も命を落と さずに済む方法がある。ちょっとわざとらしいのだが、実はいま君がまさ に言ったようなものを、すでに組み立ててくれた人がいるのだ。人という のは正確じゃないかも知れない。人々、それも大勢の人々、しかも長い時 間をかけて、しかも大した見返りもなしに、だ。このいきさつと経緯につ いての物語は、それ自体とても面白いのだが、別の機会に譲ろうと思う。 とにかくここから先、もう君は GNUdiff と GNUpatch のことを、近所の ゲーセンにおいてある 2ゲーム100円のリセットボタンみたいにきれいさっ ぱり忘れることができる。テレビの中のごちゃごちゃした部品についての 知識がなくてもリモコンをいじれば、なんだか知らんがテレビは見れるし、 百円玉を自動販売機に突っ込めば、なんだか知らんがコーラが出てくる。 同じことだ。スイッチポンで脱水、乾燥、柔軟仕上げ。かしこい主婦なら 迷わずえらぶ全自動洗濯機みたいなソフトがある。それが CVS、コンカレ ントバージョンシステム、だ。次の節ではこのソフトについて少し話をし ようと思う。ところで君んとこのイヤな野郎の話だが、そいつが嫌なやつ だからって、コンピュータに詳しいやつがみんなそういう連中だなんて思 わないでほしい。君の専門が何か私は知らないが、どんな分野だって、本 物っていうのは決して多くはないものだ。私は言ったはずだ。公正廉潔な 女性もたくさんいるし、ピアスの似合う大物政治家だって、いるにはいる のだ。たぶん。

ものすごい駆け足で説明してきたが、こういうアイディアは昨日の 今日で一人の人間の頭の中だけで思いつくものではない。私の知る限り、 おそらく 20〜30年くらいの歴史の中で少しずつ少しずつさまざまな議論 を通じて育ってきたものだ。そして今から数年前に、一応の完成をみた。 このシステムをコンカレントバージョンシステム、CVS と言う。CVS は今 言ったような形式で、複数のファイルをひとつにまとめたディレクトリ、 あるいはツリーを管理することができる。CVS の細部は、とてもここで語 り尽くせるものではないが、今までの議論で触れていないひとつの大きな 特徴がある。それは、分岐、という概念だ。GNU arch が作られた最も大 きな理由の一つは、CVS の持つ、この分岐概念の不完全さからくるので、 以下の節では分岐、そしてこれをペアになる「マージ」ということについ て詳しく説明しようと思う。分岐とマージは、今までの例のように一人で データを管理しているときには表に現れない。しかし複数の人間が協調し て一つのデータを管理する場合には本質的なものとして現れるのだ。

さて、ここで CVS について最低限の説明をしようと思う。前の節 で言ったように、生の GNUdiff と GNUpatch を使いやすくまとめて誰で も使えるようにしたパッケージを作ろうという動きは非常に早くからあっ たようだ。CVS はこの流れの中で数年前に一応の完成を見た。実はこのド キュメントを書くに当たって、CVS が完成に至る過程を詳しく追いたかっ たのだが、ネット上を検索してもなかなか良い文献には出会えなかった。 唯一参照できそうだったのが CVS に関連したメーリングリストの情報で、 いくつかのリストについては 1993/2 くらいまで遡れるものもあるような のだがアーカイブ全体をテキストファイルに落すことができず、結局詳し く追体験するには至っていない。私はこれらの歴史に非常に興味があるの で、バージョン管理システムの過去について詳しい方や、CVS 関連の非常 に古いメーリングリストのアーカイブなどを保存されておられる方がいた ら是非私に御連絡頂きたいと思う。いずれにせよ、CVS は昨日の今日でで きたようなシロモノでないことだけは確かだ。私の知る限り、20〜30年く らいの歴史の中で、多くの人々の議論の中で徐々に形をとっていたものだ と考えられる。この物語の中には「一人の天才」のようなドラマはないこ とだけは確かだ。人間一人では何にもできない。

ここでは CVS の膨大な機能の中で、基本となる部分と、GNU arch との関連で重要な「分岐」という応用機能についてしぼって説明しようと 思う。

CVS では二人の登場人物がいる。一つは、「リポジトリ」と呼ばれ るデータ格納庫。もう一つはこの「リポジトリ」にデータを追加するのに 必要な補助的な領域である「作業コピー」だ。「リポジトリ」というとな んだか高尚なもののようだが、実はもう我々はどんなものかイメージする ことができる。そう、前の節で図に書いたような、最初のリビジョンと追 加の差分情報が蓄積されたファイルを集めたディレクトリのことだ。この ディレクトリには、ディレクトリ内にあるすべてのファイルの、全ての履 歴情報が入っている。リポジトリからは、任意のリビジョンのデータを取 り出すことができるし、最新のリビジョンに次の差分を追加して、新しい リビジョンを作ることもできる。リポジトリはとても重要な場所なので、 直接編集したりすることは許していない。かならす CVS システムに対し てこれこれのことをしてくれ、と頼まなくてはならない。これはちょっと 窮屈に思えるかも知れないが、CVS にできる操作しか許さないことで、リ ポジトリのファイルを間違って削除してしまったり、勝手に名前を変えて しまったりといった操作ミスをなくすことができる。閉架式の図書館みた いなものを想像してもらってもいい。本を読みたいと思ったら直接本棚に 行くのではなく、係の人にとってきてもらう。あれと一緒だ。もちろん CVS はなにか神秘的なことをやるわけじゃない。内部的に前の節で話した GNUdiff や GNUpatch を使って一所懸命必要なリビジョンを計算して、君 のためにとってきてくれるというわけだ。あまり詳しくない人から見ると、 リポジトリはものすごい数のリビジョンデータ全体がある巨大な格納庫に 見える。しかし実際には最初のリビジョン以外は差分の集合体なのだった。

もう一つの重要な登場人物が作業コピーと呼ばれる場所だ。CVS か らデータを取り出そうとすると、作業コピーが作られてそこにデータがコ ピーされる。ただコピーされるわけじゃなくて、どのリポジトリから取り 出したか、とか、取り出したリビジョンはどれか、などの情報も記憶して いる。作業コピーは同時に何人でも作ることができる。CVS が呼び出され るたび、呼び出した人用の作業コピーができる。これは閉架式の図書館と は違うところだ。現実の本と違って、デジタルデータはいつでもコピーす ることができるのだ。このコピーを作るための命令を checkout と呼ぶ。 CVS の基本コマンド、その1だ。

図 1.10. CVSに依頼して作ったふたつの作業コピー

CVS での基本的なワークフローはいたって単純だ。まず、リポジト リから最新のリビジョンを作業コピーに checkout 命令で取得する。それ から作業コピーに対して必要な修正を加える。これでいいなということに なったら、CVS システムに対して、今回の作業コピーの内容をリポジトリ に追加してくださいという命令を送る。すると CVS は現在の最新リビジョ ンと作業コピーとの間の差分をとる。それからできた差分をリポジトリを 構成する各ファイルに追加する。この操作を commit と言う。基本コマン ドその2だ。なんだか CVS はエラク高尚なことをしているように思うかも 知れないが、実際には前節で紹介した GNUpatch とか GNUdiff のような プログラムがやるのと同じようなことをしているだけだ。get して、コミッ トする。この繰り返しによって、リポジトリのリビジョンはどんどん増え ていく。

他にも CVS はいろいろなことができる。たとえば、最新リビジョ ンよりも前のリビジョンを取り出すこともできるし、あるリビジョンと別 のリビジョンの差分を計算して、表示させることもできる。既に少し説明 した、ログメッセージの内容を表示させることもできる。これを見れば、 ああ、あの時のコミットは、こんなことをやったのだった、と見当がつく。

話がこれで終ってしまうのなら、CVS は GNUpatch と GNUdiff の やったことを一手に引き受けてくれているだけで、あまりありがたみがな い。CVS が便利なところは、複数の人間がそれぞれ作業コピーを作って同 じリポジトリにコミットできるような仕組みを提供しているところだ。 CVS の C はコンカレントの C だが、それはこのことを意味している。 ちょっと考えればわかるように複数の人間が勝手に checkout して修正を コミットすれば、修正がお互いに衝突してしまったり、相手のした修正点 に気づかず上書きしてしまったりするのは想像がつくだろう。詳しい説明 は省略するが、CVS はこの当たりの交通整理もしてくれる。ある人が修正 した部分に別の人が更に修正しようとすると警告してくれたり、まずは他 の人がした修正点がどんなものであったかを自分の作業コピーに受け取る ように指示してくれたりする。

CVS について説明した。CVS は GNUpatch と GNUdiff をうまく組 み合わせて統合したソフトで、基本的な命令 get と commit を持ってい るのだった。get を使って作業コピーと呼ばれる場所に、バージョン管理 されたデータを読み込んでは修正し、一段落したら commit して、元のデー タに差分を追加していくのだった。実際にやっていることは要するに GNUpatch や GNUdiff と変わらないのだが、使い勝手はずっと良くなって いるし、GNUpatch や GNUdiff や差分の仕組みのことを知らない人でも気 軽にバージョン管理の恩恵にあずかれると、こういう話だった。利用者が 知っていなくてはならないのは、差分とか、特殊なファイル形式とか、繁 雑な GNUdiff/GNUpatch の操作ではなく、リポジトリ、作業コピー、 get/commit のような、もっと次元の高い概念だけでいいのだった。さら に CVS は複数の人間が get / commit する場合でも、お互いの変更がか ぶったりしないように調整したり、同時に複数の人が commit しないよう に、うまく交通整理してくれると、こういうわけだった。合言葉は「スイッ チ・ポン」だ。これが世界を救うのだ。

ここでは最後の、複数の人間の共同作業、というところをもう少し 堀下げて考えてみたい。ある一つのデータをみんなで協力して改良したり 修正している場合には get/commit だけで十分だ。たとえばいまずっと問 題にしてきた、国家間で利用されるある重要なドキュメントに対して、帰 りがけに A が 10243行目の誤字に気がついたとする。A は時計とにらめっ こしながらCVS に頼んで作業コピーに最新リビジョンの内容を get する。 作業コピーの上で10243 行目を修正する。そして CVS に頼んで commit する。ばっちりだ。でももしかすると B もちょうどそのとき同じ間違い に気づいてやっぱり自分の作業コピー上で10243 行目を修正してコミット してしまっていたとする。そんな時は CVS は、その修正はもう B がやっ てるよと教えてくれる。そして commit は失敗するが、もちろんその失敗 は意図したものだし、手柄が A じゃなく B のものになっただけで誰も困 らない。

しかし、もう少し複雑な状況を考えてみる。いまは、たった一つの ドキュメントをめぐっての作業フローだった。でも、以下のようなことも、 よくおこる。基本的にはこのドキュメントと同一の内容を持っているのだ が、内容の一部がほんの少し違っているようなものが欲しくて、しかもそ れはそれで独立した文書としてずっと管理していきたい、という場合だ。 たとえば、この国家間ドキュメントには、なんらかの非常に重要な機密事 項も含まれていて、各国の首脳級レベルの人間以外には配布したくない、 と。でもそのような部分は非常にわずかで、それ以外の部分については各 地に散らばっているエージェントに配布したい、と。極秘版と、一般大衆 版のふたつのバージョンが欲しい、と。

そんな重要な文章の機密内容を、俺や Hally や Sally 程度の人間 が編集できるもんかと言うかも知れない。ではもう少し現実的な例を出そ う。そのためには君にプログラマーの役を演じてもらう必要があるが、も 実際にそんな知識が必要なわけではない。学芸会に出てくる南の国の王様 みたいにそのまま椅子にふんぞり返っていてくれればいい。いま、ある企 業が新しいソフトウェアを開発している。このソフトウェアは有料なのだ が、よくあるように、評価限定版というのがあって無料でダウンロードし て利用できる。評価限定版は、製品版と、うり二つだ。ただし、30日たつ とすべての機能が利用できなくなってしまう。そこだけが製品版との違い だ。評価版 = 製品版 + 30日タイマー、と書き表すことができる。

図 1.11. 評価版 = 製品版 + タイマー

ところで、ソフトウェアには間違いがつきものだ。これをバグと言 う。ソフトウェアが完成したらバグも全部なくなっていると思うかも知れ ないが、そんなことはない。出荷したあともいろいろなバグが見つかるし、 そのバグは修正していかなくてはならない。もちろん大きなバグ、利用す るのに致命的なバグというのはなくなっている。でなければそんなソフト 買う人なんていないだろう。この細かいバグには作り手もユーザもいつも 悩まされる。作り手は新しく何かを作るではなく、既に作ったものを保守 しているわけだから、やる気も失せてしまっている。それにバグを直した つもりが、別のバグを生んでしまうことがある。笑うかも知れないが、こ れは本当によくおこることなのだ。逆に、ユーザはしみ一つない動作をす ると期待してソフトを買ったのに実際には細かい動作が意図したように動 かない。評価版が用意されているのにはこんな理由がある。もし評価版を 使って問題があれば、買わなければいい。あるいはここを直してくれたら 買うんだが、とその会社に E-mail してあげてもいい。

ながながと書いてしまったが、評価版 = 製品版 + 30日タイマー、 となっていた。評価版に新しいバグが発見されたとする。すると、それは 製品版と共通の部分に含まれているか、30日タイマーの部分に含まれてい るかのどっちかだ。共通部分に含まれているなら、評価版のバグを修正し たら、製品版にも反映させなくてはならない。たとえばプログラム開始時 に「ようこそ、このソフトウェアへ」という文言が間違って「そうこよ、 このソフトウェアへ」と表示されてしまったら、これは共通部分に含まれ ているバグだ。でも 30日タイマーの部分なら、製品版の方には反映させ てはいけない。たとえば 30日ではなくて、60日たって使えなくなったら、 これはタイマーのバグだ。評価版と製品版は、とてもよく似ている。そし てほんの少し、つまりタイマーの部分だけ、ちょっとだけ違っている。そ してそのちょっとだけ違っている部分を保ちながら、両者を厳密にそれぞ れ管理していかなくてはならない。もし 30日タイマーの部分を不用意に 扱って、そこに別のバグが生まれてしまったら、タイマーは働かず、評価 版はいつまでも使えるようになってしまうかも知れない。これでは会社が もたない。

CVS では、こういう状況がうまく扱える。これを分岐、と言う。そ して分岐を作ることをブランチ化すると言う。英語では動詞も名詞も branch という一つの言葉で表せるので都合が良いが、日本語の場合だと 場合におうじて分岐と言ったりブランチと言ったりする。今の例では、お そらく製品版の方が先にあったはずで、そのためのリビジョンが CVS リ ポジトリに並んでたはずだ:

図 1.12. リポジトリ内に一列に並んだリビジョン

話が違うんじゃないかと思う人もいるかも知れない。CVS のリポジ トリは初期リビジョン+差分の集まりだと説明したばかりじゃなかったの か、と。絵が縄文式に戻っているぜ、と。その通りなのだが、ここから先 は実際のリポジトリの内部構造は忘れてしまうことにする。そういうコマ ゴマした詳細を隠すためにできたのが CVS だし、ここからの議論には内 部構成は関係しないからだ。利用者から見れば、リポジトリにあるものは 時間と共に増えていく一方のリビジョンの集まりだ。上の図ではそれぞれ のリビジョンを数字だけで表している。これで十分なのだ。

ここから、評価版のための分岐を作る。このためのコマンドは紹介 しないが、やはりスイッチ・ポンで分岐できる。分岐した後は、CVS リポ ジトリの中はこうなる:

図 1.13. 分岐後のリポジトリの様子

二つの横に伸びた線のことを、開発ライン、と言う。そして、最初 からあった製品版の開発ラインのことを幹といい、後から分岐してできた 評価版の方の開発ラインを枝、と言う。もちろんこれは開発ラインが分岐 している様子を一本の木にたとえたものだ。幹は英語で trunk, 枝は branch で、みき、とか、えだという言葉がおさまり悪い時には、状況に 応じて、トランク、ブランチ、とそのまま書いたりすることもある。こん な風に CVS リポジトリの中にはふたつ以上の開発ラインを分岐させるこ とができる。いままでずっと説明してきた一本の開発ラインはその特別な ケースになっていることがわかると思う。注意して欲しいのは、トランク 内にある数字で示されたリビジョンとブランチ内の同じ数字で示されたリ ビジョンは何の関係もないということだ。数字はそれぞれの開発ライン中 でのリビジョンの番号を示しているだけで両者は独立した別のデータだ。 図中トランクのリビジョン2 からブランチのリビジョン 0 に矢印が伸び ているが、ここで分岐がおきたことを示している。だからこの二つのリビ ジョンの内容は全く同じものだ^[2]

枝と枝との間では、両者に共通の修正点をお互いに取り込むことが できる。これをマージと言う。もちろんすでに説明したように、タイマー のバグの修正を製品版にとりこんじゃいけない。とりこむのはメッセージ の間違いの修正だけだ。たとえばこんな感じ:

図 1.14. 修正点の選択的なとりこみ

詳しく説明すると、トランク側の、2->3, 3->4, 5->6, 6->7 で追 加した修正はブランチ側に取り込まれていない。だから具体的にどういう バグかはわからないが、とにかく製品版にだけ関係したプログラムの間違 いだったのだろう。逆にブランチ側の 0->1, 2->3 はトランク側には反映 されていないので、評価版のみのバグ、おそらくタイマーに関係したバグ の修正だったのだろう。またブランチ側の 3->4 の差分はトランク側7 で 取り込まれている。だからこれは両方の開発ラインで共通のメッセージの 間違いのようなものだったのだろう。トランク側 4->5 についても同様だ が、最初に発見したのはトランク側開発チームで、それをブランチ側がと りこんでいる。こうして トランク と ブランチ の開発ラインは、共通の 修正点については同期して、片方にしか関係しない修正点についてはきち んとその違いを保存したまま、時間にそってしずしずと行進を、いや、更 新をつづけていくのだ。

さあ、CVS について大分説明してきた。細かい話は別にして、以上 が CVS の持っている機能の大部分だと考えてもらってよい。君は言うか も知れない。ブラボー。すばらしい。で、君はいったい何が不満なのだ、 と。

私の答えはこうだ:CVS の分岐概念には、根本的な欠陥がある。

私の目の前に一台のパソコンがある。Linuxというフリーソフトウェ アが動いている。自分で設定したものだ。このコンピュータはインターネッ トに接続されていて、その気になれば、誰でもアクセスすることができる ようになっている。「その気になれば」と言ったが、これには二つ意味が ある。まず、私がその気になることで、もう一つは実際にアクセスしよう とする相手もその気になることだ。単にアクセス、と言っても、実はいろ いろな方法がある。いくつかの方法については、私は誰でもアクセスして 良いように設定してある。たとえばいくつかの Web ページは誰でも見る ことができる。それを使って私は情報を外部に発信しているから、見るこ とのできない人がいると都合が悪いからだ。だから、この件では私はすで にその気になっている。あとは相手がその気になるだけだ。つまり私のペー ジに興味を持ってくれて、URL をブラウザに打ち込めばいい。これは一番 よく知られたアクセス方法だが、実は他にもいろいろある。たとえば telnet と呼ばれている方法があって、このアクセスを許すと、私のコン ピュータに対して、非常にたくさんのことができるようになる。コンピュー タには私にとって大切なものも含まれているので、私は telnet でアクセ スできないように設定してある。つまり私はこの件では「その気に」なっ ていない。だから外部の人間がいくら「その気」になっても私のマシンに telnet することはできない。まずは私が「その気」にならなければなら ないのだ。

図 1.15. コンピュータといろいろなサービス

今は、私と、それ以外の人との間で線引きしたが、実はもっと細か くアクセス制御することができる。たとえば、Hally と Sally にだけ telnetを許して、それ以外の人、たとえば例の天才君には許さないように もできる。会員制のホームページを見たことはないだろうか? ある画面ま で行くと、ログインiDとパスワードを入力してくれ、という画面に飛ばさ れるだろう。そう、私はあのことを言っている。あれは Web サービスに 対するアクセス制御の一種だ。そのサービスが動いているコンピュータの 管理者が、決まった人しかアクセスできないような設定をそのコンピュー タにしたから、君はおいそれとはアクセスできない。そうか。最初からこっ ちの例で説明すればよかった。

図 1.16. コンピュータとアクセス制限

CVS も、Web アクセスや、telnet と同じようにできる。つまりCVS をうまく設定して、CVS のリポジトリのあるサーバをインターネットにつ なげてやると、どこからでも CVS を使えるようにすることができる。つ まり、いままで説明してきたスイッチポンを、出先のコンピュータからも できるようになる。この場合、get コマンドで作成される作業コピーは出 先のコンピュータにできる。修正点を commit すると、今度はインターネッ トの上をデータが逆向きに流れて、作業コピーからリポジトリに向かって データが流れて、結果がリポジトリに追加される。だから君は世界中のど こにいても作業ができる。たとえば Sally がタンザニアに出張になった とする。Sally は例のソフトウェアのプログラムを管理している CVS リ ポジトリの入ったマシンに、タンザニアのインターネットカフェからアク セスできる。もちろん CVS リポジトリには適切なアクセス制御が必要だ。 これは会社の重要な資産が入ったサーバだから、外部の人間に勝手に get やcommit されては困る。だから君とHallyとSallyだけがアクセスできる ように設定されているのが普通だろう。

図 1.17. CVS サービス専用機とアクセス制限

「設定されている」などと不用意に書いてしまったが、別にコン ピュータ自身が場の空気を読んで、君や Hally や Sally を自動的にそっ と設定してくれるわけではない。コンピュータはそんなことはしてくれな い。実際には誰か生身の人間が「設定する」のだ。じゃあ誰がやるのだろ う。君の今までの話を総合すると、君もHallyもSallyにも、ちょっと荷が 重そうだ。こういう時には会社の中にシステム管理者と呼ばれる人がいて、 その人に設定を頼むことになる。「こんど、これこれの仕事にかかわるこ とになったから、例のリポジトリに get/commit をする必要があるんだ。 悪いけど設定してもらえないかなあ」君は100万ドルのスマイルで誰かに に頼む。もしかすると頼む相手は、君がこないだ言ってた天才君なのかも 知れない。もしそうなら君の笑顔に私は同情する。いずれにしても君は誰 かに頼む。機嫌がよければ、あるいは Sally が一緒ならコンマ2秒で設定 してくれるだろう。でもあいにくその日は朝から雨で、彼は奥さんと新発 売のポテトチップスの空袋が不燃ゴミか否かをめぐって大喧嘩をしてきた ばかりで、通勤電車の中ではハイヒールを履いた若い女性に踏まれ、駅の 売店では 150円少なくお釣りを渡され、工事中のマンホールにあやうく落 ちそうになり、よけたはずみで、ガムを踏んでしまい、あげくのはてに会 社に来てみると、メールボックスが新型ウィルスのまきちらしたスパムで 一杯になっていたとしたらどうだろう。私ならこう考える。「今日はやめ ておこう」。そしてそのまま Sally のデスクに言って、明日は丈の短い スカートで来てはくれまいかと頼む。

私が言いたいことはこうだ。システム管理者の許可なしには誰も CVS リポジトリにアクセスすることはできない。国立博物館の特設会場に 展示してあるガラス張りのミイラと一緒で、君はリポジトリに指一本触れ ることができない。作業できるもできないもシステム管理者の腹一つなの だ。一つの企業内の話なのだからこれでもいいのかも知れない。いや、む しろ好ましい場合さえある。しかし、現実のデータ管理にはもっといろい ろな形態があるのだ。たとえば、先のソフトウェアで、有償版は自社で作っ たが、ここで社内の担当者は燃え尽きてしまい、タイマーの部分について は子会社に発注するようなこともありうる。いま言ったように CVS はネッ トワーク越しに利用できるので、子会社からもget/commitができる。しか しそのためには、あなたの企業のシステム管理者は子会社の人たちにも許 可を設定しなければならない。CVS はもちろんセキュリティーのことを十 分に考えた設計になってはいる。しかし子会社にはどんなモラルの人間な のかはっきりしないし、身元があまりはっきりしない外部の人間にいろい ろなアクセスを許すのは管理上問題がおきやすい。リポジトリに書き込み を許す場合はなおさらだ。commit はリポジトリに対する書き込み処理な のだ。

図 1.18. CVS サービス専用機と子会社からのアクセス

でも、CVS には分岐の機能があった。タイマー機能の枝を分岐して、 そちらの部分にだけ子会社の人にアクセスさせれば良いではないか、と。 そういう機能は CVS にはない。それに同じマシンの上に二つの枝がある から、このコンピュータがディスク障害を起こすと、両方の枝のデータが 消えてしまう。もし分岐がネットワーク上にある別のマシンの別のリポジ トリの中に作ることができれば問題は解決する。つまり、子会社の中にも CVS リポジトリを持つサーバを用意して、インターネットにつないだあと、 元のリポジトリにある有償版の分岐を、このもう一つのマシンのリポジト リの中に作れば問題は解決する。しかし、CVS の分岐は、同一マシンの同 一リポジトリ内にしか作成することができないのだ。もうお分かりだろう。 私が CVS の分岐の根本的な欠陥というのはこの事実を指しているのだ。

図 1.19. CVS の分岐の限界

こんな風に書くと、私は何かことさら特殊なケースを持ち出して CVS の欠点をあげつらっているかのように見える。しかし、これは一般的 な状況なのだ。特にフリーソフトウェアを開発するときにこういう事態に よく出くわす。ちょうどいい例がある。私は GNU arch のリポジトリを Webブラウザで閲覧するための ViewARCH というフリーソフトを作ってい る。こんな場合、読み込みアクセスを世界中に許して、そのソフトウェア を公開するのが普通だ。もちろん私もそうしている。フリーソフトウェア は誰にも自由に使ってもらうことを意図して作られるし、こうしておけば、 悪い部分を誰にでもすぐに指摘してもらえるからだ。しかし普通書き込み アクセスは許さない。私も許していない。さて地球の裏側の誰かが私のソ フトに興味を持ったとしよう。そしてどこかにバグを見つけたか、新しい 機能を追加しようと思ったとする。私が CVS でこのプログラムを管理し ていたとすれば、この地球の裏側の人間に対して、私のマシンに対するア クセス許可を与えなくてはならない。しかし、このような人間とは通常電 子メールのようなもので知り合うだけで、面識はないことが多い。実際に 会うことは一生ないような人たちも多い。こんな状況でその人間に簡単に アクセス権を与えるわけにはいかない。もちろん信頼できる良識のある人 間だとわかれば、アクセスを許すことができて、分岐の仕組み自体はもっ ているのだから、CVS を使って自分のバージョンと彼のバージョンとを一 つのリポジトリ内にうまく共存させることができる。時々の彼の枝の内容 を見て気に入ればマージすることもできる。彼も自分オリジナルの変更を 自分の枝に加えながら、私のアイディアを取り込むこともできる。しかし これらはどれも彼にアクセス権を与えて初めてできることなのだ。

もし分岐を、ネットワークの他のマシン上に作ることができて、そ の枝同士でマージができれば、問題は解決する。このような機能 をもったバージョン管理システムは、ネットワーク上にさまざまなリポジ トリが分散して存在するので、分散型のバージョン管理システム、と呼ば れる。これに対して CVS のように、ひとつのマシン上のひとつのリポジ トリだけで世界が閉じているバージョン管理システムを集中型のシステム と言う。GNU arch 分散型バージョン管理システムとして設計された。い ま述べてきたことは GNU arch では簡単にやることができる。分岐を作る ときには分岐元のマシンの管理者は、自分のマシンに特別な設定をする必 要は何もない。通信ログを見なければ、地球上の誰かが自分のリポジトリ の分岐を作ったことに気づきさえしないだろう。

図 1.20. GNU arch の分岐はリポジトリの境界を越えることができる

ずいぶん長々と述べてきた。ここでまとめようと思う。

GNU arch にはこのほかにもさまざまな改良点を持っている。その どれもがすばらしいものだが、ここでは分散型の性質だについて徹底的に 絞って述べた。私の考えではこれが GNU arch と CVS とを分かつ最も重 要で強力な性質だと考えるからだ。

もし君がエラい腕っぷしの強い男で、夜たまたま通りかかった路地 裏で三人の暴漢が君の理想のタイプを取り囲んでいる場面に出くわしたと したら、うれしくて泣きそうになるだろう。彼らだって同じなのだ。

一般的に言って、GNU arch のインストール時にはそれほど大きな 問題は起こらないのが普通だ。GNU arch は外部環境にほとんど依存しな いからだ。たとえば glibc のようなライブラリは利用せず、hackerlab という奇妙な名前の自前のライブラリを使ってシステムが構築されている。 本質的に外部に依存するのは、GNU tar, GNU diff, GNU patch のような プログラムで、これらのプログラムが古かったり GNU 互換ではないと不 具合が生じることはある。

GNU arch をインストールするにはまずは最新のソースコードを手 に入れる必要がある。公式なダウンロード先は以下の URL だ:

http://regexps.srparish.net/src/tla/

ここでは tla-1.2 を利用する。wget や curl のようなプログラ ムで取得する。

$ wget http://regexps.srparish.net/src/tla/tla-1.2.tar.gz
…
$

tla が GNU arch のコマンドとしての名前だ。何の略かという話に なるとTom Lord's Arch とか、Three Letter Acronym とか、いろいろ言 われる。深い意味はない。こジャレたウィットの解説を言った本人の口か ら聞くほど野暮なことはない。とにかく tla と言う。ソースコードを展 開すると、以下のようになる:

$ tar zxvf tla-1.2.tar.gz
…
$ cd tla-1.2
$ ls
=ARCH-USERS-README  =INSTALL  =RELEASE-ID  COPYING  configs  src  {arch}
$

普通の人であれば、おそらくこの時点で驚くだろう。こういうのが GNU arch の一番困ったところだ。これから楽しいバカンスに行こうとい うのに、家の前でいきなり車に引かれそうになる。ls の出力で '=' や' {','}'という文字を目にすることはそう多くはないが、普通のアルファベッ トと同じようにファイル名に利用できる文字とされており、GNU arch は 特殊なファイルを分別するのに、さまざまな場面で積極的にこのような文 字を利用するのだ。C 言語などを知っている人なら、識別子に対して '_' のような文字も含めて考えるだろう。このようなものだと思って割り切る のが一番良いようだ。

このような特殊文字の多用の是非については GNU arch メーリング リストで非常に頻繁に議論されてきた。メリットとしては、通常のバージョ ン管理対象となるファイルとの間に区別を設けることで特殊な処理をする 場合に便利であることをあげることができる。詳しくはインベントリとファ イルグループを議論する XXX で触れる。デメリットとしては、新規ユー ザを驚かせてしまい、学習曲線を不要に高くしてしまうこと、Unix のシェ ル上での補間機能がうまく効かない場合が出てくること、また他プラット フォームへの GNU arch の移植を困難にすること、などがあげられる。い ずれにせよ、ここではただ一言ですませる。つまり、「気にするな」だ。

いま展開した tla のディレクトリに戻って話を進めると、'='で始 まるファイルはいずれも普通のファイルだ。また {arch} はディレクトリ だ。ここではたまたまそうなっているが、'=' がかならず普通のファイル に利用されるとは限らない。ディレクトリであることもある。

実際のコンパイルは、=INSTALL ファイルに書いてあるとおり、src ディレクトリの下に =build というディレクトリを作ってからそこに移動 して実行する:

もう一度いう。'=' のような文字は気にするな。

$ cd src
$ ls
COPYING      Maintfile    PLUGIN       configure       docs-tla   links  {arch}
ChangeLog.d  Makefile.in  build-tools  docs-hackerlab  hackerlab  tla
$ mkdir =build
$ cd =build
$

通常のプログラムのインストールと同様、設定スクリプトの実行、 実際の構築、構築後のインストール、という 3 段階で進む。最後の段階 以外はすべてこの =build ディレクトリの中にしか書き込まない。インス トール前であれば =build ディレクトリを丸ごと消せば初期状態に戻る。

設定は以下のようにする

$ ../configure --prefix=/usr/local

Standard Configuration Settings:

    system = i686-pc-linux-gnu
    package =
    lord@emf.net--2004/dists--devo--1.0--patch-9(configs/emf.net-tla/devo.tla-1.2)
…
    src

configuring src...
$

--prefix オプションはインストールフェーズで実際に GNU arch をインストールする先になる。--prefix を省略すると、. /src/=build/=install がインストール先になるので、まだ GNU arch を あまり信用していない人はここにインストールして動作を試すこともでき る。気に入らなければひとつ上の =build ディレクトリからまるごと削除 すれば tar を展開した直後の状態に戻る。他の場所にはいっさい書き込 みをしない。現時点で GNU arch は単一のプログラムとして構築され、モ ノリシックなプログラム tla のみからなるので、インストール後そのま まコピーして別の場所に持っていっても動作する。(今後のバージョンで どうなるかは保証しない)。

--prefix オプションは通常は /usr/local にすると良い。これで /usr/local/bin に tla という名前のコマンドでインストールされる。間 違って /usr/local/bin と指定しないこと。これだと/usr/local/bin/bin にインストールされてしまう!

実際に構築する。長いメッセージが出力される。

$ make
set -e ; \
for dir in build-tools hackerlab links tla docs-tla; do \
	make -C $dir all ; \
done
make[1]: Entering directory `/home/octopus/tla-1.2/src/=build/build-tools'
set -e ; \
for dir in standards; do \
	make -C $dir all ; \

…

set -e ; \
for dir in src; do \
	make -C $dir all ; \
done
make[2]: Entering directory `/home/octopus/tla-1.2/src/=build/docs-tla/src'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory `/home/octopus/tla-1.2/src/=build/docs-tla/src'
make[1]: Leaving directory `/home/octopus/tla-1.2/src/=build/docs-tla'
$

最後にインストールする。

$ make install
set -e ; \
for dir in build-tools hackerlab links tla docs-tla; do \
	make -C $dir install ; \
done
make[1]: Entering directory `/home/octopus/tla-1.2/src/=build/build-tools'
set -e ; \
for dir in standards; do \
	make -C $dir install ; \

…

set -e ; \
for dir in src; do \
	make -C $dir install ; \
done
make[2]: Entering directory `/home/octopus/tla-1.2/src/=build/docs-tla/src'
make[2]: Nothing to be done for `install'.
make[2]: Leaving directory `/home/octopus/tla-1.2/src/=build/docs-tla/src'
make[1]: Leaving directory `/home/octopus/tla-1.2/src/=build/docs-tla'
$

実際に動作するかどうかは以下のコマンドで確認できる

$ tla help
                        tla sub-commands
                        ----------------

* help

                        help : provide help with arch


* User Commands

…

* Published Revisions Commands

                        grab : grab a published revision


* Miscellaneous Scripting Support

          parse-package-name : parse a package name
          valid-package-name : test a package name for validity


Use tla command -h for help on `command', or tla command -H for detailed help
$

かなりたくさんのコマンドがある。100近くもあるが、実際によく 利用するのは一握りだ。あとは実験的なコマンドであるか、GNU arch に 精通してからしか利用することはない。GNU arch のコマンドが多いのは、 単純なコマンドを組み合わせることによってさまざまな複雑な機能を実現 できるようになっているからだ。ちょうど Unix のツール群と同じ考え方 です。ひとつひとつのコマンドはゾウリムシみたいに単純だが、うまく組 み合わせると恐ろしくいろんなことができる。この考え方にはデメリット もある。実際の利用で、どのコマンドの後にどのコマンドを実行すればよ いか、あるいはどのコマンドとどのコマンドをどのように組み合わせれば 必要なひとまとまりの機能を実現できるか、がすぐにはわからないところ だ。つまり、典型的なワークフローがどんなものか、すぐには見えない。

このドキュメントではよく利用されるコマンドと、その利用の順序 についてグループ分けして説明していこうと思う。私の考えでは、ワーク フローの観点から見たとき、GNU arch には 3 個のグループに分けるのが いいと思う。

この三つだ。

最初のグループは、GNU arch をインストールしたら必ずやらなく てはならない作業で、一度やれば二度以上やることは非常に稀なもの。二 つ目のグループは、新規に何かある特定のデータをバージョン管理しよう とするときの初期化処理、最後のグループは、初期化処理が済んだバージョ ン管理下にあるデータに対しておこなう日々の処理。この 3 番目のグルー プに属するコマンドは非常に少なく、せいぜい 5 個くらいだろう。

もちろん、GNU arch に慣れるにつれて残りのコマンドにも興味が わいてくるだろう。そのいくつかは処理を高速化したり、他の人のアーカ イブと協調して作業するのに必要だったり、GNU arch の根底を支える非 常に原始的な—そしてそれゆえ深遠な—コマンドであったりす る。詳しくは補遺のリファレンスを参照してほしい。一通り理解した後は リファレンス部分だけで話しが完結するような構成にしておいた。ここに はすべてのコマンドの一覧、書き込みの有無、典型的な例、CVS コマンド との対応、などについての記述がある。特に書き込みが全く発生しないコ マンドについては気軽に実行してその振る舞いを見ることができるだろう。 そして人によっては GNU arch の泥臭い実装の背後にある恐ろしく単純なデ ザインにおどろくかも知れない^[3]。

このドキュメントは GNU arch のあらゆるレベルのユーザに対して 役立つように書いたつもりだが、特にはじめて GNU arch を使おうと いう人の敷居をさげるのに役立てば、と思っている。

インストールが済んだ後、まずやらなくてはならないことが三つあ る。

この三つだ。

$ tla my-id "foo bar <octopus@bluegate.org>"
$ tla my-id
foo bar <octopus@bluegate.org>
$

$ uuidgen
08eebb07-f9c9-4b0a-973e-8c73863aec7c
$ tla my-id \
   "anonymous <anonymous@08eebb07-…3aec7c.invalid>"
$ tla my-id
anonymous <anonymous@08eebb07-…3aec7c.invalid>
$

$ pwd
/home/octopus
$ ls
Maildir  tla-1.2  tla-1.2.tar.gz
$ mkdir ARCHIVES
$ ls
ARCHIVES  Maildir  tla-1.2  tla-1.2.tar.gz
$ tla make-archive octopus@bluegate.org--2004 \
    /home/foo/ARCHIVES/octopus@bluegate.org--2004
$ tla archives
octopus@bluegate.org--2004
    /home/foo/ARCHIVES/octopus@bluegate.org--2004
$

$ tla register-archive octopus@bluegate.org--2004 \
    /home/tako/ARCHIVES/octopus@bluegate.org--2004

$ tla my-default-archive octopus@bluegate.org--2004
$ tla my-default-archive
octopus@bluegate.org--2004
$

GNU arch の抱える三つの問題は、[1]奇妙な文字の問題、 [2]長いファイル名の問題(-- の問題含む)、[3]ファイル判別ロジックの 複雑さ、である。これをもっと詳しく。

この章では GNU arch のインストールの仕方と、インストール後最 初にしなくてはならない設定について説明した。環境設定に関していくつ かの名前が出て来た。UserID, uid, アーカイブフォルダ、アーカイブ名、 アーカイブ位置名。これらはいずれも必要に応じて命名規約を満たしさえ すれば任意に指定できるが、できるだけ統一したほうが混乱が少なくて済 むことを説明した。

次の章では新しいアーカイブバージョンを作成する方法について説 明する。

この章では前の章の設定が済んでいると仮定する。つまり:

以上の前提が成り立たない限り以下の説明は少なくともそのままで は動作しないので注意してほしい。厳密にこの環境を作りあげることがで きないのは明らかだろう。自分用のメールアドレスを設定したり、ホーム ディレクトリの名前が違っている場合には適宜自分の環境にふさわしい形 に読みかえてほしい。

さて、アーカイブを作ってはみたものの、まだそこには何も存在し ていない。空っぽである。これからこの中に GNU arch での最も基本的な 管理単位である「バージョン」を作ってみようと思う。これ には tla setup-archive コマンドを使う:

$ ls
ARCHIVES  Maildir  tla-1.2  tla-1.2.tar.gz
$ tla archive-setup test--proj--1.0
* creating category octopus@bluegate.org--2004/test
* creating branch octopus@bluegate.org--2004/test--proj
* creating version octopus@bluegate.org--2004/test--proj--1.0
$

「バージョン」とは、他のバージョン管理システムで は「リポジトリ」と呼ばれるものにあたる。バージョンの中 に初期データをインポートし、その後データを修正してはコミットを繰り 返すことで、時間と共にデータがバージョンに蓄積されていく。ある１時 点でのバージョンの内容をリビジョンと言う。バージョンはリビジョンの 集まりで、それぞれのリビジョンは作られた時間によって順序づけされて いる。リビジョンにゼロから始まる番号をつけて、この番号によって特定 のリビジョンを指定することができる。これをリビジョン番号と言う。リ ビジョンはまた自分の性質に応じた名前をもっている。これをリビジョン 名と言う。通常最初のリビジョン名は base-0 だ。それ以降のリビジョン 名は普通 patch-n という名前になる。ここで n は 1 から順番に増えて いく整数でリビジョン番号と呼ばれる。

バージョンという言葉の日常的使い方から連想されるものはリビジョ ンに近いことに注意しよう。たとえば「XYZ ソフトウェアのバージョン1 がバージョンアップして バージョン 2 になりました。どうぞお買い求め ください」というときの「バージョン」は、GNU arch でいう「リビジョ ン」の意味に近く、「XYZ ソフトウェア」が、GNU arch でいう「バージョ ン」に近い。「リビジョン」という言葉のこういう使い方は GNU arch に 限らずモダンなバージョン管理システムではほぼ共通に使われている。 「バージョン」という言葉のほうは他のシステムでは「リポジトリ」と呼 ばれることが多いが、要するに「リビジョン全部」をまとめたもののこと を指す。

いま作ったバージョンは、test--proj--1.0 という名前だ。GNU arch ではこのようにバージョン名は三つの単語を '--' でつないだ名前 にしなくてはならないという規約がある。三つの部分を先頭から「 カテゴリ名」、「ブランチ名」、「バージョン名 」と言う。バージョンが、カテゴリ名、ブランチ名、バージョン名 の三つの文字列の組み合わせで構成されていることには、論理的な必然性 はまったくない。また、それぞれの名前から連想されるような名前間の制 約や階層構造があるわけでもない。単に 「第一名称部」、 「第二名称部」、「第三名称部」と考えて問題な い。これらの名称に深い意味はなにもない。

今後バージョンに関する一般的な議論の時、バージョンを指すのに シンボリックに C--B--V と記述することがある。C, B, V はもちろんそ れぞれの名前の頭文字だ^[4]。 複数のバージョンを使った議論では、C1--B1--V1, C2--B2--V2, … のようにしていくつかのバージョンを示すこともある。「バージョ ン」と「バージョン名」の違いに注意してほしい。GNU arch の一部のドキュメントではこの区別があいまいなものもあるが、文 脈に応じてどちらの意味かを判断してほしい。

バージョン、という言葉の日常的な意味からは、異なるバージョン との間の関連を連想してしまうかも知れない。たとえばtest--proj--1.1 という名前の別のバージョンを作ることもできる、この場合、 test--proj--1.0 と test--proj--1.1 との間に、何か意味的につながり が生ずるのではないか、と。しかし、この両者はまったく別のバージョン、 他のバージョン管理システムの言葉で言うと、まったく別のリポジトリだ。 異なるバージョン間を「継続」という機能を使って関連づけ ることはできるし、それが似た名前のバージョンであったほうが人間にとっ ては都合が良いかも知れない。しかし、test--proj--1.0の継続を test--proj--1.1 とするかわりに、ergo--sum--100.0という名前のバージョ ンを作って継続し、test--proj--1.1 をまったく別の目的に利用すること も、そもそもそのようなバージョンを作成しないこともできる。継続につ いては別の章で詳しく議論する。

バージョンは必ず、どこかのアーカイブ中に作成される。今の場合 だと octopus@bluegate.org--2004 という名前のアーカイブだ。tla archive-setup コマンドで、これを明示的に指定する引数はなかったが、 これはデフォルトアーカイブを octopus@bluegate.org--2004 にあらかじめ設 定しておいたからだ。いまはまだ一つのアーカイブしかないが、複数のアー カイブが存在して、デフォルトアーカイブ以外のアーカイブにバージョン を作成したい場合には -A というオプションを使って明示的に作成先を指 定することもできる。バージョンは指定されたアーカイブ中にできるだろ う。-A オプションは tla archive-setup コマンドに限らず、アーカイブ の指定が必要なすべての tla コマンドで指定することができるオプショ ンだ。そのようなコマンドで -A オプションを省略するといつでもデフォ ルトアーカイブが指定されたものと見なされる。

同じ名前のバージョンを別のアーカイブに作成することもできる。 その場合、C--B--V だけを指定しても両者を区別することができない。こ の場合、アーカイブ名をつけて、 octopus@bluegate.org--2004/test--proj--1.0のように表現する決まりがある。 この表現を使うと、ある特定のバージョンが完全に定まる。これは一つの マシン上に限ったことではない。アーカイブ名はE-mail アドレスを含ん でいるので、地球上のすべてのマシンを考慮しても一意に定まる。 octopus@bluegate.org--2004/test--proj--1.0 は、君のマシン上にある、地 球上で唯一ここだけにあるバージョンだ。^[5]後の章で、バージョン間でデータの交換をしなくては ならない場合に、この一意性が大切になる。このように A/C--B--V の形 で指定したバージョンを、完全に修飾されたバージョン名、と言う。

アーカイブと、バージョンの関係を絵に書いてみる。すでに注意し たように、カテゴリ名とブランチ名は、バージョンの階層構造にはまった く関係しない概念だ。つまり:

図 3.1. まちがったバージョンの階層構造

ではなくて:

図 3.2. 正しいバージョンの階層構造

のようにイメージしてほしい。地球上の無数のマシンの上に、異な る名前のついた無数のアーカイブがあり、その中にさまざまなバージョン が存在している。octopus@bluegate.org--2004 と、 bar@bogus.example.com--2003、上には、同じ名前のバージョン festina--lente--1.0 がある。これはたまたまそうなったのかも知れない し、二人のハッカーが関連するバージョンを表すのにお互いにわざと同じ 名前を取り決めたのかも知れない。いずれにせよ、同じ名前のバージョン が別のアーカイブにあっても、地球上の GNU arch 分散システムが混乱す ることはない。別のディレクトリにある二つの readme.txt ファイルが何 の関係もないのと同じことだ。

図 3.3. バージョン同士の関係

ふたつのバージョンは、同じアーカイブ内にあろうがなかろうが、 別のアーカイブ内にある場合、その二つのアーカイブが同一マシンにある かどうかには全くかかわらず、対等な関係にある。後の章でアーカイブ間 の分岐やマージについて説明するが、このような特殊な関係にある二つの バージョンは、それぞれどのアーカイブの上にあっても同じように動作す る。同じアーカイブ上になければできないような処理はない ^[6]。

さてあるアーカイブ中にどのようなバージョンがあるかは tla abrowse で確認することができる:

$ tla abrowse
octopus@bluegate.org--2004
  test
    test--proj
      test--proj--1.0

$

このコマンドも明示的にアーカイブを指定しなければ、デフォルト アーカイブに対して処理される。確かに今作ったバージョンが存在して いる。

準備は整った。次の節では、このバージョンに対して実際にデータ をインポートしてみる。何か新しいことを始めるとき—それは誰も 挑戦したことのない問題を解くためのプログラムかも知れないし、歴史の 本を書くことかも知れない—最初にやることになるのが、次の節で の議論だ。

GNU arch の初期インポートの典型的なユースケースは三種類ある。

以下では最初の利用方法について説明する。二番目については次章 のインベントリの議論を通じて説明し、最後のものは分岐の章で説明しよ うと思う。初期設定に関してだけ言えば、二番目のケースが一番面倒で、 最後のものは一番簡単だ。

$ pwd
/home/octopus/proj
$ find
.
./lib
./lib/tools.c
./inc
./inc/tools.h
./main.c
./cc.sh
$

$ cat main.c
#include "./inc/tools.h"

int main()
{
        hello_world();

        return (0);
}
$

$ cat lib/tools.c
#include <stdio.h>

void hello_world()
{
        printf("hello world\n");
}
$

$ cat inc/tools.h
void hello_world();
$

$ cat cc.sh
#!/bin/sh

cc -o hw main.c lib/tools.c
$

$ chmod +x cc.sh
$ ./cc.sh
$ ls
cc.sh  hw  inc	lib  main.c  {arch}
$ ./hw
hello world
$ 

$ ls
cc.sh  inc  lib  main.c
$ tla init-tree test--proj--1.0
$ ls
cc.sh  inc  lib  main.c  {arch}
$ tla tree-version
octopus@bluegate.org--2004/test--proj--1.0
$

$ tla id-tagging-method
explicit
$ 

$ tla id-tagging-method names
method set: names
$ tla id-tagging-method
names
$ 

$ tla inventory
S  cc.sh
S  hw
S  inc/tools.h
S  lib/tools.c
S  main.c
$ 

$ vi {arch}/=tagging-method

$ emacs {arch}/=tagging-method

exclude ^(.arch-ids|\{arch\}|\.arch-inventory)$

exclude ^(hw|.arch-ids|\{arch\}|\.arch-inventory)$

$ tla inventory
S  cc.sh
S  inc/tools.h
S  lib/tools.c
S  main.c
$ 

初期インポート作業(4) - インポート

おまたせしました、と心から言いたい気分だ。どうして使い始め からこんなに複雑なのだろう。たかがバージョン管理システムだろう。 俺にとってはただの手段でしかないんだ。こむつかしいこといいなさん な、こっちはとっとと使いたいだけなんだよ、と。そう感じているなら、 たぶんあなたは正常な人間だ。でも忍耐もここまでだ。インポート処理 自体は、まるでアレキサンダー大王の最後みたいにあっけない。

$ tla import
* imported octopus@bluegate.org--2004/test--proj--1.0
$ 

あまりにあっけなくて本当にインポートできたかどうか不安にな る。確認する方法はいくつかある。まずは、アーカイブ全体のようすを ざっと見るための tla abrowse コマンドを実行すること。

$ tla abrowse
octopus@bluegate.org--2004
  test
    test--proj
      test--proj--1.0
        base-0

$ 

base-0 という表示があるだろう。これは最初のリビジョンの名 前だ。確かに作成されているようだ。余談になるが abrowse コマンド 出力が、カテゴリ名、ブランチ名、バージョン名のような階層構造っぽ く表示されているのにだまされないでほしい。すでに言ったように、実 際にはこれらの間に強い階層構造はない。

tla abrowse コマンドの出力でも安心できない場合には、実際に アーカイブ中の base-0 リビジョンを今のプロジェクトツリーとは別の 場所に取り出してみればよい。これには以下のように tla get コマン ドを使う:

$ pwd
/home/octopus/proj
$ cd ..
$ ls
ARCHIVES  proj	tla-1.2  tla-1.2.tar.gz
$ tla get test--proj--1.0 hogehoge
* from pristine cache: octopus@bluegate.org--2004/test--proj--1.0--base-0
* making pristine copy
* tree version set octopus@bluegate.org--2004/test--proj--1.0
$ ls
ARCHIVES  hogehoge  proj  tla-1.2  tla-1.2.tar.gz
$ cd hogehoge
$ ls
cc.sh  hw  inc	lib  main.c  {arch}
$ 

ホームディレクトリに戻って、hogehoge というディレクトリに base-0 リビジョンを展開してみた。やはりうまくインポートできてい るようだ。でなければうまく取り出せるわけがない。納得できたら hogehogeを消しておこう。せっかく get コマンドが出てきたので少し 補足するが、get コマンドを最後の引数なしで実行してみよう。

$ pwd
/home/octopus/hogehoge
$ cd ..
$ ls
ARCHIVES  hogehoge  proj  tla-1.2  tla-1.2.tar.gz
$ rm -rf hogehoge
$ tla get test--proj--1.0
* from pristine cache: octopus@bluegate.org--2004/test--proj--1.0--base-0
* making pristine copy
* tree version set octopus@bluegate.org--2004/test--proj--1.0
$ ls
ARCHIVES  proj	test--proj--1.0--base-0  tla-1.2  tla-1.2.tar.gz
$ tla get test--proj--1.0
get: output directory already exists (/home/octopus/test--proj--1.0--base-0)
$ 

言いたいことはこうだ。展開先ディレクトリを指定しないと、 tla get は バージョンにリビジョン名をつなげたような名前のサブディ レクトリ—いまの場合だとtest--proj--1.0--base-0—を作っ てそこにリビジョン内容を展開すること、展開しようとするディレクト リがすでに存在する場合にはそれを上書きすることはないということ。 展開先ディレクトリは必ず新しく作成されなくてはならない、というこ と。確認したらディレクトリを消しておこう。

$ ls
ARCHIVES  proj	test--proj--1.0--base-0  tla-1.2  tla-1.2.tar.gz
$ rm -rf test--proj--1.0--base-0
$ ls
ARCHIVES  proj	tla-1.2  tla-1.2.tar.gz
$ 

もう信じてもいいだろう。我々は確かに base-0 という最初のリ ビジョンを手に入れたのだ。プロジェクトツリーとアーカイブの様子を 図で示すと以下のような感じになっている。

図 3.4. プロジェクトツリーとアーカイブ

プロジェクトツリー(今の場合 /home/octopus/proj)を削除して もアーカイブ中にできた base-0 は影響を受けないことに注意しよう。 プロジェクトツリーとは君が汗を流し、呻き、額を打ちつけ、格闘しつ づける、おがくずと鉄の切りくずが散らかる、油の匂が漂う泥くさい 「作業場」なのだ。あとで君のアーカイブからしみ一つない理路整然と したソースファイルを tla get で取り出した人間には、君のそんな姿 などおそらく想像もつかないだろう。だがそれでいいのだ。それが本当 の美学なのだから。

前節で最初のリビジョンをバージョン test--proj--1.0の中に作っ た。ここからはプロジェクトツリーに対して変更を加えてはコミットを発 行することで、リビジョンが増えていく。ここではリビジョンという言葉 について少し詳しく説明する。

バージョンはゼロ個以上のリビジョンを格納する場所で、アーカイ ブの中にある。バージョンにできる最初のリビジョンは base-0 という名 前になる。二つ目以降のリビジョン名は patch-n という形になる。ただ しn はコミットの順序を示す1から始まる整数である。^[12]

一度作成されたリビジョンは、修正されたり、削除されることはな い。リビジョンはバージョンの中にあり、バージョンはアーカイブの中に あり、アーカイブはその性質上既存データに対する修正はありえないので、 リビジョンを作成するのに利用したプロジェクトツリーを削除しても一度 コミットしたリビジョンは削除されることはない。リビジョンはバージョ ンの中で順序を持っている。つまり、コミットした時間の順序に一列に並 べることができる。リビジョンをこの順序に並べ、先頭のbase-0 を 0 番 目として数えていった番号のことをリビジョン番号と呼ぶ。リビジョン名 を指定すると、そのリビジョン番号がひとつ決まる。逆にリビジョン番号 を指定するとそれに対応したリビジョン名が求まる。この意味で両者を同 一視することができる。リビジョン名は、パッチレベルと呼ばれることが あるが、リビジョン番号を指す場合もあるのでどちらの意味で利用されて いるか文脈から判断する必要がある。リビジョン番号とリビジョン名の対 応は以下のようになる:

0    base-0
1    patch-1
2    patch-2
…

リビジョン名は文脈によって二つの異る意味をもつ。リビジョン名 は、そのリビジョンをコミットしたプロジェクトツリーの状態を示すと同 時に、直前のリビジョンとの間の差分であるすチェンジセットをも意味す る。その場合、このチェンジセットは直前のリビジョンといま問題になっ ているリビジョンの両方に対して等しく関係しているにもかかわらず、後 の方のリビジョン名によってこのチェンジセットを参照することに注意し なくてはならない。

ここでは日々の利用でよく遭遇する問題について説明する。良い質 問を補遺にある方法のどれかで私に送ってもらえれば、この節はより一般 的により豊富により洗練されたものとなっていくだろう。

tla changes コマンドの出力についての詳細な説明。パー ミッションが変わったときとかファイル名がかわったときとか。

外部インベントリタグを持ったファイルをファイルだけ 削除してしまった

この章は、ちょっと盛りだくさんだったかも知れないが、最初自分 が始めて GNU arch を使ったときにとまどったことなどをできるだけ思い 起こして一歩一歩書いてみた。(XXX) この中で一番重要なコマンドをあげ ろと言われたら、tla commit, tla changes, tla undo, tla redo, tla abrowse の5個だろうか。これだけ知っていれば、パンと水だけ与えられ た囚人程度には、なんとかやっていける。この中のコマンドでアーカイブ に対して書き込み処理をするのは tla commit だけであることに注意して ほしい。tla commit はアーカイブに対して書き込み処理を実行すること ができる GNU arch の数少ないコマンドの一つだ。

あるプロジェクトツリーをアーカイブバージョンの最初のリビジョ ンとしてインポートしたり、その後プロジェクトツリーに加えた変更点を 直前のリビジョンからの差分としてコミットしたりする時点で、GNU arch は常に前のリビジョンの内容と比較して、プロジェクトツリーに何が起き たかをスキャンする。プロジェクト中のあるファイルには変更が加えられ ているかも知れないし、新しいファイルが追加されたり既存のファイルが 削除されていたり、別のサブディレクトリに移動していたりすることもあ るだろう。GNU arch はプロジェクトツリー中のすべてのファイルを管理 対象にするわけではない。ある決まった規則にしたがっているファイルだ けをバージョン管理対象ファイルとみなす。あるファイルがGNU arch の 管理対象であるかどうかは、3種類のテストによって決められる。最初に ファイル名称がどんな形をしているかのチェック、二番目に、ファイルに 正しく「インベントリ」が振られているかのチェックだ。「インベントリ」 と「非認識」という言葉が説明なしに出てきたが、これについても順を追っ て説明していく。

二つのチェックは設定によってかなり自由に変更することができる。 設定は、主にプロジェクトツリーの{arch} 管理領域にある =tagging-method という定義ファイルの内容によって決まるが、それ以外 の情報も関係してくる。=tagging-method ファイルは tla init-tree コ マンドを発行してあるツリーを最初にプロジェクトツリーにした時点で、 このファイルの内容はデフォルト値に初期化される。

/*
    arch-tag: Tez Kamihira Fri Apr 16 16:15:11 JST 2004 (foo.c)
*/

#    arch-tag: Tez Kamihira Fri Apr 16 16:15:11 JST 2004 (foo.c)

{
     arch-tag: Tez Kamihira Fri Apr 16 16:15:11 JST 2004 (foo.c)
}

<!--
     arch-tag: Tez Kamihira Fri Apr 16 16:15:11 JST 2004 (foo.c)
-->

/*
    arch-tag: 9d3a97ec-dc74-445f-bcf0-234ebb054702
*/

前節での、インベントリに関するさまざまな概念を用いてファイル 分類のアルゴリズムの詳細を以下に述べる。繰り返しになるが、この節で の議論は、ファイル分類規則からくるトラブルにより import やcommit がうまく行かないような状況にないのであればぜひとも必要な知識という わけではない。私自身、今回このような形の文章を書くのでなければその 詳細を知ることはなかったと思う。

まず第一のチェックをする。ファイル名の形だけから、ファイルを 六つのどれかのタイプに分類する。分類の規則はファイルのあるディレク トリに .arch-inventory ファイルがあればその内容を、なければ {arch}/=tagging-method ファイルの内容を利用する。ただし ',,' で始 まるは常にジャンクファイルとみなし、'++'　で始まるファイルは常にプ レシャスファイルであるとみなす。非認識ファイルがひとつでもあれば、 その時点でエラーになる。

第一のチェックでソースファイルにマッチしたものについて、第二 のインベントリチェックをする。(XXX)。

...

プロジェクトツリー中のファイルがどのタイプに分類されるかを確 認するには tla inventory コマンドを使う。このコマンドは非常にたく さんの引数をとる

tla inventory の出力は、二つ以上のグループを表示させるように 指示した場合、S,P,B,J,T,U のいずれかの文字の後にオプションで '?' 文字がくる。'?' が表示された場合、名前のマッチング規則だけを考えた 場合にはソースに分類されたが、それ以外の理由で別のグループに分類さ れたことを示している。具体的には現在のIDタグづけの方法では認識しな い形式のインベントリidであったり、そもそもインベントリid が振られ ていないような場合である。文字の意味はそれぞれ、ソースファイル、プ レシャスファイル、バックアップファイル、ジャンクファイル、ツリー、 アンレコグナイズ(非認識)の意味である。その後に空白が一文字くる。-- kind オプションを指定した場合には、次に 'd', '>', 'r' のいずれ かが来る。それぞれディレクトリ、シンボリックリンク、通常ファイル、 の区別を表現している。最後にファイル名のプロジェクトツリーからの相 対パス名が表示される。--ids オプションが指定された場合にはこの後に インベントリid が表示される。インベントリid を持たないファイルの場 合は ??? が表示される。

--f オプションはディレクトリ以外のファイルについてのみ表示し、 ディレクトリは含まない。これがデフォルトである。--d を指定すると逆 にディレクトリのみを表示し、それ以外のファイルは表示しない。-b は 両方を表示する。この三つは高々一つしか指定できない。

--all オプションは {arch}管理領域の配下についても表示するが、 あまり利用されることはない。--explicit ... は、 {arch}/=tagging-method ファイルの内容によらず、指定のIDタグづけの 方法によってチェックを行うことを意味する。

--untagged オプションはタグづけされていないファイルも表示に 含める(多分これは触れないほうがいい。意味としては、ファイルパター ンはソースだが、それ以外の理由でアンレコグナイズとみなされたファイ ルを表示するというもの。しかし、untagged-source ディレクティブが =tagging-method に追加された今では、意味があいまいになりつつあるの では???XXX:)。

ファイルがディレクトリでかつ、その中に {arch} という名前のサ ブディレクトリがある場合、このディレクトリは別の独立した GNU arch 管理領域とみなされる。この場合そのディレクトリはツリー属性であると みなされ(複数グループ表示時には) T で表示される。T の配下は別の GNU arch 管理領域だが、T 自身は現在のプロジェクトツリーの一部であ ることに注意すること。tla inventory は T と認識したディレクトリの 内部は走査対象から除外する。

通常のファイルはファイル内部に arch-tag によってインベントリ タグを埋め込むことができるが、明らかにディレクトリに対してはこの手 法を使うことができない。このためディレクトリは外部タグをつけるか、 タグをつけないかのいずれかを選ぶしかない。通常ディレクトリには外部 タグを振らないことが多い。

--ids で表示されるインベントリid の意味の列挙。. /libarch/inv-ids.cの、file_id() の調査。

先頭が ? はファイル名によるタグづけであることを示している。 E_は .arch-ids 配下のファイル, D_ は .arch-ids ディレクトリ自身の インベントリidをそれぞれ示す。 A_ は {arch}管理下のファイル、明示 的なタグがある場合 x_ 、.arch-ids/=all によるデフォルトタグの場合 a_, 内部インベントリタグによる場合 i_, 内部インベントリタグが存在 しない場合に限って利用される弱いデフォルトタグの場合 w_, k_ (XXXよ くわからない)、?_ (XXX)。意味はわからないが、シンボルの一覧は以上 でおわりと考えられる。

tla tree-lint は本質的には tla inventory コマンドと同じロジッ クを使ってプロジェクトツリーを走査するがエラーメッセージがより詳細 化されている。以下のようなエラーメッセージがある。

この節では既に存在している比較的規模の大きなソースコードを新 たに GNU arch で管理し始める方法について検討する。GNU arch の実践 的な利用においては ID タグづけの方法として explicit または tagline のどちらかを選択するのが現実的だが、この場合インベントリの問題が顕 著に現れてくるため、そのままの形ではうまくインポートできないことが 多い。この節ではインポートまでの手順について説明する。前節の内容を 基本として理解できていれば一見奇妙に見えるエラーの内容も整理して理 解することができるはずだ。初期インポートさえ済んでしまえば、あとは 普通のアーカイブバージョンとなんら変わることはなくなる。第 3 章で 説明した操作や、5章で説明するすべての操作が可能となる。

なお既存プロジェクトがすでに他のバージョン管理システムで管理 されており、最新のソースだけではなくそのプロジェクトの履歴も含めて 移行するケースについてはここでは扱わない。移行元が CVS の場合につ いてはサードパーティー製のツールがある。詳しくは補遺を見てほしい。

この章では、プロジェクトツリー中の各ファイルを、GNU arch が それぞれどのような種類のファイルとして認識するかについて説明した。 ファイルには 6 っつの種類があり、プロジェクトツリー中のすべてのファ イルはこのどれかに分類され、この中のソースファイルのみがバージョン 管理の対象となった。ソースファイルはファイル名のマッチング規則の他 に、正しいインベントリid を持っている必要があった。ファイルのマッ チング規則とインベントリidの決定方法は主に=tagging-method ファイル によって決まった。非認識のファイルがひとつでもプロジェクトツリーに 残っていると import や commit 処理は失敗し、これが初期インポートの エラーの原因として考えられる大きな要因の一つであることを説明た。

次の章では、既存のバージョンの分岐を、自分のマシン上に作成す る方法と、分岐後で親のバージョンとの間とのデータ交換に必要なコマン ドについての説明をする。逆説的な話ですが、既存のバージョンからの分 岐は、新規のバージョンでのインポートに関するトラブルが一切ない。分 岐元のバージョンがすでにプロジェクトツリーを正しい状態に設定してい るためだ。

いつものように君はインターネット上にある面白そうなソフトウェ アを検索しているとする。で、お目当てのものが見つかった。それはフリー ソフトウェアで自由に使ってよいことがわかった。実際にいじってみるが 実に申し分のない動作をする。すばらしい。ただ、すばらしい機能拡張を 思い付いた。どうしてもこの機能を実装してみたい。作者にメールして、 いきなり一緒に開発してくれないかと切り出すのもおかしな話だ。なにせ この人とは会ったこともない。これからだって会う機会があるとは思えな い。なにせ彼はアルゼンチンに住んでいるのだ。これじゃ地球の裏側では ないか。

こんな状況で、彼がもし自分のプログラムを GNU arch の公開アー カイブ上のバージョンとして管理していたとすれば、君は実に運がいい。 彼になんのことわりもなく、一切彼のてをわずらわせることはなく、君の コンピュータ上に彼のプログラムのコピーを作ることができる。それもた だのコピーじゃない。このコピーは自分の由来を理解している。自分のご 先祖様が誰であったかを記憶しているのだ。いまどきそんな話、人間でも あまり聞かなくなった。今後、彼が彼のアーカイブバージョンに加えた修 正点を追加で君のアーカイブに取り込みながら、君は君で自分の機能拡張 作業を続けることができるのだ。このような用途のために君が自分のアー カイブ上に作ったバージョンを、彼のバージョンの「分岐」あるいは「ブ ランチ」と言う。君のブランチは、彼のバージョンととても良く似ている。 でもほんのちょっとだけ違っている。君は拡張モジュールを作っているか らだ。君のアイディアは良いものかも知れないし、そうでもないかも知れ ない。こういうことは普通、少しコーディングを続けてみないとはっきり しないことが多い。本質的に試行錯誤的な作業になることがおおい。一ヵ 月夢中でハックしてみて、やっぱりうまくいかなかったとあきらめること になるかも知れない。でもそれが何だろう? 別に彼に何かを頼んだわけで はない。黙って君がギブアップすれば良いだけのはなしだ。逆にアイディ アが身を結び、君の機能はとても汎用的で、彼自身にも、そしてそのソフ トウェアを使っている誰にとっても有益なものだと確信したとする。そん な時には彼にメールして、自分のアーカイブ位置を伝え、ちょっと面白い ものを作ったから、よければ取り込んでもらえないだろうかと頼む。彼が 気に入れば、これを取り込むことができる。これをマージと言う。マージ は彼の意志だけでやることができる行為だ。君には関係がない。君がする ことは自分のアーカイブをインターネット上に公開するだけだ。彼に対し て特殊な設定をする必要は何もない。

CVS のような集中型システムではこうはいかない。分岐は、親のリ ポジトリと同じリポジトリ内にしか作ることができないからだ。もし今問 題になっているプログラムが彼のマシン上の CVS で管理されていたとし よう。分岐を作ることができるのは君のマシンではなく、彼のマシンだ。 ということは、まずは君は彼のマシンに対するアクセス権限を得る必要が ある。これは君の仕事ではない。彼の仕事だ。しかしこれは実におかしな 話だ。これからハックしようとするのは君だ。彼じゃない。なのにそのこ とで彼に作業が発生するのだ。これはおかしい。考えてもみてほしい。一 度も会ったことのない男からある日突然メールが来て、あなたのプログラ ムの分岐を作りたいから、あなたのマシン上にアクセス権限をくれと言う。 そんな人間においそれとアクセスを許すことができるだろうか?

百歩譲って、アクセス権限をくれたとしよう。くれた方はどんな気 持だろうか。これだけのことを自分にしてくれたのだから、ぜひとも何ら かの成果を出さなくてはならない。もちろんそんな義務はないのだが、あ る日突然気が変わってギブアップというわけにはいかない。理由を彼に説 明して、自分はこれこれこういう理由で拡張できると思って始めたけれど、 うまくいかなかった、残念だ、という話をしなくてはならない。しなくて はならないわけじゃないが、良識のある人間ならそうするだろう。こんな ことをしなくてはならないと思うと、じつに憂鬱だ。どうなるか分からな いことを勝手に始めるのに、誰だって他人を巻き込みたくなんかないだろ う。で、結局良いアイディアがひらめいても、そこまでして分岐を作る気 にはならないだろう。これは重大な機会の損失だ。可能性は小さいかも知 れないがもし成功していたとすれば、君だけじゃない、そのソフトウェア を利用しているすべての人にとっての損失だ。君は私が何か多げさなこと を言っていると思うだろうか? 私はそうは思わない。

GNU arch ならこんな心配は何もしなくていい。君は勝手に始めら れる。そして勝手に辞められる。うまくいけば彼に伝える自由がある。も ちろんそうしない自由もある。彼は彼で君の申し出を受け入れる自由も拒 否する自由もある。誰も困らない。みんなトクをする。実際この仕組みで 損をする人がいるとしたらいったいそれは誰だろう。私に教えてほしい。

GNU arch で人のアーカイブバージョンの分岐を作るには特殊な設 定は何も要らない。まず、彼のアーカイブを登録する:

$ tla register-archive tez@kamihira.com--2004s \
      http://arch.bluegate.org/{archives}/tez@kamihira.com--2004s
$

分岐元のアーカイブバージョンを tez@kamihira.com--2004s/hello--world--1.0 とし、分岐先のバージョン を octopus@bluegate.org--2004/hello--world--1.1 として説明すると、まず 分岐先アーカイブバージョンを作成する:

$ tla archive-setup hello--world--1.1
…
$

そして tla tag コマンドで実際に分岐バージョンを作る:

$ tla tag tez@kamihira.com--2004s/hello--world--1.0 \
          octopus@bluegate.org--2004/hello--world--1.1
…
$

これで終りだ。本当にこれで全部なのだ。嘘じゃない。私を信じて ほしい。あとは君の hello--world--1.1 のプロジェクトツリー上で思う 存分ハックするだけだ。君がハックしている最中に、彼は彼で自分のリビ ジョンを進めることができる。こうして少しずつ君と彼のアーカイブバー ジョンはずれていく。彼とのずれをなくして同期させるには、君は彼の追 加修正分を時分のアーカイブバージョンに取り込まなくてはならない。こ れがマージだが、3節で詳しく説明する。分岐元のバージョンと、分岐先 のバージョンは明示的にマージコマンドを発行するまで独立に修正を加え ることができる。この間両者にはデータの授受は一切発生しない。たとえ ばGNU arch がバックグラウンドでお互いのバージョンから作ったプロジェ クトツリーに加えた変更点をリアルタイムに検出して、もう一方の関連し たリモートアーカイブバージョンに情報を転送したりすることはない。 GNU arch が実際データを交換するのは、XXX のマージコマンドのどれか を実行したときだけだ。だからどちらかのマシンがラップトップパソコン で、分岐後、マシンをネットワークから外して、喫茶店で作業を続けても もちろんなんの問題も発生しない。マージしたくなったときにネットワー クにつながっているだけで十分なのだ。

1節では人のアーカイブバージョンの分岐を自分のマシンに作る方 法を説明した。この便利さを本当に実感できたら、君だって他の人にこの 便利さを味わってほしいと思うだろう。これがアーカイブの公開と呼ばれ るものだ。こっちは少し設定が必要になる。公開用の通信方式はいくつか 選択することができて、現時点で GNU arch がサポートしている主な方式 は WebDAV と呼ばれる Apache のような httpd サーバを使う方法と、 sftp と呼ばれる sshd サーバを使う方法があり、それぞれ設定方法は違っ てくる。ここではこの 2 種類の設定方法について説明する。

<IfModule mod_dav.c>
DavLockDB /tmp/dav.lock

Alias /arch /home/foo/arch

<Location /arch/>
Dav On
</Location>
</IfModule>

もう一つの方法は sftp というプロトコルを利用することである。 sftp は WebDAVほど有名ではないが、実は ssh プロトコル上に実装され たものであるので、ssh がインストールされているシステムであれば通常 は特別な設定なしに常に利用することができる。WebDAV が自分のアーカ イブを広く不特定多数の人々に公開するのに対して、sftp は自分だけが 利用するインターネットにそれぞれ接続された複数のあるような状況で、 どのマシンからもそのアーカイブを参照できるようにしたいという意味あ いが強い。sftp は ssh 上で動作するので、ネットワーク上のデータは暗 号化されて流れるためだ。もちろん WebDAV を利用しても https を利用 すれば同じなのだが、http/https プロトコルは非常に一般的に利用され ているので攻撃の対象となりやすい。また設定の仕方を誤ることで https に限定した設定を http の設定と混同したりする可能性も高い。人が大勢 集まる野球場のすぐ横に国家の諜報活動機関用の建物を建てるようなもの だ。(XXX:)。sftp は ftp と名前が良く似ているが、ソフトウェア構成上 は何の関係もない。繰り返すが sftp は ssh パッケージの一部と考える ことができるので、あらかじめセキュリティーを確保することが容易なの だ。

sftp には、サーバ側での設定は何もいらない。単に sshd が起動 されていて、そのマシンがインターネットに接続されており、ssh と同じ 設定にしたがったパスワードまたは公開鍵を手にしていさえすれば、その まま利用できる。クライアント側では以下のように register-archive す るだけだ:

$ tla register-archive octopus@bluegate.org--2004 \
      sftp://arch.bluegate.org/home/foo/{archives}/octopus@bluegate.org--2004
$

tla abrowse で接続テストをしてみよう:

$ tla abrowse -A octopus@bluegate.org--2004
…
$

ssh の設定によって、パスワードなどを聞かれることがある。これ に正しく答えるか、公開鍵を使って自動的に接続できるように設定すれば よい。このあたりの設定は ssh の設定そのものであるので、詳しくは ssh のマニュアルなどを参考にしてほしい。

マージに関係したコマンドは大きく三つの種類にわけて考えること ができる。一つは実際のマージについての各種の情報を確認するコマンド、 もう一つは実際にマージを実行するためのコマンド、最後にマージに関す る記録を保持するパッチログと呼ばれるデータを管理するためのコマンド、 この三つだ。普通は第1と第3グループのコマンドの一部を実行して、もし マージしたとしたらどのような結果になるかをチェックし、その後実際の マージコマンドを発行する形になる。チェックコマンドはプロジェクトツ リーに対して書き込み処理はしないので気軽に実行できる。一方マージコ マンドもプロジェクトツリーには書き込みが発生するが、アーカイブには 手を触れないので、マージ後にプロジェクトツリーがどのように変形した かを確認することができる。確認の結果プロジェクトツリーが意図した形 に変形していれば、コミットすることになる。これで始めてリビジョンが 追加され、修正点がアーカイブに永続的に保存される。

プロジェクトツリーに実際に書き込むコマンドも二種類に分類でき る。ひとつは過去にマージされたチェンジセットがどれであるかを記録し たパッチログという情報を書き換えるもの、もう一つは実際のソースファ イルを変形させるものである。パッチログは重複したマージを回避するた めに GNU arch が利用する重要な情報だ。パッチログの情報を調整すると、 すでに一度適用したチェンジセットを適用しなかったことにしたり、逆に 適用したことのないチェンジセットを適用したとみなしたりすることがで きる。通常はこのような操作は不要だが、特殊な場面では役にたつ。XXX のコマンドリファレンスにはすべての GNU arch のコマンドに対してデー タの書き込みが発生するかどうか、発生するとすればどの領域に対してか を示した。これを見てこの章のコマンドをいろいろと試してみてほしい。

マージコマンドは用途や場面に応じてみっつある。

あるプロジェクトツリーを考える。プロジェクトツリーはいままで 自分自身に適用されてきたチェンジセットのログであるパッチログを記録 している。これらのパッチログの由来について、すこし詳しく考えてみよ う。

パッチログは大きくいって二つのことに由来する。ひとつはこのプ ロジェクトツリーをどこかのバージョンに — 通常はデフォルトバー ジョンに対してということになるが — コミットしたような場合で ある。この場合、そのコミットが作り出した新しいリビジョン名に対応し たパッチログがプロジェクトツリーに追加される。一方アーカイブの対応 バージョンには、一つ前のリビジョンと今回作り出されたリビジョンとの 間の差分であるチェンジセットが新しいリビジョン名で作られるが、この 中にもいま問題にしているパッチログが追加される。tla get でこの最新 リビジョンを get すると、いま作り出されたばかりのパッチログも一緒 にプロジェクトツリーに含まれることになる。

パッチログのもう一つの由来は、今回プロジェクトツリーがコミッ トしようとしているバージョン以外のバージョンからのチェンジセットを このプロジェクトバージョン中にマージすることに由来している。たとえ ば今、A/C--B--V--R にいて、これとは別のバージョン中のリビジョンで ある A1/C1--B1--V1--R1 をマージしたとする。これは直接 replay コマ ンドで選択的に取り込んだのかも知れないし、それを含むようなもっと総 括的なマージの一貫として取り込まれたのかも知れない。いずれにせよプ ロジェクトツリーには A1/C1--B1--V1--R1 のパッチログが追加される。 そしてこのパッチログは、A/C--B--V--(R+1) のコミットで作られるチェ ンジセットに記録され、チェンジセットはアーカイブバージョンに追加さ れるので、アーカイブ領域にも記録されることになる。

ここからは議論を簡単にするため、コミットするバージョンに関係 したA/C--B--V--R のようなリビジョン名を P と表すことにし、コミット バージョン以外のバージョンからのチェリーピックを p, q, r, ... と表 すことにする。P に含まれているのは、プロジェクトツリーに対するマー ジコマンドの適用による、p, q, r, ... のパッチログと、自分自身のパッ チログだ。一方 チェンジセットとしての P の実際の内容は、p, q, r,.. の実際の内容と、P 自身の修正内容になる。マージコマンドだけを実行し たのであればこれは空だが、エディタなどで直接プロジェクトツリーのファ イルを修正した場合には空ではない。だから P = P + p + q + r ... となる(XXX: ひどい説明だ!)。

ものごとには順序に関係したことと関係しないことがあることの例

ここでの問題は、P に適用された P, p, q, r,... の順序が不明だ ということ、また P はアトミックではないということだ。たとえば foo.txt の先頭の方にある行を追加し、p, q, r を適用し、その後 この三つのチェンジセットで追加された行の一部を削除したような場合を 考えると、P という内容がはっきりしなくなってしまう。

問題は他にもある。たとえば p を適用した後、その適用を完全に 取り消すような修正をプロジェクトツリーに手で加えてからコミットすれ ば、パッチログには p が適用されたという情報が残るにもかかわらず、 実質的に p は適用されていない。

まだある。p, q, r の適用順序をパッチログは示していない。p, q, r の順序で適用されたのかも知れないし、q, r, p だったのかも知れ ない。チェンジセットの代数は一般的にはアーベル的ではないので、両者 の結果は異なったものになることもあるのだ。

結論として、パッチログはパッチ適用の履歴についての完全な記述 ではないということになる。これはせいぜいあるチェンジセットがすでに 適用されているかどうかの目安にすぎない。だから場合によってはパッチ ログを操作して、まだ適用されていないチェンジセットがあたかも適用さ れていたり、実際にはすでに適用されたかチェンジセットがあたかもまだ 適用されていないかのようにプロジェクトツリーを「だます」必要がある。 こんな事態は頻繁におこるわけではないが、時には必要になる。GNU arch はもちろんこんな場合にそなえていくつかのコマンドを用意している。 tla add-log-version, tla remove-log-version, がそれである。

パッチログエントリを追加・削除するコマンドは存在し ないのか? またこれは現実の場面では不要なのか?

マージの失敗はプロジェクトツリーにのみ関係しているので大きな 問題にはならないことの説明。元に戻すための操作についての説明。

ひとつのバージョンに対して新しいリビジョンをコミットするたび、 バージョンの中にはそのリビジョンを直前のリビジョンから作り上げるの に必要なチェンジセットが蓄積されていく。tla get などのコマンドで最 新リビジョンを取得する場合、リビジョンが大きい程長い時間がかかるが、 これはベースリビジョンに対して適用しなくてはならないチェンジセット の個数がリビジョンの数に比例して大きくなっていくからだ。tla get が 表示するメッセージを見てもこれは明らかだろう。

$ tla get C--B--1.0
* from import revision: octopus@bluegate.org--2004/C--B--1.0--base-0
* patching for revision: octopus@bluegate.org--2004/C--B--1.0--patch-1
…
* patching for revision: octopus@bluegate.org--2004/C--B--1.0--patch-238
* patching for revision: octopus@bluegate.org--2004/C--B--1.0--patch-239
* making pristine copy
* tree version set octopus@bluegate.org--2004/C--B--1.0
$

patching for revision: で始まる行が直前のリビジョンに対して 次のチェンジセットを内部的に適用していることを示す行だが、これはも ちろんリビジョンが上がっていくにつれて増える。リビジョンを一から計 算しないで適当なリビジョン間隔でキャッシュしておけばリビジョンの取 得は早くなる。これをリビジョンキャッシュと言う。たとえば patch-50 patch-100, patch-150, patch-200 のリビジョンのキャッシュを保持して いれば、たとえば patch-239 を取得する場合には patch-200 からの計算 だけを考えれば良いことになるからだ。リビジョンキャッシュを作るには tla cacherev コマンドを使う。このコマンドはあるリビジョンの内容を tla get と同じアルゴリズムで計算し、アーカイブ中の、本来チェンジセッ トしか保持していないリビジョンの、リビジョンの内容全体を保存する。

あるバージョンが、別のバージョンからの継続として作られた場合 ベースリビジョンをキャッシュするのは広く行なわれる最適化だ。こうし ないと継続先のリビジョンを tla get しようとすると、継続元のバージョ ンにまで遡ってリビジョンを構築することになってしまう。継続元がネッ トワークをまたいだ別マシン上にある場合にはこの違いはより顕著になる のは明らかだ。

あるリビジョンに対するリビジョンキャッシュは、バージョン中の チェンジセットのサイズがごく小さいものだと仮定すれば、大体ベースリビジョ ンと同じ程度の領域を食うので、たくさんのリビジョンについてキャッシュ するのはあまり得策ではない。こんな場合にはリビジョンライブラリを構 築する方が良い結果が得られるだろう。

アーカイブ・ミラーは、あるアーカイブを別のアーカイブにそっく りそのままコピーしたものだ。GNU arch のアーカイブはネットワーク透 過性を持っていることを思い出してほしい。つまり同じマシンの上にある 二つのアーカイブ間でできることは、異るマシン間にあるアーカイブに対 しても必ずできる、という GNU arch の設計上の大原則だ。この性質を利 用すれば、アーカイブ・ミラーのソースとディスティネーションを別マシ ンに設定して、たとえばソースをリモートアーカイブ、ディスティネーショ ンをローカルアーカイブとすることも、その逆も、また両方を同じマシン 上の異るアーカイブとすることもできる。最初の場合はリモートアーカイ ブからローカルアーカイブへのコピーとなる。二番目はその逆になる。最 後のケースは何の役にたつか不思議に思うかも知れないが、たとえば一方 のアーカイブは外部に公開していない、プライベートなもので、もう一方 は公開しているアーカイブだとする。そして普通はプライベートアー カイブ上のバージョンで作業をしていて、問題がないと確信した時点でそ の内容を公開アーカイブにも反映したいような場合、ローカルアーカイブ 間のミラーも意味をもつ。

ミラー先のアーカイブには自分がミラーであることを示す情報があっ て、tla import や tla commit を実行しようとするとエラーになる。tla archive-mirror コマンドを利用する以外に、ミラーアーカイブに書き込 みを行なうことはできない。

まず、いままで直接アクセスしていたリモートアーカイブのミラー をローカルに作り、このミラーにリモートアーカイブの内容を実際にミラー したあと、このミラーにアクセスする例を示す。実際のミラーには非常に 時間がかかることもあるが、いったん転送が済んでしまえば、アクセスは 飛躍的早くなるのが普通だ。Tom Lord のマスターアーカイブを使って説 明しよう。まず、Tom のアーカイブに直接アクセスするような形にアーカ イブを登録する。それから tla abrowse でこのアーカイブを閲覧してみ てほしい。かなり時間がかかるはずだ:

$ tla register-archive lord@emf.net--2004 \
      http://regexps.srparish.net/{archives}/lord@emf.net--2004
$ tla abrowse -A lord@emf.net--2004
…
$

次にローカルマシンにミラーを作るわけだが、tla make-archive コマンドを実行する前にアーカイブ名について少し考える必要がある。ミ ラーアーカイブに何という名前をつけるか、だ。lord@emf.net--2004 と いう名前はすでに Tom のマスターアーカイブとしてたったいま利用して しまっているので、同じ名前をミラーに対して利用することはできない。 普通はアーカイブ名の後ろに "-MIRROR" という文字列をつけた lord@emf.net--2004-MIRRORという名前を使うが、必ずそうしなくてはな らないという決まりはない。アーカイブ名の形式に従ったものならどんな 名前をつけても良い。で、考えてみてほしいのだが、今後このミラーには 頻繁にアクセスすることになり、あたかもこちらが Tom のマスターアー カイブだとみなしたほうが都合が良いだろう。こっちを lord@emf.net--2004 という名前でアクセスしたい。すると今度は Tom の オリジナルの方を別の名前で呼ぶ必要が出てくる。これももちろん可能だ。 あるアーカイブ位置をどんな名前で呼んでも GNU arch が動かなくなるこ とはない。結局、Tom のオリジナルを lord@emf.net--2004-SOURCE と呼 び、ローカルミラーをlord@emf.net--2004 と呼ぶことにする。

$ tla register-archive -d lord@emf.net--2004
$ tla register-archive lord@emf.net--2004-SOURCE \
      http://regexps.srparish.net/{archives}/lord@emf.net--2004
$ tla make-archive --mirror lord@emf.net--2004-SOURCE lord@emf.net--2004 
      /home/foo/{archives}/lord@emf.net--2004
$

tla make-archive の前に、tla register-archive で lord@emf.net--2004 の削除と、同じアーカイブ位置を lord@emf.net--2004-SOURCEという名前であらためて登録していることに 注意してほしい。それからミラーアーカイブを tla make-archive で作成 している。tla make-archive コマンドは内部的に tla register-archive の処理も一緒に行なうので、lord@emf.net--2004 はローカルミラーとし て登録される。次に実際にアーカイブの転送を行なう:

$ tla archive-mirror lord@emf.net--2004-SOURCE lord@emf.net--2004
…
$

これにはアーカイブの大きさにおうじて、通常は長い時間がかかる。 何か別のことをやっていた方がよいだろう。ミラーが完了したらもう一度 tla abrowse を走らせてみよう:

$ tla abrowse -A lord@emf.net--2004
…
$

おそらく劇的に早くなっているはずだ。いったんミラーをつくれば、 今後の tla archive-mirror は差分だけの転送になるのでそれほど時間は かからなくなる。この処理は cron でやらせるのがおすすめだ。私はもち ろん Tom のすべてのアーカイブを自分のマシンにミラーしているが、一 日一回ミラーするようにしている。これで Tom のマシンに何か恐ろしい ことが起こっても、私のミラーを使って最悪 24 時間前の状態にまでは戻 せる。分散システムならではのメリットだ。GNU arch コミュニティーに はこのようなバックアップ的な意味あいでのミラーを、もっと大規模に構 築しているメンバーもいる。詳しくはXXXを見てほしい。

ミラーの話しに限ったことではないが、あるアーカイブから別のアー カイブに対する継続がある場合、最低限、継続のリビジョンでは tla cacherev コマンドでキャッシュしたほうが良い。そうしないと、せっか くあるアーカイブをミラーしても、そこからリビジョンを get しようと すると、継続をさかのぼって結局は別のアーカイブも参照しにいくことに なり、そのアーカイブが登録されていないことでエラーになったり、登録 されていてもスピードの恩恵にあずかることができないことになってしま う。これはミラーされる側のエチケットかも知れない。もちろん誰も彼に そんなことを強要することはできないが。人はみな、自由なのだ。

もうひとつの例は、公開用アーカイブと、ブライベートアーカイブ とのミラーだ。XXX

ミラーの特徴は、ユーザが自発的にミラーする必要があることだ。 tla archive-mirror コマンドを時々実行しなければミラーの意味はない。 これにたいして次節のリビジョンライブラリは、ユーザが通常の操作を行 なう過程で自然とキャッシュされていような仕組みを持っている。ここが 違うところだ。用途や場面に応じて、どの方法が最適か、自分で考えてみ てほしい。

最後の方法がリビジョンライブラリだ。まず最初に断っておくが、 リビジョンライブラリは、通常のコンピュータ言語での開発で利用するラ イブラリとは何の関係もないので注意してほしい。リビジョンライブラリ は大雑把にいって、アーカイブバージョン中のすべてのリビジョンを完全 な形ですべて保持してしまおうという考え方だ。ある意味非常に露骨でもっ とも単純で、それゆえ強力な方法だとも言える。すべてのリビジョンを展 開した形で持つわけだから、莫大なディスク容量が必要に思えるが、リビ ジョン間で変更のないファイルについては unix のハードリンクの考え方 を使い、一つの実体としてのファイルを複数の場所から指し示すことによっ て空間を節約する仕組みを持っている。もちろんこれは内部的な実装の話 なので利用者から見ると、巨大なリビジョン群がそのままそこに存在し、 その割にはディスクが消費していないような状況になる。あるリビジョン から次のリビジョンへの修正は通常それほど多くのファイルで起こるわけ ではないので、空間の最適化はかなり良い結果をもたらすことが多い。

リビジョンライブラリは、自分が必要だと思うリビジョンを明示的 に指定して生成することもできるし、ある処理において副次的にリビジョ ンを計算しなくてはならない時に、暗黙にそのリビジョンをライブラリに 常に追加するように設定することもできる。後者に設定しておけばいちい ち tla library-add コマンドを発行しなくても、いろいろなアーカイブ バージョンをいじっているうちに自然とパフォーマンスが向上していくよ うな結果をもたらすはずだ。欠点としては自分があまり意識しないうちに ディスク容量が消費されていくことだろう。

暗黙にリビジョンライブラリの内容を豊富にしていくのと同時にディ スク容量もそれほど消費させたくない場合、折衷案をとることもできる。 このためにもう一つ設定することのできるパラメータがある。この sparseを設定すると、あるリビジョンをライブラリに追加する際、そのリ ビジョンを作成するに当たってできた中間のリビジョンについてはライブ ラリに登録しない。

ライブラリを扱うコマンドはいろいろと存在するが、例によってカテゴリ・ブ ランチ・バージョンの 3 階層システムからくる複雑さであり、基本的に は設定、追加、内容表示、の 3 っつの種類しかない。

すでに見てきたように、GNU arch はさまざまなキャッシュを持っ ていて、ある特定のリビジョンを取得する場合、可能であれば本来のアー カイブの場所から取得するかわりに、より時間的なコストが安い場所から 取得しようとする。ではそのような場所が複数あった場合にはどうするの だろうか? リビジョンの検索順序は以下のようになる:

リビジョンライブラリは複数の場所に保持することが可能で、この 場合にはリビジョンライブラリ自身の検索順序で検索される。プリスティ ンコピーを利用するのは tla get コマンドのオプションで明示的にパス を指定するような特殊な場合に限られる。最後にアーカイブを利用する場 合、アーカイブ中でそのリビジョンがキャッシュされていれば、それを直 接展開する。そうでなければ、最後のキャッシュリビジョン、またはイン ポート時の初期リビジョンを取得した後に、そのツリーに対して順次次の チェンジセットを適用して必要なリビジョンを求める。この最後の場合に は大雑把に言ってリビジョンの数に比例した時間がかかることになる。

アーカイブミラーの話が出てこなかったのは、tla get オペレーショ ンにおいてはミラーと通常のアーカイブを区別することはないからだ。ミ ラーハキャッシュの検索順序の議論よりも 1 レイアー低い場所でキャッ シュするしくみだと言うことができる。

初期インポート時に、正体不明のエラーが表示されてどうしてもうまく行 かないことがある。これはたいていの場合、インポート対象としたいファ イルがうまく認識されていないか、ディレクトリ中に認識できないファイ ルが残っている場合だ。GNU arch はインポート時にもコミット時にも、 プロジェクトツリー全体をスキャンして、自分が認識できないファイルが 存在しないかどうかを確認する。どのようなファイルを認識できないもの にするかは、設定によってプロジェクトツリーごとにユーザが自由に設定 できるのだが、結果として認識できないファイルがディレクトリに残って いるとエラーを表示してコミットやインポートを中断する。これは、きち んと把握しているファイルのみがプロジェクトツリーには現れるべきだと いう GNU arch の思想を反映している。ただしこれには例外があって認識 できないファイルがあったとしても、それを認識できるファイルとみなす ように設定することもできるのだ。また認識できないケースにも二通りあっ て、ファイル名の形からくる場合と、インベントリidが正しく振られてい るかどうかからくる場合もある。また認識できるファイルは、諸事情でさ らにいろいろなファイルタイプに分類されているし、インベントリid 自 身の概念が通常のバージョン管理システムでは存在しないものであること などが理由で、ファイルタイプの認識ロジックは非常に複雑なものになっ ている。

ここでは GNU arch のファイル判別ロジックの詳細を説明する。もし初期 インポートにすでに成功していたり、分岐によってプロジェクトを始めた のであれば、すぐにこの章を読む必要はないと思う。しかし、新しいファ イルをプロジェクトに追加したとたんにコミットができなくなった、とか、 初期インポートがどうしてもうまくいかずエラーになる、という場合には、 この章を読んで、GNU arch のファイル判別ロジックについて少し詳しく 考える必要があるかも知れない。根底にある理屈がわかってしまえば、た いていのエラーは解消すると思う。一点だけ注意だが、GNU arch の場合、 新しいファイルをプロジェクトに追加する場合、CVS など他のバージョン 管理システムにあるような明示的なファイル追加コマンドは存在しない。 インポートまたはコミット時のファイルスキャンで規則に合致すればそれ は追加されたファイルになるし、合致しなければそうはならない。そして 運悪くそれが認識不能ファイルに最終的に分類されればインポートやコミッ ト自体が中断されてしまう。それだけの話だ。

ところで、私は語学が苦手だ。たとえば英語。わけのわからない規則が多 すぎる。want の過去形は wanted だからということで、go の過去は goed だというと笑われる。一個と二個以上を区別するくせに、二個と三 個は区別しない。三人称単数現在に限って動詞の最後に s をつける。で 得意になって studys なんてやるとまたバカにされる。ラテン語なんて最 悪だ。名詞には6っつも格があって、おまけに性がある。海がどうして女 性名詞なのか教えてほしい。人魚が住んでるからだろうか? でも海坊主だっ てちゃんと住んでる。「バラ」は女なのに、「花」は男だと言う。わけが わからない。結局、こういうのは丸暗記するしかないのだ。

GNU arch にもよく似たところがある。もちろん、作者はご存命だし、も う少しは合理的にできているし、ほりさげていけば、いちいちちゃんとし た理由もあるのだろう。でも、悪いことは言わない。最初はあまり深く考 えないほうがいい。そういうものなんだと割り切ろう。

ルールその1: 　　GNU arch はファイルを以下の xxx 種類にとりあえず分類するという約束がある。 　　これを一次分類と呼ぶ。 ルールその2: 　　一次分類は、ファイル名の形だけをもとにして分類される。 ルールその3: 　　一次分類でソースと見なされたファイルはインベントリidの存在/非存在 　　によってさらにソースかどうかを判断されるこれを二次分類という。 　　二次分類でソースでないことがわかったファイルは、とりあえず非認識とされる。 ルールその4:

この結果、最終的にファイルが非認識とみなされれば、インポートやコミッ トは中断される。これを防ぐには、ファイルタイプをソースとなるように =tagging-method を書き換えてから、必要に応じてインベントリidをこの ファイルにつける。つける方法は・・・・ファイルの個数が多い場合、こ れを手でやるのは大変だ。たとえばすでに別のバージョン管理システムで 管理していたファイルを GNU arch に移行したいような場合だ。ありがた いことに自動的にインベントリidを振ってくれるツールを作成している人 たちもいる。詳しくは・・・を見て欲しい。インベントリid については 次の節で詳しく説明しようと思う。GNU arch にしか現れない重要な概念 の一つだ。

ここでの議論は退屈で、見通しがわるく、しかも運が悪いと、GNU arch の使い始めから理解しなくてはならない場所になってしまう。それほど unix に詳しくない人なら、多分ここでさようなら、だろう。このシャー プな学習曲線を緩くするうまい方法は見つけることは、GNU archにとって 急務だと考えている。

インベントリとは、一言で言うと「バージョン管理下にあるそれぞ れのファイルの由来を示す識別子の一覧」のことだ。あるファイルが GNU arch 管理下に置かれるには次の二つのどちらかのケースしかない。一つ は、新しいバージョンをアーカイブにインポートする時にインポート対象 になっている場合。もう一つは、すでに存在しているリビジョンから分岐 したバージョンを作った場合だ。最初の場合には GNU arch システムから 見た時にはそのファイルは新規に導入されたので、新しい識別子が必要に なる。後の場合にはすでにあるファイルと由来を同じくするファイルがで きたので、識別子は分岐元のファイルと同一のものになる。分岐した後、 一般には両方のバージョンで、二つのファイルは独立に変更されていくだ ろう。その独立した二つのファイルには同じインベントリidが振られてい るので、ファイルの自己同一性を示すというよりは、ファイルの由来の同 一性を示す識別子である、と理解するのが正しいだろう。

インベントリの考え方自体は非常に単純なものだ。インベントリ の問題を複雑にしているのは、既存の Unix 系ファイルシステム上でイン ベントリを実装しようとするのが難しいことと、GNU arch のファイル分 類機構と一部干渉する部分があるからだ。GNU arch の初期インポート に失敗する場合、ファイル分類機構がエラーを出している場合と、インベ ントリの仕組みがエラーを出している場合がありこの判別が難しいのだ。 本来、ファイル分類機構はインベントリとは何の関係もない話だが、あ えてこの節で一緒にとりあげることで、初期インポート時のトラブルへの 対処方法を示したいと思う。初期インポートという、一番最初の操作 でつまづく可能性があるのは GNU arch の普及をさまたげる大きな原因の 一つになりかねないのは残念なことだ。

第1章の議論を思い出してほしい。私はバージョン管理手法の最も 原始的な形態としてのバックアップを取り上げ、それからテキストファイ ルに対する差分管理について述べた。バックアップをとるかわりにファイ ルの差分をつぎつぎと保存していけば十分であるという議論だった。チェ ンジセットはこのひとつのファイルに対する差分を、ディレクトリツリー 全体に対する差分へと拡張したものだ。だからチェンジセットのことをパッ チと呼ぶ人もいる。ちょっと考えると、これはわざわざ鳴り物入りで言う ほどのことではないような気もする。ファイルが N 個あるのなら、ファ イルごとに管理した N 個の独立した差分を考えれば十分ではないか、と。 GNUdiff を使ったことのある人なら、-r オプションつきで実行すれば、N 個の独立した差分を一つのファイルとして表現することすらできると思う かも知れない。しかしここに罠がある。

まず、パッチファイルには、ファイルの生成、消滅を厳密に扱う方 法がない。GNUdiff を使って同等のことを表現しようとすると、ファイル の生成は、ゼロバイトのファイルと、生成後のファイルの差分を作る形で 表すしかないし、消滅の場合には、消滅前のファイルの内容と、ゼロバイ トのファイルのファイルの差分を計算する形で表すより他ない。-N とい うオプションはこれを実行してくれる。しかしこれでは、その時点でファ イルが生成されたことと、実はゼロバイトで存在していたことを区別する ことができない。消滅の場合も話しが逆になるだけで同様である。

次に、パッチファイルはファイルのパーミッションの変化について 記録する方法がない。あるシェルスクリプト foo.sh に、うっかり実行権 限をつけるのを忘れたとする。あるリビジョンで内容には一切変更を加え ず chmod +x foo.sh のようなことをやって実行ビットを立てたとする。 パッチファイルにはこのような変化を記録する方法がないのだ。他にもま だある。ファイル名称の変更だ。あるファイル、./foo.h を、./include/foo.h に移動したとする。パッチファイルではこれを表現できない。あるファイ ル ./foo.h がある日突然ゼロバイトになり、./include/foo.h というゼ ロバイトのファイルが、突然 ./foo.h の内容になったようにしか表現で きない。これは都合がわるい。すでに述べたように、我々はファイル名の 変更を追うための強力なしくみ、インベントリを手にしているのだ。これ を生かさない手はない。しかしパッチファイルにはそれができない。

そんなこんなで、パッチの拡張であるチェンジセットのデータ構造 が厳密に定義された。チェンジセットはパッチが一つのファイルであるの に対して決まった名前のファイルと構造をもつディレクトリとして定義さ れる。これはチェンジセットを扱う GNU arch の内部ロジック、 dopatch()/mkpatch()が、このデータ構造中でランダムアクセス処理が発 生するためだ。パッチファイルはただのファイルなのでもちろんバイト列 が並んだシリアル形式のデータ構造だ。だからランダムアクセスには向か ない。しかし、これは単なる実装上の問題でしかない。チェンジセットが ディレクトリであることには本質的な意味は何も無い。

チェンジセットの厳密なデータ構造は補遺に示した。興味のある方 はご覧いただきたい。

プロジェクトツリーが他のバージョンからのチェンジセットを適用 すると、「そのチェンジセットはもう取り込んだ」という意味のログが、 {arch}管理配下に記録される。これをパッチログと言う。パッチログは通 常のファイルで、中には RFC822形式に準じたいくつかの情報があり、人 間への手がかりとなるが、GNU arch がシステム的に考慮するのは「パッ チログが存在するか、否か」だけだ。つまり管理領域に A/C--B--V--R が 存在すればこのチェンジセットはすでに受け取っているのであり、存在し なければ受け取ってはいない。それだけだ。プロジェクトツリーをコミッ トすると、パッチログはアーカイブバージョン中のチェンジセットにも記 録され、永続的なものとなる。

GNU arch のマージコマンドは常に、マージするチェンジセットが すでにパッチログとして記録されているチェンジセットと一致しないかど うかを確認し、パッチログが存在しない場合に限りそれを適用する。これ によって同じチェンジセットを二度以上適用してしまう、いわゆる重複マー ジの問題を回避することができる。

パッチログはチェンジセットにも含まれるが、その当のチェンジセッ トに対応したパッチログだけではなく、そのチェンジセットが間接的に受 け取ったパッチログも含んでいる。たとえば C1--B1--V1--R1 というリビ ジョンで、Cx--Bx--Vx--Rx と、Cy--By--Vy--Ry という 二つのパッチログを受け取り、C1--B1--V1--R1+1 というリビジョンをコ ミットしたとしよう。するとチェンジセット C1--B1--V1--R1+1 には、 この三つのチェンジセットに対応したパッチログがすべて含まれる。 このチェンジセット C1--B1--V1--R1+1 を受け取った Cz--Bz--Vz--Rz+1 には、自分自身もふくめて四つのパッチログをプロジェクトツリーに追加 することになる。このようなパッチログの授受の連鎖によって、一度適用 したチェンジセットを、もう一度同じバージョンから受け取ることを回避 できるだけではなく、めぐりめぐって別のバージョンから受け取ることも 回避できる。

どんなバージョン管理システムにも共通の、当たり前の原則がある。 それは過去に現れたデータは決して削除されない、というものだ。データ を削除する、とは、削除された形の新しいリビジョンを「追加」する、と いうことでしかない。過去は消せない。髪を黒く戻して、ピアスを外して タバコを辞めても、タイムマシンに乗ればバレてしまう。

アーカイブ中で、リビジョンがコミットされるにつれ、データは増 えていく。過去のデータは古くなるにつれ、監査や考古学的な興味を除け ば、その価値は薄れていく。もし、新たらしい部分のリビジョンを取得す るのに過去のリビジョンに強く依存しているとすると、これは問題がある。 たとえばディスク障害が起こって、非常に古いリビジョンのほんの一部が わずかに壊れてしまったとしよう。これが理由で、アーカイブ中のすべて のリビジョンのデータが全滅したとすれば、それはまずい。腐ったリンゴ を簡単に捨てちゃいけない。腐った部分だけ捨てて、腐ってないところを おいしくいただきたい。

GNU arch はちゃんとこのへんの事情を心得ていて、あるアーカイ ブバージョンのリビジョンが増えたら、別のバージョンに乗り移ることが できる。これを継続という。私は何か新しいことを書いているようだが、 実はこれは tla tag コマンドで分岐を作る行為そのものだ。だから分岐 には実は二通りの、すこし異なるニュアンスがあることがわかる。一つは 幹の開発をさまたげずに自分独自の修正を加えるための分岐。もう一つは リビジョンが大きくなりすぎたのでアーカイブバージョンをここらで新し くしたいと思って始める分岐。つまり継続。継続を作ったら、そのベース リビジョンはキャッシュしておくことを強く勧める。これで過去の分岐元 のバージョンが腐っても、継続後のバージョンは被害を受けることはない。

継続バージョンを作ると、継続後のバージョンは自分の継続した祖 先のバージョンを記憶している。tla ancestry コマンドはこの情報を元 にしてあるバージョンの祖先をずっとたどってくれる。しかし逆はだめだ。 あるバージョンの親は、自分にどのような子がいるか知らない。子供を列 挙する方法はないのだ。無理にやろうとすれば、たとえばあるアーカイブ 中をしらみつぶしに検索することになるだろう。これは現実的ではない。 それに特定のアーカイブ中でしかこれはできない。しかし地球上には無数 のアーカイブがあるのだ。この非対称性は、親に黙って分岐を作ることが できる、という GNU arch の性質に対応している。もし親が子の情報をも つとすれば、黙って分岐を作ることができなくなるだろうが、それじゃブ ルーな世界に逆戻りだ。

アーカイブには署名することができて、この機能を有効にするかど うかはアーカイブごとに選択することができるが、サインするしないにか かわらず、アーカイブに新しいデータが追加される時にはかならすその追 加データに対するチェックサムが計算され、独立したファイルとして同時 に保存される。アーカイブに対する追加は以下のどれかのコマンドでしか 発生しない。つまり、import, commit, tag, cacherev である。 ^[16] 追加データが正しい内容であるかどうかは追加データのチェックサムをも う一度計算し、チェックサムファイルの値と一致するかどうかを確認する ことで検証することができる。ディスクの低レベルエラーや、作為的でな いデータ検証はこれでおこなうことができる。

チェックサムの計算だけでは、作為的な悪意のある改懺からデータ を守ることはできない。チェックサムを計算する元データを変更して、そ れに対するチェックサムを計算し、元のファイルとそれぞれ置き換えれば チェックサムの妥当性検証をすり抜けることができる。これを防ぐために はアーカイブをサインつきとして設定する必要がある。サインつきアーカ イブのアイディアは非常に単純である。前節で説明したチェックサムファ イルに対してなんらかの暗号方式で署名するだけである。これで追加デー タを別の悪いあるもので置き換えたあとチェックサムを計算することはで きても、そのチェックサムに正しい署名をすることは本人にしかできない ので結果的にデータの改懺は不可能になる。

サインつきアーカイブを作るには、tla make-archive で --sign オプションをつけて作成するだけでよい。これはアーカイブをとにかくサ インつきとすることを指示するだけであって、具体的にどのような暗号方 式を利用するかを決めるものではない。具体的なサインの仕方は、

~/.arch-params/signing/アーカイブ名

というファイルに実際のサインの仕方を示す単一のシェルコマンド を指定する。典型的には、たとえば octopus@bluegate.org--2004 をサインつ きアーカイブとして作成したあと

~/.arch-params/signing/octopus@bluegate.org--2004

という通常のファイルを作り、その中に

gpg --clearsign

のように書く。gpg は GnuPG と呼ばれる pgp の実装である。gpg そのものの説明や設定方法はこのドキュメントの範囲を越えている。

http://www.gnupg.org/

のページなどを参考にしてほしい。主要な unix 系 os であれば パッケージに含まれていることが多いのでインストールは容易だと考えら れる。

指定するプログラムは標準入力からチェックサムファイルの内容を 受け取り、標準出力に対してサインした結果を返すような任意のプログラ ムを設定することができる。たとえば上の例では、gpg プログラムはパス フレーズと呼ばれるパスワードを起動のつど対話的に聞いてくる。つまり import, commit, tag, cacherev のようなコマンドを実行するたびにパス ワードを入力しなくてはならない。これは頻繁にコミットするような環境 では不便なので、パスワードをキャッシュするようなプログラムもある。 たとえば agpg と呼ばれるようなプログラムは一度だけパスフレーズを入 力するとそれ以降はメモリ中にその内容をキャッシュしておいてくれるも のだ。このようなプログラムを使う場合には、

~/.arch-params/signing/octopus@bluegate.org--2004

という通常のファイルの内容は

gpg --clearsign

のかわりに

agpg --clearsign

のような設定になる。こちらについても詳しい説明は agpg のサイ トを参照してほしい。

前節はサインつきアーカイブの作成方法と、それに対する具体的な サイン方式の設定についての方法だったが、逆にサインつきアーカイブか ら取得したデータの妥当性の検証方法の設定の仕方について説明する。こ ちらのほうは

~/.arch-params/signing/octopus@bluegate.org--2004.check

のような通常ファイル、つまりチェック方法を設定したいアーカイ ブ名の後に .check の拡張子をつけたファイルに、チェック方法を示すシェ ルコマンドを記述することでおこなう。典型的には

gpg --verify-files -

こちらについても、標準入力からテキストを入力し、その結果をス テータスで返すようなプログラムであれば何でもよい。しかし現時点では 上記のようなコマンドを設定するのがほとんど唯一の現実的な利用方法で あると考えられる。

サインつきアーカイブの数が増えてくると、いちいち前節や前々節 の方法ですべてのサインつきアーカイブの設定をするのは大変である。特 に指定していないアーカイブについてのデフォルトルールが設定できると 便利だ。これには、実際のサイン、その検証それぞれのシェルスクリプト を

サインのルールのデフォルト
~/.arch-params/signing/=default

サインのチェックルールのデフォルト
~/.arch-params/signing/=default.check

にそれぞれ設定する。現実的な利用方法としては、もっとも保守的 に、つまり安全に運用する場合は、それぞれ:

gpg --clearsign

gpg --verify -

と設定する。またもっともリベラルに、つまりサインもしないし チェックもしない場合には、両方のファイルをゼロバイトのファイルとし て作成すると良い。

ある種の重要なできごとが起こった時に、それに連動する形であら かじめ登録しておいた処理が実行されると都合がよいことがよくある。こ のような処理をフックと言う。これは別に GNU arch に限った話ではない。 ソフトウェアに限った話ですらない。腰にぶら下げる万歩計を考えて見れ ばいい。足を一歩踏み出すたび、万歩計はカウントされる。これは足を一 歩踏み出すという行動に対するフックだと言える。フックには二つの要素 がある。ひとつはフックのトリガーとなる出来事、もう一つはフックの内 容だ。出来事のことをフックイベントと呼んだりする。

GNU arch でのフックイベントは以下のとおりである:

実際に呼び出されるフック用のプログラムは、 ~/.arch-params/hook である。どのイベントが起こった時でもこのプログ ラムが呼び出される。~/.arch-params/hook は実行可能ビットが設定され ている必要がある。

~/.arch-params/hook は唯一の引数をとり、これは上記で列挙した フックイベント文字列そのものである。たとえばコミット直後には:

~/.arch-params/hook commit

という形でフックが呼び出される。フックスクリプト中で引数の内 容によって分岐するようなシェルスクリプトにすることで各種フックイベ ント用の処理を切替えることができる。さらに必要に応じてフックは以下 の環境変数が設定された状態で呼び出される。

以下は hook ファイルの例である:

#!/bin/sh

if [ "$1" == "commit" ]; then
   echo
   "${ARCH_ARCHIVE}/${ARCH_CATEGORY}--${ARCH_BRANCH}--${ARCH_VERSION}--${ARCH_REVISION}
   created" \
   | mail octopus@bluegate.org
fi

より複雑な例は以下である:

#!/bin/sh

case "$1" in
    precommit)
        ;;
    commit)
        ;;
    …
esac

すでに述べたように GNU arch には非常に原始的なたくさんのコマ ンドがある。これは Unix コマンドのようにパイプライン上などで組み合 わせて利用することを前提として作られたプリミティブがたくさんあるか らだ。これは融通が利く反面、利用しはじめた人にとってはどれとどれを どのように組み合わせれば作業が楽になるかがはっきりしない。実践的な ワークフローを作るにはノウハウがいる。ここではそのような「必殺技」 の数々をおめにかけよう。

$ tla undo
$ tla replay --reverse patch-10
$ tla replay --reverse patch-9
$ tla sync-tree patch-9
$ tla sync-tree patch-10
$ tla commit -L'hello my new world.'
$

$ tla -S tag A/C--B--V--patch-5 A1/C1--B1--V1
$ cd [これからサブディレクトリを作るどこかのディレクトリ]
$ tla get A1/C1--B1--V1
$

$ tla -S tag A/C--B--V--patch-5 A1/C1--B1--V1
$ tla join-branch A1/C1--B1--V1
$ tla set-tree-version A1/C1--B1--V1
$

$ tla undo
$ tla archive-setup A/C--B--V
$ tla set-tree-version A/C--B--V
$ tla add-log-version A/C--B--V
$ tla import
$ tla redo
$ tla commit -L'hehe, now switched. :)'
$

$ tla inventory -s | tar -T- -zcvf ../`tla tree-version`.tar.gz
$

$ tla inventory -s | xargs -l grep -H 'arch-tag'

マルチツリープロジェクトはツリーの構成を記述しているだけの設 定用アーカイブバージョンと、その設定から読み込まれる要素となるアー カイブバージョンから構成される。設定用アーカイブバージョンには設定 ファイルがあり、どのアーカイブを、どのサブディレクトリに取り込むか を記述する。

GNU arch 本体の場合、アーカイブバージョン間の関係は以下のよ うになっている。

各構成バージョンのversion 名が、1.0 とか 1.3 とかまちまちに なっていることに注意しよう。何度か言ってきたように、GNU arch は異 なるバージョン間のバージョン名には、そのままでは何の関係もない。マ ルチツリープロジェクトを展開するには、設定用アーカイブバージョンを 通常の方法で tla get する。マルチツリープロジェクトの一部として利 用されるアーカイブバージョンと言えども、単独で見た場合には普通のバー ジョンとなんら変わることはなく、バージョンに対してできるすべての操 作が可能であることに注意しよう:

$ tla get -A lord@emf.net--2004 dists--devo--1.0--patch-10 dists--devo--1.0
* from archive cached: lord@emf.net--2004/dists--devo--1.0--base-0
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-1
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-2
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-3
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-4
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-5
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-6
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-7
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-8
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-9
* patching for revision: lord@emf.net--2004/dists--devo--1.0--patch-10
* making pristine copy
* tree version set lord@emf.net--2004/dists--devo--1.0
$ cd dists--devo--1.0
$ ls
=ARCH-USERS-README  =INSTALL  =RELEASE-ID  COPYING  configs  {arch}
$

リビジョン番号は開発が進むにつれてもっと大きな番号になってい るかも知れない。設定用バージョンには、他のどのアーカイブバージョン をどのディレクトリに読み込むかについての定義ファイルがある。定義ファ イルはどのような名前にしても良いが、設定用バージョンのルートディレ クトリか、ルートディレクトリの下の ./configs ディレクトリ配下に置 かなくてはならないという決まりがある。定義ファイルは用途に応じた複 数個を用意することもでき、個数が多いようなら ./configs ディレクト リの下にまとめた方が整理しやすくなる。./configs ディレクトリの下に はサブディレクトリを作り、更に細かく定義ファイルを整理することもで きる。実際 GNU arch ではそのようにして ./configs/emf.net などのディ レクトリが作られている。

定義ファイルの内容は

ディレクトリ名　　　バージョン名

のような複数行からなる。空白だけの行、# で始まる行をコメント として利用することができる。GNU arch にある ./configs/emf.net/devo.tlaという定義ファイルは以下のようになってい る:

# Check out a tla arch distribution from the devo branches.  Latest
# revisions.
#

./src                   lord@emf.net--2004/package-framework--devo--1.0
./src/tla               lord@emf.net--2004/tla--devo--1.3
./src/hackerlab         lord@emf.net--2004/hackerlab--devo--1.0

./src/docs-tla          lord@emf.net--2004/docs-tla--devo--1.0
./src/docs-hackerlab    lord@emf.net--2004/docs-hackerlab--devo--1.0


# tag: Tom Lord Sat Jun 14 14:54:15 2003 (emf.net/devo.tla)
#

各行の意味は明らかだろう。./src というサブディレクトリの下に、 lord@emf.net--2004/package-framework--devo--1.0 というバージョンを 展開する、などの指定になる。実際の各バージョンの展開には tla build-config コマンドを使う:

$ tla build-config emf.net/devo.tla
…
$

余談だが、./configs ディレクトリにはこのほかにもさまざまな定義ファイル があり、Tom Lord が作った GNU arch 以外の公開されたソフトウェアは すべてこれらの定義ファイルから構築することができる。tla build-config が終了すれば、通常 tar ファイルとして配布される tla のソースコードが展開されていることがわかる。XXX 章に書いた方法を使 えばもちろんインストールできる。

せっかく GNU arch のソースコード本体について触れたので、ここ で GNU arch そのもののソースコードの編成について説明しようと思う。 ソースコードのディレクトリ構成はさまざまな理由で大きく変わる可能性 はある。ここでは tla-1.3 のツリー構成について説明する。興味のある 人はここでの説明を理解したら、次の節の方法で GNU arch の分岐を自分 のマシンに作っていつでもハックし始めることができる。

際上位ディレクトリは以下のような雰囲気になっている。

$ ls
=ARCH-USERS-README  =INSTALL  =RELEASE-ID  COPYING  configs  src  {arch}
$ 

ここはあまり見るべきものはない。configs の下にマルチツリープ ロジェクト構築に必要な情報があるだけでどうということはない。重要な のは src ディレクトリの下だ。降りてみる:

$ cd src
$ ls
COPYING      Maintfile	  PLUGIN       configure       docs-tla   links  {arch}
ChangeLog.d  Makefile.in  build-tools  docs-hackerlab  hackerlab  tla
$ 

すこし面白くなってくる。この階層は基本的には Tom Lord が自分 で作ったビルドシステムに関係している。./configure という名前のファ イルがあるが、これが実際に tla をコンパイルする時に走らせるシェル スクリプトだ。tla 本体をハックする場合に関係するディレクトリは hackerlab と tla だけだ。hackerlab は tla とは独立したライブラリ群 で、GNU の glibc のような感じのさまざまなルーチンが入っている。tla に降りてみる:

$ cd tla
$ ls
=THANKS		COPYING      Makefile.in  libawk      libneon  {arch}
=TODO		ChangeLog    PLUGIN	  libdate     tests
=gpg-check.awk	ChangeLog.d  libarch	  libfsutils  tla
$ 

だいぶ核心に近づいてきたが、まだごちゃごちゃしている。'='文 字で始まるファイルは、例によって深く考えなくても良い。この下の libarch。ここが tla の心臓になる:

$ cd libarch
$ ls
=scraps			 cmd-get-changeset.h	    cmd-sync-tree.h
Makefile.in		 cmd-get.c		    cmd-tag.c
PLUGIN			 cmd-get.h		    cmd-tag.h
ancestry.c		 cmd-grab.c		    cmd-tree-lint.c
ancestry.h		 cmd-grab.h		    cmd-tree-lint.h
apply-changeset.c	 cmd-help.c		    cmd-tree-root.c

…

cmd-file-find.c		 cmd-show-changeset.c	    undo.c
cmd-file-find.h		 cmd-show-changeset.h	    undo.h
cmd-find-pristine.c	 cmd-star-merge.c	    whats-new.c
cmd-find-pristine.h	 cmd-star-merge.h	    whats-new.h
cmd-get-changeset.c	 cmd-sync-tree.c
$ 

ここには非常にたくさんのソースファイルがそのまま並んでいる。 数が多いので詳細は省略した。大雑把に言うと、tla foo というコマンド に対応して、cmd-foo.c と cmd-foo.h という二つのソースファイルがほ ぼ必ず存在すると考えて良い。この cmd-foo.c に書ききれる程度の機能 でしかないコマンドの場合には cmd-foo.c のみで話が終る。一つのファ イルで記述するには規模が大きすぎたり、コマンド間で共通の機能として くくり出す場合には、他のファイルが関係していることもある。この場合、 cmd-foo.c の他に、foo.c のような名前になることが多い。たとえば少し 変則的だが、tla my-id に対応するソースコードは cmd-my-id.c であり、 他の my がつくコマンドとの共通部分のソースコードは my.c に存在する、 といった具合になる。cmd-my-id.c と my.c は、GNU arch のコマンドの、 スケルトンと言っても良いくらい単純なので、新しいコマンドを追加しよ うとする人は、まずはここから読み始めるのがおすすめだ。

各コマンドのディスパッチテーブルは cmds.c にある。cmd-xxx.c で作ったコマンドをここに登録すれば tla help などの一覧でも表示され るようになり、実際に呼び出すこともできるようになる。

以下、特に注目すべきファイルを挙げる

第1節で tla build-config を使って tla のソースコードを展開し た。ここでは tla のソースコードに実際に手を入れる方法について説明 しよう。既にのべたように tla はひとつの設定用アーカイブバージョン と、四つの独立したアーカイブバージョンをまとめたものだった。tla を 修正する場合は、このうち、tla--devo--1.3 と hackerlab--devo--1.0 のどちらかに 対して修正を入れることがほとんどなので、これを前提としてカスタマイ ズの仕方を考えてみる。まず、直接 Tom Lord のアーカイブを修正するこ とはできないので、tla と hackerlab の分岐を、ローカルマシンに作る。 ここでは分岐先アーカイブバージョン名を、それぞれ tla--foo--1.3と hackerlab--foo--1.0としよう。

$ tla archive-setup tla--foo--1.3
…
$ tla archive-setup hackerlab--foo--1.0
…
$ tla archive-setup dists--devo--1.0
…
$

通常の分岐を作る操作と全く同じで、それぞれのバージョンに対し てtla tag を実行する。

$ tla tag lord@emf.net--2004/tla--devo--1.3 octopus@bluegate.org/tla--foo--1.3
…
$ tla tag lord@emf.net--2004/hackerlab--devo--1.0 octopus@bluegate.org/hackerlab--foo--1.0
…
$ tla tag lord@emf.net--2004/dists--devo--1.0 octopus@bluegate.org/dists--foo--1.0
…
$

dists--foo--1.0 を get する。当たり前だが dists--devo--1.0 とまったく同じものになる。

$ tla get dists--foo--1.0
…
$

独自の設定を作るため、./configs/emf.net/devo.tla をコピーす る。ここでは ./config/emf.net/foo.tla としよう

./config/emf.net/foo.tla を編集し、以下のように tla と hackerlab を分岐後のものとする:

# Check out a tla arch distribution from the devo branches.  Latest
# revisions.
#

./src                   lord@emf.net--2004/package-framework--devo--1.0
./src/tla               octopus@bluegate.org--2004/tla--foo--1.3
./src/hackerlab         foo@bleugate.org--2004/hackerlab--foo--1.0

./src/docs-tla          lord@emf.net--2004/docs-tla--devo--1.0
./src/docs-hackerlab    lord@emf.net--2004/docs-hackerlab--devo--1.0


# tag: Tom Lord Sat Jun 14 14:54:15 2003 (emf.net/devo.tla)
#

あとは、tla build-config をいま作った定義ファイルによって構 築すればよい:

$ tla build-config emf.net/foo.tla
…
$

これからの修正は、tla の部分については ./src/tla、hackerlab の部分については ./src/hackerlab に降りていって行えばよい。コミッ トは個別のアーカイブバージョンのディレクトリで行なえばよい。繰り返 すが、後は異なる 3っつのアーカイブバージョンのプロジェクトツリーが たまたま特別なディレクトリの上下関係の中に展開されているだけだ。