さて、アーカイブを作ってはみたものの、まだそこには何も存在し ていない。空っぽである。これからこの中に 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 の形 で指定したバージョンを、完全に修飾されたバージョン名、と言う。
アーカイブと、バージョンの関係を絵に書いてみる。すでに注意し たように、カテゴリ名とブランチ名は、バージョンの階層構造にはまった く関係しない概念だ。つまり:
ではなくて:
のようにイメージしてほしい。地球上の無数のマシンの上に、異な る名前のついた無数のアーカイブがあり、その中にさまざまなバージョン が存在している。octopus@bluegate.org--2004 と、 bar@bogus.example.com--2003、上には、同じ名前のバージョン festina--lente--1.0 がある。これはたまたまそうなったのかも知れない し、二人のハッカーが関連するバージョンを表すのにお互いにわざと同じ 名前を取り決めたのかも知れない。いずれにせよ、同じ名前のバージョン が別のアーカイブにあっても、地球上の GNU arch 分散システムが混乱す ることはない。別のディレクトリにある二つの readme.txt ファイルが何 の関係もないのと同じことだ。
ふたつのバージョンは、同じアーカイブ内にあろうがなかろうが、 別のアーカイブ内にある場合、その二つのアーカイブが同一マシンにある かどうかには全くかかわらず、対等な関係にある。後の章でアーカイブ間 の分岐やマージについて説明するが、このような特殊な関係にある二つの バージョンは、それぞれどのアーカイブの上にあっても同じように動作す る。同じアーカイブ上になければできないような処理はない [6]。
さてあるアーカイブ中にどのようなバージョンがあるかは tla abrowse で確認することができる:
$ tla abrowse
octopus@bluegate.org--2004
test
test--proj
test--proj--1.0
$
このコマンドも明示的にアーカイブを指定しなければ、デフォルト アーカイブに対して処理される。確かに今作ったバージョンが存在して いる。
準備は整った。次の節では、このバージョンに対して実際にデータ をインポートしてみる。何か新しいことを始めるとき—それは誰も 挑戦したことのない問題を解くためのプログラムかも知れないし、歴史の 本を書くことかも知れない—最初にやることになるのが、次の節で の議論だ。