[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C. 管理用ファイル便覧

リポジトリ中のディレクトリ `$CVSROOT/CVSROOT' に、 CVS を支援する多くのファイルが置かれます。 これらのファイルが無いと CVS の能力が制限されてしまいますが、 適切に設定すれば種々の操作を簡略化することができます。 これらを編集する方法は 2.4 管理用ファイルの紹介 参照。

これらの内で最も重要なファイルは `modules' で、 リポジトリ内のモジュールを定義します。

C.1 The modules file  モジュールを定義する
C.2 cvswrappers ファイル  ファイル名の応じてバイナリかどうかを指定する
C.3 格納を支援するファイル  格納を支援するファイル (commitinfo, verifymsg, editinfo, loginfo)
C.7 Taginfo  タグの検証、ロギング
C.6 管理用ファイル rcsinfo  ログ・メッセージの雛型
C.8 cvsignore でファイルを無視する  無視するファイルを設定する
C.9 checkoutlist ファイル  自分自身の管理ファイルを追加する
C.10 ファイル history  履歴情報を記録する
C.11 管理用ファイルにおける変数展開  各種変数の展開
C.12 The CVSROOT/config configuration file  その他の CVS の設定


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1 The modules file

管理用ファイル `modules' には、 ソース・コードの集合体の名前の定義を記述します。 新たな定義を CVS に理解させるには、 CVS を用いてファイル `modules' を修正して下さい (add, commit など普通のコマンドを使用します)。

ファイル `modules' には、モジュールの定義だけでなく、 空白行や註釈行 (`#' で始まる行) も記述できます。 またバックスラッシュ (`\') を行の最後に加えて、 長い行を次の行にまで続けることができます。

モジュールには3つの種類があります: 別名モジュール、一般モジュール、ア ンドモジュールです。それらの違いはリポジトリのファイルの作業ディレクト リへの割り付け方法です。以下の全ての例では、最上位のリポジトリには `first-dir' というディレクトリがあり、そこには `file1' と `file2' というファイルがあり、`sdir' というディレクトリがあ ります。`first-dir/sdir' には `sfile' というファイルがありま す。

C.1.1 別名モジュール  一番簡単なモジュール
C.1.2 一般モジュール  
C.1.3 アンドモジュール  
C.1.4 ディレクトリの除外  モジュールからディレクトリを除外する
C.1.5 モジュールのオプション  一般とアンドモジュールはオプションを取れる
C.1.6 modules ファイルの "プログラムオプション" のプログラムがどのように実行されるか  modules の "プログラムオプション" の プログラムの動作方法


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1.1 別名モジュール

別名モジュールが一番簡単な種類のモジュールです:

mname -a aliases...
これはモジュール mname の最も簡単な定義方法を表わします。 `-a' フラグは単純に別名の定義を行います: CVS に (コマンドの引数として) mname が与えられると、 aliases に記述された名前の一覧を代りに使用します。 aliases は他のモジュール名もしくはパス名から構成します。 aliases にパス名を使用した場合、 CVS の引数にパス名を明示した場合と同じく、 checkout したとき途中の全てのディレクトリが 作業ディレクトリに作成されます。

例えば、モジュールファイルの内容が以下のようであると:

 
amodule -a first-dir

次の2つのコマンドは等価です:

 
$ cvs co amodule
$ cvs co first-dir

そして、それらは以下のような出力を出します:

 
cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1.2 一般モジュール

mname [ options ] dir [ files... ]
この形式のモジュール定義を最も単純にすると、 `mname dir' となります。 これはディレクトリ dir の全てのファイルを、 モジュール mname と定義します。 dir は ($CVSROOT から) ソースのあるディレクトリへの相対パス名です。 この場合にソースを取り出すと、 mname というディレクトリだけが作業ディレクトリに作成されます。 つまり dir が複数のディレクトリ階層から成るパス名であっても、 既定では途中のディレクトリ階層は使用されません。

例えば、モジュールが以下で定義されていると:

 
regmodule first-dir

regmodule は first-dir のファイルを含みます:

 
$ cvs co regmodule
cvs checkout: Updating regmodule
U regmodule/file1
U regmodule/file2
cvs checkout: Updating regmodule/sdir
U regmodule/sdir/sfile
$

dir の後で明示的にモジュールを指定することで、特定のファイルをディ レクトリ dir から選択することができます。例:

 
regfiles first-dir/sdir sfile

この定義により、regfiles モジュールを取得すると、一覧に挙げられたファ イルがある単独のディレクトリ `regfiles' を作成し、それは CVS のソースリポジトリのより深いディレクトリから来ています。

 
$ cvs co regfiles
U regfiles/sfile
$


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1.3 アンドモジュール

モジュール定義は定義に `&module' を含めることで他のモジュー ルを参照することができます。

 
mname [ options ] &module...

そうすると、モジュールを取得したときに、モジュールのあるディレクトリで、 それぞれのモジュールのためのサブディレクトリを作成します。

 
ampermod &first-dir

そうすると、checkout は ampermod ディレクトリを作成し、それには first-dir というディレクトリがあり、それは今度は自分の全てのファ イルとディレクトリを持っています。例えば、コマンド

 
$ cvs co ampermod

は以下のファイルを作成します:

 
ampermod/first-dir/file1
ampermod/first-dir/file2
ampermod/first-dir/sdir/sfile

ここには、一つ癖/バグがあります: CVS が印字するメッセージは `ampermod' を省略するので、ファイルが取り出された位置を正確に表示 しません。

 
$ cvs co ampermod
cvs checkout: Updating first-dir
U first-dir/file1
U first-dir/file2
cvs checkout: Updating first-dir/sdir
U first-dir/sdir/sfile
$

このバグっぽい動作に頼らないでください。CVS の将来のリリースでは 修正されているかもしれません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1.4 ディレクトリの除外

別名モジュールは、除外されるべき各ディレクトリ名の前に驚嘆符 (`!') を付けることで、特定のディレクトリを除外することができます。

例えば、モジュールファイルが以下のようになっていると:

 
exmodule -a !first-dir/sdir first-dir

モジュール `exmodule' を取り出すと、サブディレクトリ `first-dir/sdir' にあるファイル以外の全てを取り出します。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1.5 モジュールのオプション

標準モジュールとアンドモジュールのどちらもオプションを含むことができ、 それはモジュールの追加情報を提供します。

-d name
作業ディレクトリの名前をモジュール名とは別のものにします。

-e prog
モジュールのファイルが export されたときに常に実行されるプログラム prog を指定します。prog は単独の引数、モジュール名と共に実 行されます。

-o prog
ファイルのモジュールが取り出されたときに常に実行されるプログラム prog を指定します。prog は単独の引数、モジュール名と共に実 行されます。prog が実行される方法は C.1.6 modules ファイルの "プログラムオプション" のプログラムがどのように実行されるか を 参照してください。

-s status
モジュールに状態を割当てます。モジュールファイルが `cvs checkout -s' で印字されると、モジュールが主モジュール状態に従って並び換えられ、 それからモジュール名に従って並び換えられます。このオプションは他に意味 はありません。状態以外のいくつかのことにこのオプションを使うことができ ます: 例えば、このモジュールに責任のある人の一覧などです。

-t prog
モジュールのファイルが rtag でタグ付けされたときに常に実行され るプログラム prog を指定します。prog は2つの引数と共に実行 されます: モジュール名と rtag に指定されたタグ名です。 tag が行われたときは実行されません。一般的に、taginfo の方が良 い解決法です (see section C.7 Taginfo)。

"プログラムオション" プログラムがどのように実行されているのかを見る ために C.1.6 modules ファイルの "プログラムオプション" のプログラムがどのように実行されるか も参照した方が良いでしょう。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.1.6 modules ファイルの "プログラムオプション" のプログラムがどのように実行されるか

checkout, rtag, export ではプログラムはサーバ側が基で、以下のものが適 用されます:-

遠隔接続方法 (pserver, ext など) を使っているときは、CVS はこのプログ ラムをサーバ上で一時ディレクトリから実行します。プログラムはパス上で検 索されます。

"ローカル接続" 使っているときは (ローカルや、遠隔の NFS ファイルシス テムを使用しているとき、すなわちリポジトリがパスのみに設定されていると き)、プログラムはもし見つかれば新しく取り出されたディレクトリから実行 され、そうでない場合は代わりにパスが検索されます。

commit と update はローカルリポジトリ接続を使っているとき のみ に動作することにも注意してください--pserver や他の遠隔 CVS からソース が取り出されているときは、そのファイルは単純に作成されません。

プログラムは全て操作がちゃんと終了した後に実行されます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.2 cvswrappers ファイル

Wrapper とは操作中のファイル名に基づいて設定を制御することを可能にする CVS の機能のことです。設定は、バイナリ・ファイルには `-k' で、 マージできないテキスト・ファイルには `-m' です。

また、非バイナリ・ファイルを更新するときの マージ方針について記述するオプション `-m' があります。 MERGE は CVS が通常用いる方法です: ファイルをマージしようとすることを意味します。COPYcvs update はファイルのマージを拒否するという意味で、`-kb' でバイナ リとして指定されたファイルにもそうなります (ただし、バイナリとして指定 されていれば、`-m 'COPY'' を指定する必要はありません。 CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する ために使用者が CVS の外の機構を使用することを要求します。

警告: CVS 1.9 以前では COPY を使わないでくださ い--それらのバージョンの CVS はあるバージョンを別の物の上にコピー し、以前の内容を消し去ってしまいます。 Wrapper オプション `-m' は更新時のマージ方針にのみ影響し、 ファイルの格納方法には影響しません。 バイナリ・ファイルの詳細は 9. バイナリ・ファイルの扱い 参照。

管理用ファイル `cvswrappers' の基本的な書式:

 
ワイルドカード    [オプション 値][オプション 値]...

利用できるオプションを以下に挙げます。
-m                マージ方針              値: MERGE か COPY
-k                キーワード展開          値: 置換モード

値は以下のように単引用符で囲みます。

例えば、`.exe' で終わるファイルをバイナリとして扱いながら、 ディレクトリを取り入れます:

 
cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.3 格納を支援するファイル

ファイル `modules' 中の `-i' フラグは、 ファイルが格納された時に特定のプログラムを実行するのに用いられます (see section C.1 The modules file)。 この節で説明するファイルは、 ファイルの格納時にプログラムを実行するための、 より柔軟な方法を提供します。

格納時に実行できるプログラムは三種類に分けられます。 これらのプログラムはリポジトリ中のファイルに記述されます。 次に示すのは、 ファイル名と、対応するプログラムに必要な機能を示したものです。

`commitinfo'
ここに記述されるプログラムは、 格納が許されるかどうか判断する責任を持ちます。 このプログラムが正常終了しなければ、 格納が中止されます。

`verifymsg'
指定されたプログラムはログメッセージを評価するために使用され、それは全 ての要求部分を備えているかを検証するかもしれません。これはログメッセー ジの雛型を保持することのできる `rcsinfo' ファイルと組合せて使うと とても役に立ちます (see section C.6 管理用ファイル rcsinfo)。

`editinfo'
ここに記述されるプログラムは、 ログ・メッセージを編集するのに用いられ、 全ての要求される項目が含まれるかどうか可能な限り確かめます。 ログ・メッセージの雛型を記述する `rcsinfo' ファイルと 組み合せることで、より便利になります (see section C.6 管理用ファイル rcsinfo)。(旧式)

`loginfo'
ここに記述されるプログラムは、 格納が完了した時点で呼び出されます。 ログ・メッセージと追加情報とを受け取り、ファイルに格納するか、 特定の人物にメールとして出すか、またはニュース・グループに投稿するとか、 または... あなたの想像力だけがその制限です。

C.3.1 共通の構文  
C.4 管理用ファイル Commitinfo  格納前にチェックする
C.5 ログメッセージの検証  ログメッセージはどのように評価されるのか?
C.5.1 Editinfo  ログ・メッセージの作成方法を指示
(旧式)
C.5.2 管理用ファイル Loginfo  ログ・メッセージをどこに送るか?


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.3.1 共通の構文

`commitinfo', `loginfo', `rcsinfo', `editinfo', `verifymsg', などのような管理ファイルには共通の書式があります。 各ファイルの目的は後述します。 ここでは共通の構文について説明します。

各行は次の要素から構成されます:

空白行は無視されます。 また `#' という文字で始まる行は註釈行として扱われます。 残念ながら、長い行を複数行に分割することはできません

リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。 行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.4 管理用ファイル Commitinfo

`cvs commit' を実行する直前に必ず実行したいプログラムを、 ファイル `commitinfo' に記述します。 修正、追加、削除されたファイルを格納しても良いかどうか、 このプログラムを用いて格納前に判断します。 例えば、変更されたファイルがあなたのサイトの コーディング・スタイルの標準に従っているか確かめることもできます。

前に書いたように、`commitinfo' の各行は、第一項の正規表現、 残りの部分のコマンド行形式から構成されます。 コマンド行の部分には、 プログラム名と適切な数の引数とを記述することができます。 また実行の際には、リポジトリのフルパスと 格納しようとするファイル名 (追加, 削除, 修正されたファイル名) がコマンド行の最後に与えられます。

リポジトリ中のディレクトリと正規表現とが合致する最初の行が実行されます。 そしてコマンドが非零で終了した場合は、格納が中止されます。

第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。

第一項が `ALL' である行全てが、 最初に合致した正規表現または `DEFAULT' に加えて適用されます。

コマンドはユーザが修正したい (commit) ファイルを全て含んだ 作業スペースのルートか、`サーバの作業空間 (see section 2.9 別のマシンのリポジトリ)' で実行されます。ファイルが削除されようとしている場合、現在のディレクトリには そのファイルのコピーは存在しません。ファイルが追加されようとしている場合、 ファイルが復活されているのでない限り、リポジトリに対応するアーカイブファイルは ありません。

格納されようとしているファイルに対応するアーカイブファイルの場所を調べるために、 リポジトリのディレクトリと対応する Attic (see section 2.2.4 The attic) ディレクトリの 両方を調べる必要があるかもしれないことに注意してください。 このコマンドは指定先の枝、コミットメッセージ、コマンドラインオプションを 含め、詳しい commit リクエストの詳細を手に入れることはできません。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.5 ログメッセージの検証

一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために そのメッセージを評価することができます。ログメッセージを検証するための プログラムを指定するために `verifymsg' ファイルを使用することがで きます。このプログラムは入力されたメッセージに必要なフィールドがあるか どうかを調べる簡単なスプリプトでも良いでしょう。

`verifymsg' ファイルは、ログメッセージの雛型を指定するために使う ことのできる `rcsinfo' ファイルと一緒に使用されたときにとても役に 立つことが多いです。

`verifymsg' ファイルは正規表現とコマンド行の雛型から成ります。雛 型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加 されます。

一つ注意しなければならないのは、`ALL' キーワードは使えないという ことです。一行以上合致した場合、最初のものが使われます。これはディレク トリで既定の検証スクリプトを指定して、サブディレクトリで上書きするとき に役に立ちます。

リポジトリ名がこのファイルのどの正規表現にも合致しなければ、 `DEFAULT' が指定されていると、それが使用されます。

検証スクリプトが非零の値で終了すれば、格納は中止されます。

デフォルトの設定では、CVS は検証スクリプトがログメッセージを 変更することを許可しています。これは CVSROOT/config のオプション RereadLogAfterVerify で変更することができます。

`RereadLogAfterVerify=always' か `RereadLogAfterVerify=stat' の場合、ログメッセージは 検証スクリプトが実行された後で、常に再読込されるか、 ログメッセージファイルの状態が変更したときに再読込されるかになります。

他の CVSROOT/config オプションは See section C.12 The CVSROOT/config configuration file

いろいろなクライアント/サーバメソッドで verifymsg スクリプトがクライアントと対話的に動作するのは 良くない考えです。pserver メソッドには `verifymsg' と遠隔地にいるクライアントとが通信をするための プロトコルのサポートがありません。 extserver メソッドでは、CVS プロトコルメッセージと 同じチャネルを使って送られる文字によって CVS が混乱するかもしれません。 より詳しいサーバ/クライアントの設定については 2.9 別のマシンのリポジトリ を 参照してください。さらに、`verifymsg' スクリプトが実行されている 時点で、CVS サーバはリポジトリにロックをかけています。 ここでユーザに制御が渡されたら、他のユーザはリポジトリへのアクセス待ちで 止まってしまうかもしれません。

このオプションは空の要素やデフォルトの値を書き入れるために 修正されるべき rcstemplate を使っているときに役に立つでしょう。 リポジトリの rcstemplate が変更されていて、CVS/Template はまだ 更新されていないけれど、`verifymsg' によって実行される検証 スクリプトによって新しいフォーマットに適応させることができるときにも 有用です。

更新の例にはすべての 'BugID:' を 'DefectID:' に変えるというような ものがあります (これは rcstemplate が最近変更されて、 ユーザのチェックアウトしたディレクトリツリーが古いバージョンの CVS/Template のキャッシュされたコピーを持っているときに役に立ちます)。

更新の他の例としては、'BugID: none' の存在が許可されているかの 検証の後に、それを含む行をログメッセージから削除するというものもあります。

以下は、`verifymsg' ファイルのちょっとしたばかげた例と、それに対 応する `rcsinfo' ファイル、ログメッセージの雛型と検証スクリプトで す。まず、ログメッセージの雛型です。常に bug-id 番号をログメッセージの 最初の行に記録します。ログメッセージの残りのテキストは自由に書いたもの です。以下の雛型ファイルは `/usr/cvssupport/tc.template' にありま す。

 
BugId:

スクリプト `/usr/cvssupoort/bugid.verify' はログメッセージの評価 に使われます。

 
#!/bin/sh
#
#       bugid.verify filename
#
#  Verify that the log message contains a valid bugid
#  on the first line.
#
if sed 1q < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
    exit 0
elif sed 1q < $1 | grep '^BugId:[ ]*none$' > /dev/null; then
    # It is okay to allow commits with 'BugId: none',
    # but do not put that text into the real log message.
    grep -v '^BugId:[ ]*none$' > $1.rewrite
    mv $1.rewrite $1
    exit 0
else
    echo "No BugId found."
    exit 1
fi

`verifymsg' ファイルには以下の行があります:

 
^tc     /usr/cvssupport/bugid.verify

`rcsinfo' ファイルには以下の行があります:

 
^tc     /usr/cvssupport/tc.template

`config' ファイルには以下の行があります:

 
RereadLogAfterVerify=always


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.5.1 Editinfo

注意: `editinfo' 機能は旧式になっています。ログメッセージ の既定のエディタを設定するためには、CVSEDITOR, EDITOR 環境変数 (see section D. CVS に影響する全ての環境変数) か `-e' 広域オプション (see section A.4 広域オプション) を使用してください。ログメッセージを評価する ための `verifymsg' 機能を使うための情報は C.5 ログメッセージの検証 を参照 してください。

いつも同じ形式でログ・メッセージを記録したい場合に、 ログ・メッセージを編集するプログラムを `editinfo' に 指定することができます。 指定するプログラムは、 ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、 エディタを呼び出して、入力されたメッセージが必要項目を 満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。

合致する行が `editinfo' になかった場合、 環境変数 $CVSEDITOR に指定されたエディタを使用します。 この環境変数が設定されていない場合には、 環境変数 $EDITOR に指定されたエディタを代わりにします。 そしてこの環境変数も設定されていない場合は、 既定のものが使われます。1.3.2 変更の格納 参照。

`rcsinfo' にログ・メッセージの雛型を指定すると、 より効果的に `editinfo' を利用できるでしょう。

`editinfo' の各行は、第一項の正規表現、 残りの部分のコマンド行形式から構成されます。 コマンド行の部分には、 プログラム名と適切な数の引数とを記述することができます。 また実行の際には、ログ・メッセージの雛型へのフルパス がコマンド行の最後に与えられます。

`ALL' が利用できないことに注意して下さい。 合致する行が複数あった場合は、最初の行が実行されます。 これは、モジュールの編集スクリプトが設定されていて、 サブディレクトリでは別のものを使用したい場合を考慮しています。

第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。

編集スクリプトが非零で終了した場合は、格納が中止されます。

注意: CVS が別のマシンのリポジトリを利用している場合や、 cvs commit の `-m' または `-F' オプションを 使用した場合、`editinfo' は参照されません。 この問題を解決する良い方法は今のところありません。 代わりに `verifymsg' を使ってください。

C.5.1.1 Editinfo 記述例  editinfo 記述例


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.5.1.1 Editinfo 記述例

次に、ちょっとアホくさい `editinfo' の使用例を、 対応する `rcsinfo'、ログ・メッセージの雛型、 エディタ・スクリプトと併わせて紹介します。 まずログ・メッセージの雛型ですが、 最初の行に必ずバグ番号を記録するように促し、 残りは自由に記述してもらいます。 この雛型は `/usr/cvssupport/tc.template' に置くことにします。

 
BugId:

ログ・メッセージを編集するため、 次のスクリプト `/usr/cvssupport/bugid.edit' を使用します。

 
#!/bin/sh
#
#       bugid.edit filename
#
#  Call $EDITOR on FILENAME, and verify that the
#  resulting file contains a valid bugid on the first
#  line.
if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
$CVSEDITOR $1
until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
do  echo -n  "No BugId found.  Edit again? ([y]/n)"
    read ans
    case ${ans} in
        n*) exit 1;;
    esac
    $CVSEDITOR $1
