リポジトリ中のディレクトリ `$CVSROOT/CVSROOT' に、 CVS を支援する多くのファイルが置かれます。 これらのファイルが無いと CVS の能力が制限されてしまいますが、 適切に設定すれば種々の操作を簡略化することができます。 これらを編集する方法は section 管理用ファイルの紹介 参照。
これらの内で最も重要なファイルは `modules' で、 リポジトリ内のモジュールを定義します。
管理用ファイル `modules' には、
ソース・コードの集合体の名前の定義を記述します。
新たな定義を CVS に理解させるには、
CVS を用いてファイル `modules' を修正して下さい
(add
, commit
など普通のコマンドを使用します)。
ファイル `modules' には、モジュールの定義だけでなく、 空白行や註釈行 (`#' で始まる行) も記述できます。 またバックスラッシュ (`\') を行の最後に加えて、 長い行を次の行にまで続けることができます。
モジュールには3つの種類があります: 別名モジュール、一般モジュール、ア ンドモジュールです。それらの違いはリポジトリのファイルの作業ディレクト リへの割り付け方法です。以下の全ての例では、最上位のリポジトリには `first-dir' というディレクトリがあり、そこには `file1' と `file2' というファイルがあり、`sdir' というディレクトリがあ ります。`first-dir/sdir' には `sfile' というファイルがありま す。
別名モジュールが一番簡単な種類のモジュールです:
mname -a aliases...
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
mname [ options ] dir [ files... ]
$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 $
モジュール定義は定義に `&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 の将来のリリースでは 修正されているかもしれません。
別名モジュールは、除外されるべき各ディレクトリ名の前に驚嘆符 (`!') を付けることで、特定のディレクトリを除外することができます。
例えば、モジュールファイルが以下のようになっていると:
exmodule -a !first-dir/sdir first-dir
モジュール `exmodule' を取り出すと、サブディレクトリ `first-dir/sdir' にあるファイル以外の全てを取り出します。
標準モジュールとアンドモジュールのどちらもオプションを含むことができ、 それはモジュールの追加情報を提供します。
-d name
-e prog
-i prog
-o prog
-s status
-t prog
rtag
でタグ付けされたときに常に実行され
るプログラム prog を指定します。prog は2つの引数と共に実行
されます: モジュール名と rtag
に指定されたタグ名です。
tag
が行われたときは実行されません。一般的に、taginfo の方が良
い解決法です (see section ログ方法を使用者自身が設定する)。
-u prog
"プログラムオション" プログラムがどのように実行されているのかを見る ために section modules ファイルの "プログラムオプション" のプログラムがどのように実行されるか も参照した方が良いでしょう。
checkout, rtag, export ではプログラムはサーバ側が基で、以下のものが適 用されます:-
遠隔接続方法 (pserver, ext など) を使っているときは、CVS はこのプログ ラムをサーバ上で一時ディレクトリから実行します。プログラムはパス上で検 索されます。
"ローカル接続" 使っているときは (ローカルや、遠隔の NFS ファイルシス テムを使用しているとき、すなわちリポジトリがパスのみに設定されていると き)、プログラムはもし見つかれば新しく取り出されたディレクトリから実行 され、そうでない場合は代わりにパスが検索されます。
commit と update プログラムはローカルが基で、以下のように実行されます:-
プログラムは常にローカルで実行されます。これらのオプションが modules管 理ファイルで更新された場合は再びディレクトリを checkout する必要があり ます。ファイル CVS/Checkin.prog はオプション `-i' が modules ファイル で設定されており、ファイル CVS/Update.prog は同様に `-u' が設定されて います。プログラムは常にクライアント側の取り出されたコピーの最上位から 実行されます。これも、プログラムはまず取り出されたコピー上を探し、それ からパスを使って検索されます。
commit と update はローカルリポジトリ接続を使っているとき のみ に動作することにも注意してください---pserver や他の遠隔 CVS からソース が取り出されているときは、そのファイルは単純に作成されません。
プログラムは全て操作がちゃんと終了した後に実行されます。
Wrapper とは操作中のファイル名に基づいて設定を制御することを可能にする CVS の機能のことです。設定は、バイナリ・ファイルには `-k' で、 マージできないテキスト・ファイルには `-m' です。
また、非バイナリ・ファイルを更新するときの
マージ方針について記述するオプション `-m' があります。
MERGE
は CVS が通常用いる方法です:
ファイルをマージしようとすることを意味します。COPY
は cvs
update
はファイルのマージを拒否するという意味で、`-kb' でバイナ
リとして指定されたファイルにもそうなります (ただし、バイナリとして指定
されていれば、`-m 'COPY'' を指定する必要はありません。
CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する
ために使用者が CVS の外の機構を使用することを要求します。
警告: CVS 1.9 以前では COPY
を使わないでくださ
い---それらのバージョンの CVS はあるバージョンを別の物の上にコピー
し、以前の内容を消し去ってしまいます。
Wrapper オプション `-m' は更新時のマージ方針にのみ影響し、
ファイルの格納方法には影響しません。
バイナリ・ファイルの詳細は section バイナリ・ファイルの扱い 参照。
管理用ファイル `cvswrappers' の基本的な書式:
ワイルドカード [オプション 値][オプション 値]... 利用できるオプションを以下に挙げます。 -m マージ方針 値: MERGE か COPY -k キーワード展開 値: 置換モード 値は以下のように単引用符で囲みます。
例えば、`.exe' で終わるファイルをバイナリとして扱いながら、 ディレクトリを取り入れます:
cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
ファイル `modules' 中の `-i' フラグは、 ファイルが格納された時に特定のプログラムを実行するのに用いられます (see section The modules file)。 この節で説明するファイルは、 ファイルの格納時にプログラムを実行するための、 より柔軟な方法を提供します。
格納時に実行できるプログラムは三種類に分けられます。 これらのプログラムはリポジトリ中のファイルに記述されます。 次に示すのは、 ファイル名と、対応するプログラムに必要な機能を示したものです。
`commitinfo', `loginfo', `rcsinfo', `editinfo', `verifymsg', などのような管理ファイルには共通の書式があります。 各ファイルの目的は後述します。 ここでは共通の構文について説明します。
空白行は無視されます。 また `#' という文字で始まる行は註釈行として扱われます。 残念ながら、長い行を複数行に分割することはできません。
リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。 行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。
`cvs commit' を実行する直前に必ず実行したいプログラムを、 ファイル `commitinfo' に記述します。 修正、追加、削除されたファイルを格納しても良いかどうか、 このプログラムを用いて格納前に判断します。 例えば、変更されたファイルがあなたのサイトの コーディング・スタイルの標準に従っているか確かめることもできます。
前に書いたように、`commitinfo' の各行は、第一項の正規表現、 残りの部分のコマンド行形式から構成されます。 コマンド行の部分には、 プログラム名と適切な数の引数とを記述することができます。 また実行の際には、リポジトリのフルパスと 格納しようとするファイル名 (追加, 削除, 修正されたファイル名) がコマンド行の最後に与えられます。
リポジトリ中のディレクトリと正規表現とが合致する最初の行が実行されます。 そしてコマンドが非零で終了した場合は、格納が中止されます。
第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。
第一項が `ALL' である行全てが、 最初に合致した正規表現または `DEFAULT' に加えて適用されます。
注意: CVS が別のマシンのリポジトリを利用している場合、 `commitinfo' に記述された行は、 クライアント側ではなく別のマシン (サーバ) 側で実行されます (see section 別のマシンのリポジトリ)。
一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために そのメッセージを評価することができます。ログメッセージを検証するための プログラムを指定するために `verifymsg' ファイルを使用することがで きます。このプログラムは入力されたメッセージに必要なフィールドがあるか どうかを調べる簡単なスプリプトでも良いでしょう。
`verifymsg' ファイルは、ログメッセージの雛型を指定するために使う ことのできる `rcsinfo' ファイルと一緒に使用されたときにとても役に 立つことが多いです。
`verifymsg' ファイルは正規表現とコマンド行の雛型から成ります。雛 型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加 されます。
一つ注意しなければならないのは、`ALL' キーワードは使えないという ことです。一行以上合致した場合、最初のものが使われます。これはディレク トリで既定の検証スクリプトを指定して、サブディレクトリで上書きするとき に役に立ちます。
リポジトリ名がこのファイルのどの正規表現にも合致しなければ、 `DEFAULT' が指定されていると、それが使用されます。
検証スクリプトはログメセージを変更できないことに注意してください。単に 受け入れるか拒否するかのどちらかです。
以下は、`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 head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then exit 0 else echo "No BugId found." exit 1 fi
`verifymsg' ファイルには以下の行があります:
^tc /usr/cvssupport/bugid.verify
`rcsinfo' ファイルには以下の行があります:
^tc /usr/cvssupport/tc.template
注意: `editinfo' 機能は旧式になっています。ログメッセージ
の既定のエディタを設定するためには、EDITOR
環境変数
(see section CVS に影響する全ての環境変数) か `-e' 広域オプション
(see section 広域オプション) を使用してください。ログメッセージを評価する
ための `verifymsg' 機能を使うための情報は section ログメッセージの検証 を参照
してください。
いつも同じ形式でログ・メッセージを記録したい場合に、 ログ・メッセージを編集するプログラムを `editinfo' に 指定することができます。 指定するプログラムは、 ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、 エディタを呼び出して、入力されたメッセージが必要項目を 満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。
合致する行が `editinfo' になかった場合、
環境変数 $CVSEDITOR
に指定されたエディタを使用します。
この環境変数が設定されていない場合には、
環境変数 $EDITOR
に指定されたエディタを代わりにします。
そしてこの環境変数も設定されていない場合は、
既定のものが使われます。section 変更の格納 参照。
`rcsinfo' にログ・メッセージの雛型を指定すると、 より効果的に `editinfo' を利用できるでしょう。
`editinfo' の各行は、第一項の正規表現、 残りの部分のコマンド行形式から構成されます。 コマンド行の部分には、 プログラム名と適切な数の引数とを記述することができます。 また実行の際には、ログ・メッセージの雛型へのフルパス がコマンド行の最後に与えられます。
`ALL' が利用できないことに注意して下さい。 合致する行が複数あった場合は、最初の行が実行されます。 これは、モジュールの編集スクリプトが設定されていて、 サブディレクトリでは別のものを使用したい場合を考慮しています。
第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。
編集スクリプトが非零で終了した場合は、格納が中止されます。
注意: CVS が別のマシンのリポジトリを利用している場合や、
cvs commit
の `-m' または `-F' オプションを
使用した場合、`editinfo' は参照されません。
この問題を解決する良い方法は今のところありません。
代わりに `verifymsg' を使ってください。
次に、ちょっとアホくさい `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
`loginfo' を用いて、
`cvs commit' によるログ情報の送り先を管理します。
各行の第一項には正規表現が記述され、
行の残りの部分はフィルタでなくてはいけません。
変更を加えたディレクトリを
$CVSROOT
からの相対パスで表わしたものと、
各行の正規表現が合致するかどうか試されます。
合致した場合は、
その行の残りの部分であるフィルタ・プログラムの標準入力に、
ログ情報を与えます。
第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。
第一項が `ALL' である行全てが、 最初に合致した正規表現または `DEFAULT' に加えて適用されます。
正規表現が合致する最初の行が実行されます。
ファイル `loginfo' の構文についての記述は See section 格納を支援するファイル.
使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は `%' の後に空白か、単独のフォーマット文字、もしくは分離器 `{' と `}' に囲まれたいくつかのフォーマット文字が続いた物 です。フォーマット文字は:
フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます (フィールドを分離するコンマはまだ提供されされています。)
例えば、有効なフォーマット文字列は `%', `%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 別のマシンのリポジトリ)。
ここで示す `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
あるディレクトリがリポジトリで管理されている場合、 そのディレクトリを常に最新にしておきたい事があるでしょう。 例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、 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' を更新します。
`rcsinfo' には、格納時にログ・メッセージを 書き込むための書式を指定します。`rcsinfo' の 構文は `verifymsg', `commitinfo', `loginfo' とほぼ同じです。See section 共通の構文. しかし他のファイルと異なり、 第二項はコマンド行形式ではありません。 正規表現の次の部分は、ログ・メッセージの雛型を記した ファイルへのフルパス名でなくてはいけません。
第一項が `DEFAULT' である行の記述は、リポジトリ名が ファイル中のどの正規表現にも合致しない場合に適用されます。
第一項が `ALL' である行全てが、 最初に合致した正規表現または `DEFAULT' に加えて適用されます。
ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。 しかし、`cvs commit -m message' や `cvs commit -f file' によってログ・メッセージを指定した場合、 こちらが優先されます。
`rcsinfo' ファイルの記述例は See section ログメッセージの検証.
CVS が別のマシンのリポジトリを利用している場合、 最初に作業ディレクトリを取り出した時に `rcsinfo' に 記述されていた雛型が使用され、以後変更されません。 `rcsinfo' や雛型を変更した場合には、 新たに作業ディレクトリを取り出す必要があります。
作業コピーの中に、いつも決まった名前のファイルがあるけれど、 CVS の管理下には置きたくないという場合がよくあります。 例えば、ソースのコンパイル時に生成される オブジェクト・ファイルなどです。 `cvs update' を実行した場合には通常、 これらのファイル各々に対して、 知らないファイルがあったと出力されます (see section update の出力)。
CVS は、update
, import
, release
の実行時に無視すべきファイルのリストを
(sh(1) のファイル名形式で) 保持します
このリストは、以下の方法で構築されます。
RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$ *.old *.bak *.BAK *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core
$CVSIGNORE
の内容全てがリストに付加されます。
上記五つのファイル内で単感嘆符 (`!') を記述すると、 無視するファイルのリストが空になります。 これは、通常は CVS に無視されるファイルを、 リポジトリに格納したい場合に使用します。
cvs import
に `-I !' を指定すると、全てを持ち込み、それは
素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん
でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ
るのがわかると思います。もし配布に `.cvsignore' ファイルがあると、
そのファイルの形式は `-I !' が指定されたとしても実行されます。唯
一の対策は持ち込むために、`.cvsigonre' ファイルを消去することです。
これはやっかいなので、将来は `-I !' はそれぞれのディレクトリの
`.cvsignore' ファイルを上書きするように修正されるかもしれません。
無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ れぞれの行が続いたものであることに注意してください。これは空白のある ファイル名を指定する綺麗な方法を提供しませんが、`foo bar' という 名前のファイルに合致させるために `foo?bar' のような対策を使うこと ができます (`fooxbar' などにも合致します)。また、現在は註釈を指定 する方法が無いことにも注意してください。
CVS を使って自分自身のファイルを `CVSROOT' ディレクトリに維 持することは役に立つかもしれません。例えば、`logcommit.pl' という スクリプトがあり、それは以下の行を `commitinfo' 管理ファイルに含 めることにより実行するとしましょう:
ALL $CVSROOT/CVSROOT/logcommit.pl
CVS で `logcommit.pl' を維持するためには、以下の行を `checkoutlist' 管理ファイルに追加します:
logcommit.pl
`checkoutlist' の形式は、一行につき CVS を使って維持したいそ れぞれのファイルのファイル名を書いたものです。
このように `checkoutlist' を設定した後で、そこに一覧として挙げら れているファイルは CVS の元からの管理ファイルと同じように機能しま す。例えば、そのファイルの一つを格納するときは、次のようなメッセージを 得るでしょう:
cvs commit: Rebuilding administrative file database
そして、`CVSROOT' ディレクトリに取り出されているコピーも更新され ます。
`passed' (see section パスワード認証のためのサーバの設定) を `checkoutlist' に載せるうことはセキュリティに関する理由により 推奨されないことに注意してください。
`checkoutlist' で提供されるよりも一般的な文脈で取り出したコピーを 維持するための情報は、section 取得済のコピーを最新に保つ を参照してくだ さい。
ファイル `$CVSROOT/CVSROOT/history' は、
history
コマンドのためにログ情報を記録します
(see section history---ファイルと使用者の状態を表示)。
ログを記録したい場合には、このファイルを作成する必要があります。
cvs init
でリポジトリを準備すると、
自動的に作成されます (see section リポジトリの作成)。
`history' ファイルの書式を説明したものは、
CVS ソース・コード内の註釈しかありません。
CVS の将来のリリースで書式が変更されるかも知れないので、
このファイルは必ず cvs history
を通して利用して下さい。
管理用ファイルを記述するときに、CVS の動作環境についての 色々な情報を利用したい場合があると思います。 ここでは、その実現方法を幾つか紹介します。
CVS を実行した人物のホーム・ディレクトリを
(環境変数 HOME
から) 参照するには、
`/' または行端の直前に `~' を記述します。
同様に user のホーム・ディレクトリは、
`~user' と記述します。
これらの変数はサーバ側で展開されるため、pserver
(see section パスワード認証による直接接続) を用いる場合には正しく展開されません。
この場合、CVS を実行する人物が動作を変更できるように、
ユーザ変数 (下記参照) を用いると良いでしょう。
CVS 内部の情報を参照したい場合もあると思います。
CVS の内部変数は ${variable}
という書式で参照できます。
この variable は文字で始まり、
アルファベットと `_' から構成されます。
variable に続く文字がアルファベットや `_' でない場合は、
`{' と `}' とを省略しても構いません。
参照可能な CVS の内部変数には次のようなものがあります:
CVSROOT
RCSBIN
CVSEDITOR
VISUAL
EDITOR
USER
ユーザ変数を用いれば、CVS を実行する人物が、
管理用ファイルで用いる値を自由に設定できます。
ユーザ変数は、管理用ファイルに ${=variable}
と記述します。
ユーザ変数の設定は、CVS の広域オプション `-s' に、
引数 variable=value
を続けます。
このオプションは `.cvsrc' に記述しておくと良いでしょう
(see section 既定オプションと ~/.cvsrc ファイル)。
例として、実験用ディレクトリを管理用ファイルから参照するため、
ユーザ変数 TESTDIR
を用います。それから、以下のように CVS
を起動し、
cvs -s TESTDIR=/work/local/tests
管理ファイルに sh ${=TESTDIR}/runtests
と書いてあれば、文字列
は sh /work/local/tests/runtests
に展開されます。
`$' が上記以外の解釈を受けることはありません。 また `$' 自身を表現する別の方法も用意されてないため、 `$' という文字を引用することはできません。
管理ファイル `config' は CVS の振舞いに影響するいろいろな雑 多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ れません。`#' で始まる行は註釈と解釈されます。 他の行はキーワード、`='、値からなります。この構文は厳密であること に注意してください。余分な空白やタブは使えません。
現在定義されているキーワードは:
RCSBIN=bindir
SystemAuth=value
PreservePermissions=value
TopLevelAdmin=value
CVSROOT
を
指定する必要がなくなります。`CVS/Template' ファイルの場所も提供し
ます (see section リポジトリでのデータの保存方法)。
LockDir=directory
Go to the first, previous, next, last section, table of contents.