作業コピーの構造の基本的なところについては、An Overview of CVS で既に見てきました。この章ではもう少し詳細のところを見ます。詳細の大 部分は CVS/ 管理サブディレクトリ中のファイルに関連することです。 Entries, Root, Repository ファイルについては見てきたと思いますが、 CVS/ サブディレクトリには状況により他のファイルがあることもあります。 それらのファイルをここでは説明します。そういうファイルを見つけた時に 驚かないためであり、それらのファイルが原因の問題が起こった時になおす ことができるためです。
CVS/Entries.Log
時々、CVS/Entries.Log
という名前のファイルが現れることがあり
ます。このファイルは、Entries ファイルを書き換えるに足るような重要な
操作をするまで、Entries ファイルへの変更を一時的にキャッシュしておく
ために使われます。CVS は Entries ファイルの適切な箇所だけを書き換え
ることができません。変更するには、全部読んでから全部書き戻さなければ
なりません。これを避けるため、Entries ファイルを書き換える必要が出て
くるまでの間、少々の変更を Entries.Log に記録することがあるのです。
Entries.Log のフォーマットは Entries とほぼ同じですが、各行の冒頭に
一文字付け加わっています。A
は Entries ファイルに追加すべき行
を意味し、R
は削除すべき行を意味します。
Entries.Log ファイルは、たいていは無視して構いません; 欠いてある情報 を人間が理解しなければならないことはめったにありません。しかし、デバッ グのため作業コピー中の Entries ファイルを読んでいる場合には Entries.Log ファイルも調べるべきでしょう。
CVS/Entries.Backup
CVS/Entries.Backup ファイルは CVS が実際に新しい Entries ファイルを
書く場所です。書いたあと Entries
にリネームされます(これは
CVS がリポジトリ内に RCS ファイルを書く時に、一時的な RCS ファイルを
書いて、完成したら適切な名前に変える、というやりかたと同じです)。
完成し次第 Entries にリネームされるので、Entries.Backup ファイルはめっ
たに見ることはないと思います。もし見ることになったとしたら、それは
きっと、CVS がオペレーションの最中に中断されたということを意味します。
CVS/Entries.Static
CVS/Entries.Static ファイルが存在している場合、それはそのディレクト リ全体はリポジトリから取得されたものではないということを意味します。 (作業コピーが不完全な状態であるということを CVS がわかっている場合は、 そのディレクトリの中に余分なファイルを作ったりはしません)
Entries.Static ファイルはチェックアウト中やアップデート中に現われ、
オペレーションが完了し次第、すぐに削除されます。Entries.Static が見
えたとしたら、それは CVS が中断されたことを意味します。そのファイル
があると、CVS は作業ディレクトリに新しいファイルを作ることができません。
(通常、cvs update -d
を実行すれば Entries.Static が削除さ
れ、問題は解決できます)
Entries.Static がなければ、作業コピーはプロジェクトのファイルをすべ て持っている、とは必ずしも言えません。プロジェクトのリポジトリ中に新 しいディレクトリが作成されて、誰かが作業コピーを -d フラグなしでアッ プデートした場合は、作業コピーに新しいディレクトリは作成されません。 この場合 CVS はリポジトリ中に新しいディレクトリがあるということに気 づかないので、作業コピー中に新しいディレクトリがなくても、アップデー トの完了時に Entries.Static ファイルを削除します。
CVS/Tag
CVS/Tag が存在する場合、ある意味、タグ名をディレクトリに関連づける役 割を果たします。ある意味、と言ったのはつまり、CVS はディレクトリに関 するリビジョン履歴を保存しませんし、厳密に言えばディレクトリにタグを つけることもできないからです。タグというのは通常のファイルのみに、正 確に言えば通常のファイルの特定のリビジョンにつけられるものなのです。
しかしながら、あるディレクトリ中の全ファイルが特定のタグをつけられて いるような状況では、CVS はそのディレクトリ全体にそのタグがつけられて いるとも考えるのです。たとえば、あるブランチ上の作業コピーをチェック アウトしたとしましょう:
floss$ cvs co -r Bugfix_Branch_1
ここにファイルを1つ追加する場合、その新しいファイルの最初のリビジョン は、そのブランチ上のリビジョンであって欲しいのではないでしょうか。 CVS も同じような理由で、そのディレクトリにブランチでないスティッキー タグや日付がセットされているかどうかを知る必要があります。
Tag ファイルには1行しかありません。その行の最初の文字はそのタグがどん な種類かを1文字で示すようなコードです。残りはタグ名です。現状、CVS はその1文字コードを3種類使っています:
floss$ cvs checkout -D 1999-05-15 myproj
または
floss$ cvs update -D 1999-05-15 myproj
などです。
(他の1文字コードがあったとしたらそれは、この章が書かれたより後に CVS に新しい種類のタグを追加されたということですね)
Tag ファイルを手で削除したりすべきではありません、かわりに
cvs update -A
を使用して下さい。
他に CVS/ サブディレクトリ中にあるかもしれないファイルを記します:
これらのファイルが何か問題を起こすことは通常ありません、ただ並べてみ ただけです(詳しい説明は CVS Reference を参照のこと)。
CVS に新しい機能が追加されたとすると、作業コピーの管理領域に新しい (ここに書いてない)ファイルが現れるかもしれません。新しいファイルが追 加されれば、Cederqvist マニュアルの Working Directory Storage ノードにドキュメントされることと思います。また、コードから何か得たい と思ったら、ソースディストリビューション中の src/cvs.h を見てみると よいでしょう。
最後に、 全ての CVS/* ファイルは、現時点においても将来においても、作 業コピーの存在するシステムの改行コードを使用します(たとえば、Unix で は LF、Windows では CRLF)。このことは、作業コピーをあるマシンから他 のマシンへ移すと CVS はそれを扱えなくなるかもしれない、ということを 意味します(でもそういう時には、リビジョン管理下にあるファイル自体の 改行コードが新しい環境と不一致を起こすので、別の問題が起きるでしょう)。