done

ファイル `editinfo' には次の行を記述します:

 
^tc     /usr/cvssupport/bugid.edit

ファイル `rcsinfo' には次の行を記述します:

 
^tc     /usr/cvssupport/tc.template


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.5.2 管理用ファイル Loginfo

`loginfo' を用いて、 `cvs commit' によるログ情報の送り先を管理します。 各行の第一項には正規表現が記述され、 行の残りの部分はフィルタでなくてはいけません。 変更を加えたディレクトリを $CVSROOT からの相対パスで表わしたものと、 各行の正規表現が合致するかどうか試されます。 合致した場合は、 その行の残りの部分であるフィルタ・プログラムの標準入力に、 ログ情報を与えます。 CVS が broken pipe シグナルで失敗しないために、 フィルタプログラムはログ情報をすべて読み込まなければならない ことに注意してください。

第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。

第一項が `ALL' である行全てが、 最初に合致した正規表現または `DEFAULT' に加えて適用されます。

正規表現が合致する最初の行が実行されます。

ファイル `loginfo' の構文についての記述は See section C.3 格納を支援するファイル.

使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は `%' の後に空白か、単独のフォーマット文字、もしくは分離器 `{' と `}' に囲まれたいくつかのフォーマット文字が続いた物 です。フォーマット文字は:

s
ファイル名
V
古いバージョン番号 (格納前)
v
新しいバージョン番号 (格納後)

フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます (フィールドを分離するコンマはまだ提供されされています。)

例えば、有効なフォーマット文字列は `%', `%s', `%{s}', `%{sVv}' などです。

