この章では、GNU arch が必要なリビジョンやチェンジセットを高 速に取得する方法について議論する。この章での議論はパフォーマンスに 関してのことだけで、ここを読んでも本質的に何か新しい機能がつけ加わ るわけではないし、基本的な設定をすませてしまえば、普段はあまり意識 しないでこの恩恵にあずかることができる。普通免許さえあれば、誰でも ベンツにも乗れるのと一緒だ。しかしある特定のバージョンの中に非常に たくさんのリビジョンを蓄積していく場合や、ネットワーク上の別のマシ ンにあるバージョンとのやりとりが発生するような利用が主な場合、ここ での技法は場面によっては速度を劇的に改善することがある。GNU arch を実践的に利用しようと考えているなら、いつかはこの章のどれかの技法 が君を助けることになるだろう。誰だって料金がそんなに違わないなら ファーストクラスで行くだろう。
ひとつのバージョンに対して新しいリビジョンをコミットするたび、 バージョンの中にはそのリビジョンを直前のリビジョンから作り上げるの に必要なチェンジセットが蓄積されていく。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 しようとすると、継続元のバージョ ンにまで遡ってリビジョンを構築することになってしまう。継続元がネッ トワークをまたいだ別マシン上にある場合にはこの違いはより顕著になる のは明らかだ。
あるリビジョンに対するリビジョンキャッシュは、バージョン中の チェンジセットのサイズがごく小さいものだと仮定すれば、大体ベースリビジョ ンと同じ程度の領域を食うので、たくさんのリビジョンについてキャッシュ するのはあまり得策ではない。こんな場合にはリビジョンライブラリを構 築する方が良い結果が得られるだろう。