初期インポート時に、正体不明のエラーが表示されてどうしてもうまく行 かないことがある。これはたいていの場合、インポート対象としたいファ イルがうまく認識されていないか、ディレクトリ中に認識できないファイ ルが残っている場合だ。GNU arch はインポート時にもコミット時にも、 プロジェクトツリー全体をスキャンして、自分が認識できないファイルが 存在しないかどうかを確認する。どのようなファイルを認識できないもの にするかは、設定によってプロジェクトツリーごとにユーザが自由に設定 できるのだが、結果として認識できないファイルがディレクトリに残って いるとエラーを表示してコミットやインポートを中断する。これは、きち んと把握しているファイルのみがプロジェクトツリーには現れるべきだと いう GNU arch の思想を反映している。ただしこれには例外があって認識 できないファイルがあったとしても、それを認識できるファイルとみなす ように設定することもできるのだ。また認識できないケースにも二通りあっ て、ファイル名の形からくる場合と、インベントリidが正しく振られてい るかどうかからくる場合もある。また認識できるファイルは、諸事情でさ らにいろいろなファイルタイプに分類されているし、インベントリid 自 身の概念が通常のバージョン管理システムでは存在しないものであること などが理由で、ファイルタイプの認識ロジックは非常に複雑なものになっ ている。

ここでは GNU arch のファイル判別ロジックの詳細を説明する。もし初期 インポートにすでに成功していたり、分岐によってプロジェクトを始めた のであれば、すぐにこの章を読む必要はないと思う。しかし、新しいファ イルをプロジェクトに追加したとたんにコミットができなくなった、とか、 初期インポートがどうしてもうまくいかずエラーになる、という場合には、 この章を読んで、GNU arch のファイル判別ロジックについて少し詳しく 考える必要があるかも知れない。根底にある理屈がわかってしまえば、た いていのエラーは解消すると思う。一点だけ注意だが、GNU arch の場合、 新しいファイルをプロジェクトに追加する場合、CVS など他のバージョン 管理システムにあるような明示的なファイル追加コマンドは存在しない。 インポートまたはコミット時のファイルスキャンで規則に合致すればそれ は追加されたファイルになるし、合致しなければそうはならない。そして 運悪くそれが認識不能ファイルに最終的に分類されればインポートやコミッ ト自体が中断されてしまう。それだけの話だ。

ところで、私は語学が苦手だ。たとえば英語。わけのわからない規則が多 すぎる。want の過去形は wanted だからということで、go の過去は goed だというと笑われる。一個と二個以上を区別するくせに、二個と三 個は区別しない。三人称単数現在に限って動詞の最後に s をつける。で 得意になって studys なんてやるとまたバカにされる。ラテン語なんて最 悪だ。名詞には6っつも格があって、おまけに性がある。海がどうして女 性名詞なのか教えてほしい。人魚が住んでるからだろうか? でも海坊主だっ てちゃんと住んでる。「バラ」は女なのに、「花」は男だと言う。わけが わからない。結局、こういうのは丸暗記するしかないのだ。

GNU arch にもよく似たところがある。もちろん、作者はご存命だし、も う少しは合理的にできているし、ほりさげていけば、いちいちちゃんとし た理由もあるのだろう。でも、悪いことは言わない。最初はあまり深く考 えないほうがいい。そういうものなんだと割り切ろう。

ルールその1: 　　GNU arch はファイルを以下の xxx 種類にとりあえず分類するという約束がある。 　　これを一次分類と呼ぶ。 ルールその2: 　　一次分類は、ファイル名の形だけをもとにして分類される。 ルールその3: 　　一次分類でソースと見なされたファイルはインベントリidの存在/非存在 　　によってさらにソースかどうかを判断されるこれを二次分類という。 　　二次分類でソースでないことがわかったファイルは、とりあえず非認識とされる。 ルールその4:

　　

この結果、最終的にファイルが非認識とみなされれば、インポートやコミッ トは中断される。これを防ぐには、ファイルタイプをソースとなるように =tagging-method を書き換えてから、必要に応じてインベントリidをこの ファイルにつける。つける方法は・・・・ファイルの個数が多い場合、こ れを手でやるのは大変だ。たとえばすでに別のバージョン管理システムで 管理していたファイルを GNU arch に移行したいような場合だ。ありがた いことに自動的にインベントリidを振ってくれるツールを作成している人 たちもいる。詳しくは・・・を見て欲しい。インベントリid については 次の節で詳しく説明しようと思う。GNU arch にしか現れない重要な概念 の一つだ。

ここでの議論は退屈で、見通しがわるく、しかも運が悪いと、GNU arch の使い始めから理解しなくてはならない場所になってしまう。それほど unix に詳しくない人なら、多分ここでさようなら、だろう。このシャー プな学習曲線を緩くするうまい方法は見つけることは、GNU archにとって 急務だと考えている。

インベントリとは、一言で言うと「バージョン管理下にあるそれぞ れのファイルの由来を示す識別子の一覧」のことだ。あるファイルが GNU arch 管理下に置かれるには次の二つのどちらかのケースしかない。一つ は、新しいバージョンをアーカイブにインポートする時にインポート対象 になっている場合。もう一つは、すでに存在しているリビジョンから分岐 したバージョンを作った場合だ。最初の場合には GNU arch システムから 見た時にはそのファイルは新規に導入されたので、新しい識別子が必要に なる。後の場合にはすでにあるファイルと由来を同じくするファイルがで きたので、識別子は分岐元のファイルと同一のものになる。分岐した後、 一般には両方のバージョンで、二つのファイルは独立に変更されていくだ ろう。その独立した二つのファイルには同じインベントリidが振られてい るので、ファイルの自己同一性を示すというよりは、ファイルの由来の同 一性を示す識別子である、と理解するのが正しいだろう。

インベントリの考え方自体は非常に単純なものだ。インベントリ の問題を複雑にしているのは、既存の Unix 系ファイルシステム上でイン ベントリを実装しようとするのが難しいことと、GNU arch のファイル分 類機構と一部干渉する部分があるからだ。GNU arch の初期インポート に失敗する場合、ファイル分類機構がエラーを出している場合と、インベ ントリの仕組みがエラーを出している場合がありこの判別が難しいのだ。 本来、ファイル分類機構はインベントリとは何の関係もない話だが、あ えてこの節で一緒にとりあげることで、初期インポート時のトラブルへの 対処方法を示したいと思う。初期インポートという、一番最初の操作 でつまづく可能性があるのは GNU arch の普及をさまたげる大きな原因の 一つになりかねないのは残念なことだ。