出力は空白で区切られた語からなる文字列になります。下位互換のために、最 初の語はリポジトリのサブディレクトリになります。残りの語はフォーマット 文字列で要求された情報をコンマで分けたリストです。例えば、 `/u/src/master/yoyodyne/tc' がリポジトリで `%{sVv}' がフォー マット文字列、3つのファイル(ChangeLog, Makefile, foo.c) が 修正されていると、出力は:

 
"yoyodyne/tc ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13"

別の例として、`%{}' ではリポジトリ名のみが作成されます。

注意: CVS が別のマシンのリポジトリを利用している場合、 `loginfo' はクライアント側ではなく、別のマシン (サーバ) 側で実行されます (see section 2.9 別のマシンのリポジトリ)。

C.5.2.1 Loginfo 記述例  loginfo 記述例
C.5.2.2 取得済のコピーを最新に保つ  格納毎にディレクトリを更新


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.5.2.1 Loginfo 記述例

ここで示す `loginfo' ファイルと付属のシェル・スクリプトは、 格納時に次のような動作をします。 まず全てのログ・メッセージを `$CVSROOT/CVSROOT/commitlog' に追記します。 次に全ての管理用ファイル (`CVSROOT' 内) の 格納時のログを `/usr/adm/cvsroot-log' に追記します。 `prog1' ディクトリへの格納は ceder にメールで送られます。

 
ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER
^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
^prog1          Mail -s %s ceder

