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

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

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

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