コンピュータに一度でも触ったことのある人なら、長く保存してお きたいようなデータを誰でもひとつくらいは持っているものだ。それは大 切な人からの E-mail に添付されていたデジカメでとった写真だったり、 上司ににらまれながら徹夜で仕上げた提案書だったり、カナダの天才ピア ニストが演奏したバッハの変奏曲だったり、hello world とだけ画面に表 示される、本人以外にとっては何の意味もない C 言語のソースコードだっ たり、今日習いにいったおかし教室の先生が自分にだけこっそり教えてく れたチーズケーキのレシピだったり、過去10年分の株価チャートだったり、 次のペットはコッカースパニエルにすべきか、チワワにすべきかについて の非常に論理的な知人からの忠告のメールだったり、2週間ホテルに缶詰 になって書き上げた恋愛小説の最後のたった一言だったりする。これらす べてが、すべて1と0の組み合わせ、つまりデジタルデータとして表現し保 存できることは、実は鉄の塊が空を飛ぶことや、5光年も離れた星が肉眼 で見えるほどに宇宙が澄みきっているのと同じくらい驚嘆すべきことなの だが、たいていの人はそれに気づいてはいない。
このようなデジタルデータは、おおきく二つのグループにわけるこ とができる。ひとつは、一度保存したら二度とその内容がかわらないもの。 もうひとつは、時間と共に修正や改良が必要であり、内容が変化していく ものだ。大切な人の写真はどうだろう? 普通は前者だろう。送ってもらっ た写真を画像編集ソフトで勝手に修正したりしちゃいけない。ありのまま の彼女の姿をありのまま受け入れよう。そうすれば君はずっと彼女の友人 でいられる。でももしかすると君は雑誌の編集者かなんかで、その写真は 一ヵ月に 15 万部も売れる雑誌の一面をかざるはずのコラージュの素材に なるのかも知れない。なら話しは別だ。その画像には大いに修正が入る。 君は背景を黒く塗りつぶし、右目の上にどっかの国の大統領の左目を張り 付け、別に作っておいたレンガのハッチパターンで塗りつぶしたバルテノ ン神殿の裏口に、そのピカソの首を転がす必要がある。それを上司に確認 してもらって、何度か修正を入れる。やっぱり元のやつがいい、とか言わ れてもいいように、修正してできた版ごとに名前のついたファイルにバッ クアップをとっておこう。こうして君の作品は採用され、雑誌は晴れて発 売され、その夜君はどっかのラウンジで静かに酒を飲みながらこれで一段 落だと一人ごちる。
時間と共に内容に変更や修正が加わるデータを履歴つきで時間にそっ て管理したいという場面はよくある。しかもそれは具体的なデータの種類 によらない、一般的な話だってことがわかる。上のような画像であれ、編 集中の音楽であれ、プログラムのソースコードであれ、ドキュメントであ れ、いつ誰がどのような変更をどこに、どのように加えたかを即座に知る ことができて、間違った時のために過去のどの時点のデータにもすぐに戻 れる。そんな汎用的な仕組みがあれば、これは便利だ。こんな発想から発 達してきた、ソフトウェアの一分野がある。バージョン管理シ ステムがそれだ。ここで説明しようとしている GNU arch と いうソフトウェアも、このジャンルに分類されるソフトウェアだ。気づい ただろうか。いま私はこっそり、「いつ誰がどのように」と書いた。そう、 写真の例は一人でやる作業のシナリオだったが、もっと一般的に複数の人 間がひとつのデータをめぐって共同作業するようなケースまで含めて考え てみたいのだ。
実はバージョン管理システムと呼ばれるソフトウェアはすでにいく つも存在している。商用のものもあれば、フリーソフトウェアのものもあ る。フリーソフトウェアの側で一番有名なのは、CVS と呼ばれるもので、 事実上その分野の標準になっている。GNU arch が作られたのは CVS より もずっと後のことだが、こちらもフリーソフトウェアなので、ある一定の ルールを守れば、誰でも自由に利用することができる。ところで人生には 同じ冗談を二度言ってはいけない、という鉄則があるのをご存じだろうか? これに従えば CVS というソフトがあるのに、あえて別のソフトを作った のには、もちろんちゃんとしたわけがある。結局、同じ車輪を二度まわす ほど暇な人間はそう多くはない。この章では、GNU arch の生い立ちにつ いて説明しようと思が、それにはまず、バージョン管理システムの歴史に ついて説明する必要があるし、その歴史のなかで CVS がどんな風に生ま れてきたかも説明する必要があるし、それを踏まえた上でその欠点も説明 する必要がある。それではじめて、どうしてGNU arch が生まれたかもわ かってもらえるというものだ。
もし君がプログラムについての知識がゼロだったり、Unix という 言葉を知らなかったり、知っていても使ったことはないのなら、後の章は まったくのチンプンカンプンであること請け合いだが、この章だけは退屈 せずに読んでもらえることを目指したつもりだ。そんな風にしたのにはわ けがある。実はバージョン管理システムの歴史は、フリーソフトウェア/ オープンソフトウェアのムーブメント自体に密接にかかわっていて、その 世界について、広くさまざまな人に知ってもらいたいという動機が私には あるのだ。
バージョンを管理するのに一番原始的な方法は、もちろんバックアッ プをとることだ。バックアップファイルの名前の後ろに通し番号をつけて 整理したフォルダに入れておけばこれは立派なバージョン管理の役割をは たすことができる。冒頭の画像の話を例にして考えてみよう。いま、 image.tiff という画像ファイルを編集しているとしよう。tiff というの は精細な画像を扱うときによく利用される形式だ。これが雑誌の表紙にな るはずのデータだとしよう。この最初の版を作ったのがたとえば 2004/03/11 の 11:30 だとする。君はまずは手始めに image.tiff を、 image-0.tiff という名前で保存する。それから背景色を変えて、少し縮 小した次の版が 13:45 分にできあがったら、これを image-1.tiff とい う名前でまた保存する。そのあと知らぬ間にボスがやってきて、さんざん ケチをつけたあと、気をとり直して次の版ができたのが 19:12。ではこれ を image-2.tiff にしよう。こんな具合だ。
ファイル名を通し番号じゃなく、時刻そのものにするのも一案だ。 たとえば、image-0.tiff のかわりに、2004-03-11-11-30.tiff のような 名前にする。これだとファイル名を見ただけで、いつバックアップをとっ たかまで一目瞭然だ。欠点としてはファイル名がすごく長くなってしまう ことで、これから説明していくにはちょっと都合がわるい。大抵のシステ ムでは、ファイルの時刻を調べる機能がちゃんとついているので、ファイ ル名自体に時刻を埋め込まなくてもそれほどは困らない。
この方法の利点と欠点について、すこし考えてみよう。まず利点。 なんといっても話が単純なことだ。それからこの手法は—これだっ て立派な手法だ—どんなデータにだって使えることだ。今は画像で 説明したけれど、同じことは見積り用の表計算のデータにだって、プレゼ ン用の提案書にだって、FAX で送る予定のお悔やみの文書にだって、校正 中のマサイ語の辞書にだって使える。1 + 1 = 2 が、りんごにも、みかん にも、象にもサイにも使えるのと同じだ。このことを示すために、 image.tiff という具体的なファイル名のかわりに R という一文字でファ イルを表して、その後にバックアップの順番を示す番号を振ろうと思う。 R はリビジョンの略だ。ファイル名を番号だけ表すのはさすがに寒いので 先頭につけてみた。あまり深く考えないでほしい。
次は欠点。版を重ねるごとにデータサイズが大きくなることだ。い まみたいな話だとかなり複雑なデータになっているはずだから、数メガバ イトもあるかも知れない。そんなんもんじゃない? オーケー。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]