[目次へ][5章へ][6章へ][6.4へ] 最終更新:$Date: 2002/10/23 06:26:50 $
■第6章 CVSの少し賢い使い方【サーバ編】
WinCvsによる編集は基本的に同じなので書かないことにした。
EmptyDirに関する資料(2002/8/23 木津さんより提供あり):
使用例:
[http://www.netbeans.org/devhome/sources/cvs.html] のページの「Maintaining Multiple Checkouts」という部分。
Cederqvistの記述内:
CVS/Repositoryに、当該作業ディレクトリがリポジトリ内のディレクトリに対応していない場合、CVSROOT/EmptyDirが使用される模様。
失敗談:
[http://www.kmc.gr.jp/~ranran/memo/software.2000-1.html]
消すとチェックアウトできなくなる模様。
豆知識:
[http://cvs.m17n.org/cvs/server.ja.html]
cvs-1.10.7 以前に cvs init でリポジトリを作った場合にはこのディレクトリができないので、作らないといけない模様。
■■6.1 管理ファイルを設定しよう
■■■ 6.1.1 管理ファイルってどこにあるの?
■■■ 6.1.2 管理ファイルはどうやって編集するの?
■■■ 6.1.3 自分のファイルは管理ファイルに加えられるの?
■■6.1 管理ファイルを設定しよう
この節ではCVSの管理ファイルを設定するために必要な基本的知識を説明します。続く6.2節、6.3節、6.4節、6.5節で説明するようなさまざまなリポジトリの活用を考えていくには、ここを良く理解しておく必要があります。具体的には、管理ファイルはどこにあってどういうものか、どうやって編集するか、また管理ファイルを加えるにはどうするのかということを順番に説明していきます。
■■■6.1.1 管理ファイルってどこにあるの?
管理ファイルは、リポジトリの直下にあるCVSROOTディレクトリの中にあります。本書では、リポジトリを/home/cvsrootに設置していますので、/home/cvsroot/CVSROOTの中で見つかるはずです。CVSROOTの中身をちょっと覗いてみましょう【図6.1】。
【図6.1.1】CVSROOTの中身 ▼ ls -aF /home/cvsroot/CVSROOT ./ .#notify commitinfo history rcsinfo,v .#checkoutlist .#rcsinfo commitinfo,v loginfo taginfo .#commitinfo .#taginfo config loginfo,v taginfo,v .#config .#verifymsg config,v modules val-tags .#cvswrappers ../ cvswrappers modules,v verifymsg .#editinfo Emptydir/ cvswrappers,v notify verifymsg,v .#loginfo checkoutlist editinfo notify,v .#modules checkoutlist,v editinfo,v rcsinfo ▲
名前の先頭に.#のついたファイルはバックアップ・ファイルですので気にしないでください。EmptyDirというのはcheckout時にCVSが利用するディレクトリの様です。ないとcheckoutができなくなります。1.10.7以前のcvsからそれ以降のcvsに乗り換える場合には、リポジトリに存在しないこのディレクトリを作成する必要があります。このディレクトリをCVS/Repositoryに書くことによって、CVS管理下にないディレクトリをダミーとして扱えるようになるようです。が、このへんは良くわかりません。誰かご存知の方は教えてください。
checkoutlistとcheckoutlist,vのように、,vのついたファイル(RCSファイルともいいます)とペアになったファイルが管理者が設定をおこなうための管理ファイルです。なお、この最初の状態では含まれていない管理ファイルに、passwd、readers、writers、users、cvsignoreの5つのファイルがあります。ここで主な管理ファイルと、関連するコマンド、およびその使用目的を【表6.1.1】にまとめておきます。【表6.1.1】
| 管理ファイル名 | 使用目的 | 初期 セット |
ユーザ 設定ファイル |
説明 | 備考 |
| checkoutlist | 新規に追加する管理ファイルを記述する | 〇 | 6.1.3項 | ||
| commitinfo | コミット前のチェックプログラムを指定する | 〇 | 6.3節 | 共通構文 | |
| config | リポジトリ全体に影響する設定をおこなう | 〇 | 6.1.2項 | ||
| cvsignore | 指定したファイルを見えなくする | × | .cvsignore | 本項 | |
| cvswrappers | データの出し入れ時に特定のファイルに対してフィルタをかける | 〇 | .cvswrapper | 6.3節 6.5節 |
将来的には使わない |
| editinfo | コミットのログを編集したり、評価したりするプログラムを指定する | 〇 | もはや使わない | ||
| history | コマンド実行の履歴を保持する | 〇 | 本項 | CVS管理外 | |
| loginfo | コミット後のログメッセージの処理をおこなう | 〇 | 6.3節 | 共通構文 | |
| modules | モジュールに別名をつけ、コマンド実行時に外部プログラムを実行する | 〇 | 6.3節 | ||
| notify | watch指定されたファイルに変更があったときの通知を制御する | 〇 | 6.3節 7.3節 |
||
| passwd | pserverで使用するパスワードを格納する | × | 6.2節 | CVS管理外 | |
| rcsinfo | ログメッセージのフォーマットを指定する | 〇 | 6.3節 | 共通構文 | |
| readers | pserver経由のアクセスについて読み書きのできるユーザを指定する | × | 6.2節 | writersより優先 CVS管理外 |
|
| taginfo | タグ操作時に外部プログラムを実行する | 〇 | 6.3節 | 共通構文 | |
| users | notifyでメール通知をおこなう場合のユーザ名にメールアドレスを対応させる | × | 7.3節 | ||
| writers | pserver経由のアクセスについて読み書きのできるユーザを指定する | × | 6.2節 | readersの方が優先 CVS管理外 |
以下にこれらについて簡単に説明しておきます。
■■■■checkoutlistファイル
これは新たに管理ファイルに追加したいときに使用します。詳しくは6.1.3項で説明します。
■■■■comitinfoファイル、loginfoファイル、modulesファイル、notifyファイル、rcsinfoファイル、taginfoファイル
コマンド実行時に他のプログラムを自動実行させたいときに設定します。詳しくは6.4節で説明します。
■■■■configファイル
リポジトリの環境設定ファイルです。詳しくは次の6.1.2項で説明します。
■■■■cvsignoreファイル
passwdファイルと同様、cvsignoreファイルも初期状態では存在しません。cvsignoreファイルも後から追加することができます。
cvsignoreの使い方および設定の仕方は、5.1節「個人環境を整えよう」で.cvsignoreに記述したものと同じです。パターンを書いておくと、updateの時にパターンにマッチしたファイルを無視するようになります。両者の違いは設定の影響範囲です。.cvsignoreの設定は個人および作業コピー内にのみ影響を与えますが、管理ファイルcvsignoreの設定は、リポジトリ利用者全員に影響を与えます。
■■■■cvswrappersファイル
リポジトリにデータが出入りする際に、このファイルに記述されたファイルパターンでマッチして、マッチしたものに指定されたフィルタをかけるようにするためのファイルです。このファイルの働きについては、6.3節と6.4節で詳しく説明します。
■■■■editinfoファイル
このファイルはもはや使用しないので説明は省きます。
■■■■historyファイル
このファイルはユーザのおこなった動作をCVSが逐次記録するためのファイルです。add、commitなどのコマンドを実行する度に、その情報が追加されていきます。このファイルはCVS管理外のファイルです(,vのついたペアのファイルが存在しません)。これは、記録が記録を呼んでめんどくさいことになるからのような気がしますが、確認はしていません。
4.6節で説明したhistoryコマンドでこのファイルの内容を抽出・整形して表示することもできます。自動的に書き換えられるものですから、管理者が編集する必要はありません。基本的にこのファイルはこのままそっとしておいてください。
なお、1.11からconfigファイルのLogHistoryパラメータで、どのコマンド動作を記録するかを指定できるようになりました。6.1.2項で説明します。
■■■■passwdファイル、readersファイル、writersファイル
これらは初期状態では存在しない管理ファイルで、遠隔リポジトリへの接続方法のひとつであるpserverの設定の際に作成します。これらのファイルは管理ファイルですが、CVS管理下には入っていません(,vのついたペアのファイルが存在しません)。これはセキュリティ上の配慮からです。詳しくは、6.2節で説明します。
■■■■usersファイル
notifyファイルを使用するとメール通知をおこなうことができるのですが、このときユーザ名にメールアドレスを対応させる必要があることがあります。その指定をおこなうためのファイルです.詳しくは7.3節で説明します。
■■■6.1.2 管理ファイルはどうやって編集するの?
気がつかれたと思いますが、,vが各管理ファイルについていたということは、これらの管理ファイルはバージョン管理されているということです。ほかのモジュールと違って、CVSROOTはそのディレクトリの中に、バージョン管理用の,vファイルと、その最新コピーが入っています。このため、管理ファイルを編集するには、次のようなどちらかの通常の作業方法でバージョン管理する必要があります。
方法1. 直接/home/cvsroot/CVSROOT内のコピーを編集し、RCSコマンドを介してバージョン管理する 方法2. checkoutして編集し、commitする
CVSには、「checkoutして編集→commit」という通常の操作だけで、管理ファイルへの変更反映をおこなう仕組みが組み込まれています。この仕組みを利用する方が楽でしょう。つまり、方法2.を使うのが良いと思います。
まず、CVSROOTの作業コピーをcheckoutしてみましょう【図6.1.2】。
【図6.1.2】CVSROOTを手元に取ってくる ▼ % cvs checkout CVSROOT cvs checkout: Updating CVSROOT U CVSROOT/checkoutlist U CVSROOT/commitinfo U CVSROOT/config U CVSROOT/cvswrappers U CVSROOT/editinfo U CVSROOT/loginfo U CVSROOT/modules U CVSROOT/notify U CVSROOT/rcsinfo U CVSROOT/taginfo U CVSROOT/verifymsg ▲
【表6.1】であげた16個のファイルのうち、passwd、readers、writers、users、cvsignoreを除く11個の管理ファイルがコピーされました。
このうち、試しにconfigファイルを編集してみましょう。configファイルの中に設定できるパラメータは、現在のところ、SystemAuth、LockDir、TopLevelAdmin、LogHistory、RereadLogAfterVerifyの5つです。本書の前版からPreservePermissionsパラメータが無くなり、LogHistoryパラメータとRereadLogAfterVerifyパラメータが加わりました。PreservePermissionsパラメータとLogHistoryパラメータは1.11での変化ですが、RereadLogAfterVerifyパラメータはいつ加わったか不明です(はて?)。
このうち、SystemAuthパラメータは遠隔のサーバ設定で使用するパラメータですので、次の6.2節で詳しく説明します。
TopLevelAdminパラメータは、モジュールを取ってきたとき、モジュールの内部だけでなく、その上のディレクトリにもCVSディレクトリを作るためのパラメータです。何が嬉しいかといいますと、細々としたモジュールをまとめて扱うときに便利です。加えて複数のリポジトリを使い分けている利用者も、同じリポジトリを同じディレクトリにまとめることができるので、便利かもしれません。
LockDirパラメータは、作業中にロックファイルを作るディレクトリを指定するためのパラメータです。このパラメータの設定により、リポジトリに書き込み許可を持たないユーザがリポジトリを利用できるようになります。WWWでの公開に伴い、httpdの実行ユーザがリポジトリを利用する必要があるようなときは、設定を考えるとよいでしょう。
LogHistoryパラメータは、historyファイルにどのコマンド動作を記録するかを指定するためのパラメータです。具体的には、4.6節で説明した11個のイベント、「TOEFWUCGMAR」で指定できます(…のはずですが、コメントからUが外れてます…多分記載ミスでしょう。Uについて動作しているようです)。例えば、コミットに関するものだけ記録するという場合には、LogHistory=MARというように指定します。全部記録する場合にはLogHistory=TOEFWUCGMARと指定する以外に、LogHistory=allというようにも指定できます。
RereadLogAfterVerifyパラメータは、verifymsgファイルによるログメッセージ書き換えの挙動を制御するものです。always、stat、neverの3つが指定でき、標準ではalwaysが指定された状態になってます。alwaysは常に書き換えを許可し、statは読む前に対象ファイルが変更されているかをチェックすることを強制し(その分オーバヘッドがかかるので、大きなリポジトリには推奨されていません)、neverは書き換えることを禁止します。使ったことがないので、詳細は分かりません。
ここでは、ほかでは紹介しないTopLevelAdminパラメータを設定し、その挙動を観察します。まず、cvs-1.11.2に付属するconfigファイルについてみてみましょう。
【図6.1.3】cvs-1.11.2についてくるconfigファイル ▼ # Set this to "no" if pserver shouldn't check system users/passwords #SystemAuth=no # Put CVS lock files in this directory rather than directly in the repository. #LockDir=/var/lock/cvs # Set `TopLevelAdmin' to `yes' to create a CVS directory at the top # level of the new working directory when using the `cvs checkout' # command. #TopLevelAdmin=no # Set `LogHistory' to `all' or `TOFEWGCMAR' to log all transactions to the # history file, or a subset as needed (ie `TMAR' logs all write operations) #LogHistory=TOFEWGCMAR # Set `RereadLogAfterVerify' to `always' (the default) to allow the verifymsg # script to change the log message. Set it to `stat' to force CVS to verify # that the file has changed before reading it (this can take up to an extra # second per directory being committed, so it is not recommended for large # repositories. Set it to `never' (the previous CVS behavior) to prevent # verifymsg scripts from changing the log message. #RereadLogAfterVerify=always ▲
最初configファイルには、SystemAuth、LockDir、TopLevelAdmin、LogHistory、RereadLogAfterVerifyの5つのパラメータがコメントとして記述されています。ここでは、実験的に最終行の先頭の#を外して有効にし、かつTopLevelAdmin=yesに書き換えます。編集後このconfigファイルをcommitします【図6.1.4】。
【図6.1.4】configファイルをcommitする ▼ % cvs commit -m "Activate TopLevelAdmin on trial" config Checking in config; /home/cvsroot/CVSROOT/config,v <-- config new revision: 1.4; previous revision: 1.3 done cvs commit: Rebuilding administrative file database ▲
commitの手順自体は、通常のモジュールと同じですが、最後にリポジトリ側の管理ファイルを作りなおしているところがちょっと違います【図6.1.4 6行目】。 次に、別のディレクトリに作業コピーを作ってみます【図6.1.5】。対象とするモジュールは何でもよいのですが、ここではcvstestを使用しています。
【図6.1.5】別の場所に作業コピーを取ってみる ▼ % cvs -d /home/cvsroot checkout cvstest cvs checkout: Updating cvstest U cvstest/fish.jpg U cvstest/test.txt ▲
すると、今までできなかった、CVSというディレクトリがモジュールcvstestと同じ場所にできていることを確認できます【図6.1.6 3行目】。
【図6.1.6】何ができているのかな? ▼ % ls -FR .: CVS/ cvstest/ ./CVS: Entries Entries.Log Entries.Static Repository Root ./cvstest: CVS/ fish.jpg test.txt ./cvstest/CVS: Entries Repository Root ▲
EntriesとEntries.Staticは空で、中身があるのは、Entries.LogとRoot、Repositoryです。この3つのファイルの中身を眺めてみましょう。
CVS/Entries.Log ▼ A D/cvstest//// ▲
CVS/Root ▼ /home/cvsroot ▲
CVS/Repository ▼ . ▲
CVS/Rootがあるので、CVSROOT環境変数や-dオプションを使ってリポジトリを切り替えなくても、このディレクトリに入れば、同じリポジトリに対する操作が可能となります。あとはモジュールではないのでCVS/Repositoriesの内部が.になっているのが面白いですね。CVS/Entries.Logは通常のモジュールでCVS/Entriesがサブディレクトリを管理しているのの代理のようです。cvs -t updateなどとすると、どのあたりで使用されているか様子を垣間見ることができます【図6.1.7】。
【図6.1.7】cvsの挙動をトレースしてみたり… ▼ % cvs -t update -> main loop with CVSROOT=/home/cvsroot cvs update: Updating . -> rename(CVS/Entries.Backup,CVS/Entries) -> unlink_file(CVS/Entries.Log) -> Reader_Lock(/home/cvsroot) -> Lock_Cleanup() cvs update: Updating cvstest -> Reader_Lock(/home/cvsroot/cvstest) -> Lock_Cleanup() -> Lock_Cleanup() ▲
使わない場合には元に戻しておいてください。
■■■ 6.1.3 自分のファイルは管理ファイルに加えられるの?
CVSが管理ファイルとしてあらかじめ知っているもの以外のファイルを、CVSROOTに加えたいたいことがあります。加えるだけではなくて、コミットすると自動的にリポジトリ側のファイルも更新したいとします。例えば、6.4節や6.5節で見るように自動化スクリプトを管理ファイルと一緒に登録して変更時には自動更新したいということがあるかもしれません。
スクリプトを登録することの是非についてはここでは置いておきます。つまり、便利にはなりますが、複数のユーザが管理ファイルに触れることができるような状況では危険です。そういう危険を理解した上で設定してください。
単にCVSROOTに加えただけでは、リポジトリの管理ファイルは更新されません。ここでは、newadminfileというファイルを用意して様子を見ていきましょう。ともかく、CVSROOTに加えてみます【図6.1.8】。
【図6.1.8】newadminfileの追加 ▼ % cvs add -m "Test administrative file" newadminfile cvs add: scheduling file `newadminfile' for addition cvs add: use 'cvs commit' to add this file permanently % cvs commit -m "Add a test administrative file" newadminfile RCS file: /home/cvsroot/CVSROOT/newadminfile,v done Checking in newadminfile; /home/cvsroot/CVSROOT/newadminfile,v <-- newadminfile initial revision: 1.1 done cvs commit: Rebuilding administrative file database ▲
【図6.1.8 最終行】で、管理ファイルが再構成されたとメッセージが出ていますが、実際はどうでしょう【図6.1.9】。
【図6.1.9】再構成されたって? ▼ % ls -Fa /home/cvsroot/CVSROOT ./ .#notify commitinfo history rcsinfo .#checkoutlist .#rcsinfo commitinfo,v loginfo rcsinfo,v .#commitinfo .#taginfo config loginfo,v taginfo .#config .#verifymsg config,v modules taginfo,v .#cvswrappers ../ cvswrappers modules,v val-tags .#editinfo Emptydir/ cvswrappers,v newadminfile,v verifymsg .#loginfo checkoutlist editinfo notify verifymsg,v .#modules checkoutlist,v editinfo,v notify,v ▲
newadminfileについて見てみると、newadminfile,vファイルは出来ていますが、newadminfile自体は出来ていません。ここで強制的にRCSコマンドcoで取り出したとしても、以降のコミットで更新はされません。これでは管理ファイルとしては機能しません。困りましたね。
リポジトリ側の管理ファイルが(チェックアウトされ)更新されるようにするには、checkoutlistファイルに追加する必要があります。 checkoutlistファイルの書式は1行に一つのファイルを設定する仕組みをとっています。1行の書式は【図6.1.10】のようになります。最初に空白があってもなくても構いません、次はファイル名で、さらに空白が入り、最後に行末までがエラーメッセージとして扱われます。エラーメッセージはなんらかの理由でこのファイルが取り出せなかったときに出力されるメッセージです。適当で構いません。
【図6.1.10】checkoutlistでの追加ファイル設定の書式 ▼ [<空白>]<ファイル名><空白><エラーメッセージ><行末> ▲
例えば、newadminfileを追加するには【図6.1.11】のように書きます。
【図6.1.11】newadminfile登録のための1行 ▼ newadminfile The test administration file (newadminfile) cannot be retrived ▲
これをcheckoutlistファイルに組み込みます【図6.1.12】。
【図6.1.12】checkoutlistファイルへの組み込み ▼ # The "checkoutlist" file is used to support additional version controlled # administrative files in $CVSROOT/CVSROOT, such as template files. # # The first entry on a line is a filename which will be checked out from # the corresponding RCS file in the $CVSROOT/CVSROOT directory. # The remainder of the line is an error message to use if the file cannot # be checked out. # # File format: # # [] # # comment lines begin with '#' newadminfile The test administration file (newadminfile) cannot be retrived ▲
これをコミットしましょう【図6.1.13】。
【図6.1.13】コミットコミット〜♪ ▼ % cvs commit -m "Add newadminfile into checkoutlist as ad administrative file." checkoutlist Checking in checkoutlist; /home/cvsroot/CVSROOT/checkoutlist,v <-- checkoutlist new revision: 1.2; previous revision: 1.1 done cvs commit: Rebuilding administrative file database ▲
そしてリポジトリの管理ファイルの様子を見てみます【図6.1.14】。
【図6.1.14】お、newadminfileができてる! ▼ % ls -Fa /home/cvsroot/CVSROOT ./ .#notify commitinfo history notify,v .#checkoutlist .#rcsinfo commitinfo,v loginfo rcsinfo .#commitinfo .#taginfo config loginfo,v rcsinfo,v .#config .#verifymsg config,v modules taginfo .#cvswrappers ../ cvswrappers modules,v taginfo,v .#editinfo Emptydir/ cvswrappers,v newadminfile val-tags .#loginfo checkoutlist editinfo newadminfile,v verifymsg .#modules checkoutlist,v editinfo,v notify verifymsg,v ▲
めでたく、newadminfileができました(パチパチ)。今後、CVSROOTの作業コピーで作業した内容は、コミット時に自動的にリポジトリ側のファイルに反映されるようになります。実際の活用例は、6.4節や6.5節を見てください。