以下は、archive-pfs.c のコメントからの抜粋である。

あるバージョン内にはリビジョンが一列になって並んでいる。新し いリビジョンはどれも順序づけされて、不分割で、独立し、永続的なもの として作成される必要がある。ファイルシステムアーカイブ中で、バージョ ンはディレクトリの形に実装され、リビジョンはその中にパッチレベル名 を持ったサブディレクトリとして実装される。(base-0, patch-1 ... な ど)。通常の rename システムコールはこのための仕組みをほぼ用意して くれる: tla クライアントは,,wants-to-be-patch-1-txnidのような名前 のディレクトリを作り、必要なリビジョンデータをそこに入れ、それから patch-1 のような名前に rename すれば良いように思える。クライアント はpatch-(N-1)が存在しない場合には patch-N を作らないものと取り決め ておけば、patch-Nのコミットに成功した別のクライアントがある場合に は rename を失敗するので、排他制御は正しく働くことになるように思え る。

しかしここに罠がある。base-0 あるいは patch-N の後の名前は固 定されたものではないのだ。patch-(N+1)かも知れないが、version-0 に なることもある。patch-N (あるいは base-0 )の後続リビジョンとして、 同時に patch-(N+1)と version-0 を作ろうとするクライアントがあった 場合には悲惨なことになる。rename はこの問題を直接解くことはないの だ。(さらに、"継続する形のロック"もサポートしたい。実際にコミット する前に新しいリビジョンをロックしておくことで、そのリビジョンに対 して別の誰かがコミットすることをあらかじめ防ぐようにしたい。)

で、かわりに以下のような仕組みを実装する。

あるバージョンのサブツリーは常に、唯一の(ネストしない) "リビ ジョンロック用ディレクトリ" を持つものとする。このディレクトリは常 に +contents と呼ばれるサブディレクトリを持つ。通常、+contents ディ レクトリは最終的には新しいリビジョン用のディレクトリとして rename されるものだ。

一般的に、リビジョンロックディレクトリの名前はロックの状態を 示す。書き込みトランザクションがロックを取得するときには +contents ディレクトリ中に新しいリビジョン用のデータ(これはネストされた新し いリビジョンロックディレクトリがあるが)を入れ、それから +contents をpatch-N(あるいは version-0、base-0、versionfix-N の名前)に rename し、後始末をする。

とりうるリビジョンロックの状態は以下である。

[A,B,C,D,E]