前節で最初のリビジョンをバージョン test--proj--1.0の中に作っ た。ここからはプロジェクトツリーに対して変更を加えてはコミットを発 行することで、リビジョンが増えていく。ここではリビジョンという言葉 について少し詳しく説明する。
バージョンはゼロ個以上のリビジョンを格納する場所で、アーカイ ブの中にある。バージョンにできる最初のリビジョンは base-0 という名 前になる。二つ目以降のリビジョン名は patch-n という形になる。ただ しn はコミットの順序を示す1から始まる整数である。[12]
一度作成されたリビジョンは、修正されたり、削除されることはな い。リビジョンはバージョンの中にあり、バージョンはアーカイブの中に あり、アーカイブはその性質上既存データに対する修正はありえないので、 リビジョンを作成するのに利用したプロジェクトツリーを削除しても一度 コミットしたリビジョンは削除されることはない。リビジョンはバージョ ンの中で順序を持っている。つまり、コミットした時間の順序に一列に並 べることができる。リビジョンをこの順序に並べ、先頭のbase-0 を 0 番 目として数えていった番号のことをリビジョン番号と呼ぶ。リビジョン名 を指定すると、そのリビジョン番号がひとつ決まる。逆にリビジョン番号 を指定するとそれに対応したリビジョン名が求まる。この意味で両者を同 一視することができる。リビジョン名は、パッチレベルと呼ばれることが あるが、リビジョン番号を指す場合もあるのでどちらの意味で利用されて いるか文脈から判断する必要がある。リビジョン番号とリビジョン名の対 応は以下のようになる:
0 base-0 1 patch-1 2 patch-2 …
リビジョン名は文脈によって二つの異る意味をもつ。リビジョン名 は、そのリビジョンをコミットしたプロジェクトツリーの状態を示すと同 時に、直前のリビジョンとの間の差分であるすチェンジセットをも意味す る。その場合、このチェンジセットは直前のリビジョンといま問題になっ ているリビジョンの両方に対して等しく関係しているにもかかわらず、後 の方のリビジョン名によってこのチェンジセットを参照することに注意し なくてはならない。
プロジェクトツリーとは、tla init-tree コマンド、あるいは tla get コマンドなどによって作成された {arch}管理領域を持つディ レクトリツリーのことである。プロジェクトツリーはリビジョンとは違っ て一つ以上のバージョンと関係を持つことができる。しかし通常は主に 一つのバージョンと関係するだけのことが多いし、またこれで十分であ る。プロジェクトツリーはデフォルトバージョンを設定することができ る。プロジェクトツリーに対してはたらく多くのコマンドは特に指定し なければデフォルトバージョンに対してはたらく。
プロジェクトツリーは、通常はデフォルトバージョンに対して行 なうコミットを、実は任意のバージョンに対して実行することができる。 あるバージョンに対するコミットが成功するには、アーカイブ中にある そのバージョンに含まれるすべてのリビジョンのパッチログを、そのプ ロジェクトツリーは持っていなくてはならない。この条件が満たされた 時、そのバージョンの最新リビジョンとプロジェクトツリーとの間のチェ ンジセットが計算され、その内容によって新しいリビジョンがそのバー ジョンに追加される。両者のツリーの内容がいかに違っていたとしても、 チェンジセットの差分の計算は(適用の計算と違って)常に成功するので、 かならず新しいリビジョンを追加することができる。
あまり頻繁に起こる状況ではないが、プロジェクトツリーの内容 をあるバージョンの最新リビジョンとして強制的にコミットしたい場合 には、tla sync-tree を使って、該当バージョンのすべてのリビジョン のパッチログをプロジェクトツリーに追加すれば良い。sync-tree はあ る意味、コミットロジックをだますためのコマンドであるとも言える。
同じような視点でプロジェクトツリーの update を述 べよ