シェル・スクリプト `/usr/local/bin/cvs-log' の内容:

 
#!/bin/sh
(echo "------------------------------------------------------";
 echo -n $2"  ";
 date;
 echo;
 cat) >> $1


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.5.2.2 取得済のコピーを最新に保つ

あるディレクトリがリポジトリで管理されている場合、 そのディレクトリを常に最新にしておきたい事があるでしょう。 例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、 CVS で保守されたウェブ・サイトのファイルを 格納毎に更新したい場合などです。

これを実現するため、 cvs update を実行するように `loginfo' を設定します。 しかし単純に設定するとロックの問題が発生するので、 cvs update をバックグラウンドで実行する必要があります。 Unix での例を以下に示します (実際は一行です):

 
^cyclic-pages		(date; cat; (sleep 2; cd /u/www/local-docs;
 cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1

リポジトリ中の cyclic-pages で始まるディレクトリに ファイルが格納された時、 取得済みのディレクトリ `/u/www/local-docs' を更新します。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.6 管理用ファイル rcsinfo

`rcsinfo' には、格納時にログ・メッセージを 書き込むための書式を指定します。`rcsinfo' の 構文は `verifymsg', `commitinfo', `loginfo' とほぼ同じです。See section C.3.1 共通の構文. しかし他のファイルと異なり、 第二項はコマンド行形式ではありません。 正規表現の次の部分は、ログ・メッセージの雛型を記した ファイルへのフルパス名でなくてはいけません。

第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。

第一項が `ALL' である行全てが、 最初に合致した正規表現または `DEFAULT' に加えて適用されます。

ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。 しかし、`cvs commit -m message' や `cvs commit -f file' によってログ・メッセージを指定した場合、 こちらが優先されます。

`rcsinfo' ファイルの記述例は See section C.5 ログメッセージの検証.

CVS が別のマシンのリポジトリを利用している場合、 最初に作業ディレクトリを取り出した時に `rcsinfo' に 記述されていた雛型が使用され、以後変更されません。 `rcsinfo' や雛型を変更した場合には、 新たに作業ディレクトリを取り出す必要があります。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.7 Taginfo

`taginfo' ファイルは誰かが tagrtag コマンドを 実行したときに実行するプログラムを定義します。 `taginfo' ファイルは各行が正規表現と実行されるコマンドで 構成された管理ファイルの標準形式 (see section C.3.1 共通の構文) になっています。 コマンドに渡される引数は順番に tagname, operation (tag には add, tag -F には mov, tag -d には del), repository, と残っている filename revision の対です。 フィルタが非零の値で終了するとタグは異常終了します。

`taginfo' ファイルを使って tagrtag コマンドを ログ収集する例です。`taginfo' ファイルには以下を書きます:

 
ALL /usr/local/cvsroot/CVSROOT/loggit

`/usr/local/cvsroot/CVSROOT/loggit' は以下の書かれたスクリプトです:

 
#!/bin/sh
echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.8 cvsignore でファイルを無視する

作業コピーの中に、いつも決まった名前のファイルがあるけれど、 CVS の管理下には置きたくないという場合がよくあります。 例えば、ソースのコンパイル時に生成される オブジェクト・ファイルなどです。 `cvs update' を実行した場合には通常、 これらのファイル各々に対して、 知らないファイルがあったと出力されます (see section A.17.2 update の出力)。

CVS は、update, import, release の実行時に無視すべきファイルのリストを (sh(1) のファイル名形式で) 保持します このリストは、以下の方法で構築されます。

上記五つのファイル内で単感嘆符 (`!') を記述すると、 無視するファイルのリストが空になります。 これは、通常は CVS に無視されるファイルを、 リポジトリに格納したい場合に使用します。

cvs import に `-I !' を指定すると、全てを持ち込み、それは 素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ るのがわかると思います。もし配布に `.cvsignore' ファイルがあると、 そのファイルの形式は `-I !' が指定されたとしても実行されます。唯 一の対策は持ち込むために、`.cvsignore' ファイルを消去することです。 これはやっかいなので、将来は `-I !' はそれぞれのディレクトリの `.cvsignore' ファイルを上書きするように修正されるかもしれません。

無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ れぞれの行が続いたものであることに注意してください。これは空白のある ファイル名を指定する綺麗な方法を提供しませんが、`foo bar' という 名前のファイルに合致させるために `foo?bar' のような対策を使うこと ができます (`fooxbar' などにも合致します)。また、現在は註釈を指定 する方法が無いことにも注意してください。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.9 checkoutlist ファイル

CVS を使って自分自身のファイルを `CVSROOT' ディレクトリに維 持することは役に立つかもしれません。例えば、`logcommit.pl' という スクリプトがあり、それは以下の行を `commitinfo' 管理ファイルに含 めることにより実行するとしましょう:

 
ALL $CVSROOT/CVSROOT/logcommit.pl

CVS で `logcommit.pl' を維持するためには、以下の行を `checkoutlist' 管理ファイルに追加します:

 
logcommit.pl

`checkoutlist' の形式は、一行につき CVS を使って維持したいそ れぞれのファイルのファイル名を書いたものです。その後には省略可能な、 空白と格納後にファイルが CVSROOT にチェックアウトできなかったときの エラーメッセージを書くこともできます。

 
logcommit.pl	Could not update CVSROOT/logcommit.pl.

このように `checkoutlist' を設定した後で、そこに一覧として挙げら れているファイルは CVS の元からの管理ファイルと同じように機能しま す。例えば、そのファイルの一つを格納するときは、次のようなメッセージを 得るでしょう:

 
cvs commit: Rebuilding administrative file database

そして、`CVSROOT' ディレクトリに取り出されているコピーも更新され ます。

`passed' (see section 2.9.3.1 パスワード認証のためのサーバの設定) を `checkoutlist' に載せることはセキュリティに関する理由により 推奨されないことに注意してください。

`checkoutlist' で提供されるよりも一般的な文脈で取り出したコピーを 維持するための情報は、C.5.2.2 取得済のコピーを最新に保つ を参照してくだ さい。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.10 ファイル history

ファイル `$CVSROOT/CVSROOT/history' は、 history コマンドのためにログ情報を記録します (see section A.12 history--ファイルと使用者の状態を表示)。 ログを記録したい場合には、このファイルを作成する必要があります。 cvs init でリポジトリを準備すると、 自動的に作成されます (see section 2.6 リポジトリの作成)。

`history' ファイルの書式を説明したものは、 CVS ソース・コード内の註釈しかありません。 CVS の将来のリリースで書式が変更されるかも知れないので、 このファイルは必ず cvs history を通して利用して下さい。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.11 管理用ファイルにおける変数展開

管理用ファイルを記述するときに、CVS の動作環境についての 色々な情報を利用したい場合があると思います。 ここでは、その実現方法を幾つか紹介します。

CVS を実行した人物のホーム・ディレクトリを (環境変数 HOME から) 参照するには、 `/' または行端の直前に `~' を記述します。 同様に user のホーム・ディレクトリは、 `~user' と記述します。 これらの変数はサーバ側で展開されるため、pserver (see section 2.9.3 パスワード認証による直接接続) を用いる場合には正しく展開されません。 この場合、CVS を実行する人物が動作を変更できるように、 ユーザ変数 (下記参照) を用いると良いでしょう。

CVS 内部の情報を参照したい場合もあると思います。 CVS の内部変数は ${variable} という書式で参照できます。 この variable は文字で始まり、 アルファベットと `_' から構成されます。 variable に続く文字がアルファベットや `_' でない場合は、 `{' と `}' とを省略しても構いません。 参照可能な CVS の内部変数には次のようなものがあります:

CVSROOT
CVS が使用中のルート・ディレクトリへの絶対パスです。 ルート・ディレクトリのいろいろな指定方法は、See section 2. リポジトリ。 内部変数にあるのはディレクトリのみで、アクセスメソッドの情報は何も ないことに注意してください。

RCSBIN
CVS 1.9.18 以前では、これは CVS が RCS プログラムを探す 場所を指定していました。CVS はもう RCS プログラムを実行しま せんので、今はこの内部変数を指定するとエラーになります。

CVSEDITOR
EDITOR
これらは CVS が使用するエディタを示し、 全て同じ値に展開されます。 指定方法の説明は、See section A.4 広域オプション.

USER
CVS を実行する人物の (CVS サーバでの) 名前に展開されます。 同名の環境変数と間違えないでください。

ユーザ変数を用いれば、CVS を実行する人物が、 管理用ファイルで用いる値を自由に設定できます。 ユーザ変数は、管理用ファイルに ${=variable} と記述します。 ユーザ変数の設定は、CVS の広域オプション `-s' に、 引数 variable=value を続けます。 このオプションは `.cvsrc' に記述しておくと良いでしょう (see section A.3 既定オプションと ~/.cvsrc ファイル)。

例として、実験用ディレクトリを管理用ファイルから参照するため、 ユーザ変数 TESTDIR を用います。それから、以下のように CVS を起動し、

 
cvs -s TESTDIR=/work/local/tests

管理ファイルに sh ${=TESTDIR}/runtests と書いてあれば、文字列 は sh /work/local/tests/runtests に展開されます。

`$' が上記以外の解釈を受けることはありません。 また `$' 自身を表現する別の方法も用意されてないため、 `$' という文字を引用することはできません。

管理ファイルに渡される環境変数は:

CVS_USER
存在する場合、ユーザから提供された、CVS 特有のユーザ名で (現在は pserver アクセスメソッドのみ)、そうでない場合は空文字列です。 (CVS のユーザ名を `$CVSROOT/CVSROOT/passwd' を使って システムユーザ名にマップしている場合、CVS_USERUSER は 違うものになる可能性があります。)

LOGNAME
システムユーザのユーザ名です。

USER
LOGNAME と同じです。 同名の内部変数と間違えないでください。


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

C.12 The CVSROOT/config configuration file

管理ファイル `config' は CVS の振舞いに影響するいろいろな雑 多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ れません。`#' で始まる行は註釈と解釈されます。 他の行はキーワード、`='、値からなります。この構文は厳密であること に注意してください。余分な空白やタブは使えません。

現在定義されているキーワードは:

RCSBIN=bindir
CVS 1.9.12 から 1.9.18 まで、この設定は bindir ディレクトリ にある RCS プログラムを探すように CVS に教えるために使われて いました。現在のバージョンの CVS は RCS プログラムを実行しま せん。互換性のためのこの設定は可能になってますが、何も起こりません。

SystemAuth=value
value が `yes' であれば、pserver は使用者を調べるときに、 `CVSROOT/passwd' に見つからなければ、システムのデータベースを調べ にいきます。`no' であれば、全ての使用者は `CVSROOT/passwd' に存在している必要があります。既定値は `yes' です。pserver につい ては、2.9.3 パスワード認証による直接接続 を参照してください。

PreservePermissions=value
リポジトリでの、特別なデバイスファイル、シンボリック・リンク、ファイル 使用許可、所有権に関する機能を使用可にします。既定値は `no' です。 このキーワード使用の完全な意味は See section 15. 特別なファイル.

TopLevelAdmin=value
`checkout' コマンドが取り出されたディレクトリ中に作成される `CVS' に加えて、新しい作業ディレクトリの最上位にも `CVS' ディ レクトリを作成するように修正します。既定値は `no' です。

このオプションは、取り出されたサブディレクトリではなく、最上位のディレ クトリで多くのコマンドを実行するときに便利です。そこに作成される `CVS' ディレクトリにより、それぞれのコマンドに CVSROOT を 指定する必要がなくなります。`CVS/Template' ファイルの場所も提供し ます (see section 2.3 リポジトリでのデータの保存方法)。

LockDir=directory
CVS ロックファイルをリポジトリ中のディレクトリでなく、directory に置きます。これは使用者にリポジトリから読み込みをさせたいけれど、リポ ジトリには書き込み許可を与えたくなく、directory ディレクトリのみ に書き込み許可を与えたいときに便利です。 非常に速いメモリ中のファイルシステムを使ってリポジトリのロックとロックの 解除を速くすることもできます。 directory は作成する必要 がありますが、必要ならば CVS は directory のサブディレクトリを作 成します。CVS のロックに関する情報は 10.5 同時に CVS の実行を試みる複数の開発者 を参照してくだ さい。

LockDir オプションを使用可にする前に、CVS 1.9 やそれ以前のもののコピー を追跡して消去したことを確認してください。そのようなバージョンは LockDir をサポートしていませんし、それをサポートしていないというエラー を出すこともありません。結果として、もしこのようなことが起こってしまえ ば、CVS の何人かの使用者はある場所にロックを置き、他は別の場所に置くと いうことになり、リポジトリが壊れてしまう可能性があります。CVS 1.10 は LockDir をサポートしていませんが、LockDir が使用されているリポジトリで 実行されると警告を印字します。

LogHistory=value
`CVSROOT/history' ファイルにログ収集される内容を制御します (see section A.12 history--ファイルと使用者の状態を表示)。デフォルトは `TOEFWUPCGMAR' (`all' と同じです) はすべてのトランザクションをログ収集します。 デフォルトのどんなサブセットも指定することができます。 (例えば、`*,v' ファイルを修正するトランザクションだけを ログ収集するには、`LogHistory=TMAR' を使います。)

RereadLogAfterVerify=value
`commit' コマンドを修正して、CVS が `verifymsg' で指定された プログラムを実行した後にログメッセージを再読込するようにします。 value はログメッセージが常に再読込されることを示す `yes' と `yes' か、決して再読込されないことを示す `no' と `never' か、 再読込の前にファイルシステムの `stat()' 関数を使って変更があるかどうかを 調べる `stat' (下の警告を参照のこと) のどれかを指定することができます。 デフォルトの値は `always' です。

注意: 'stat' モードにすると格納されるディレクトリ毎に最大で 1秒 CVS を停止させることがあります。これは IO や CPU に負荷のかかる 動作ではありませんが、大規模リポジトリでの使用は推奨されていません

verifymsg の詳しい使い方は See section C.5 ログメッセージの検証 参照。


[ << ] [ >> ]           [Top] [Contents] [Index] [ ? ]

This document was generated by Yoshiki Hayashi on October, 13 2004 using texi2html