| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
作業ファイルを編集している間は、 いつでも `cvs status' や `cvs log' を使って そのファイルの状態を調べることができます。 しかし開発環境から取り出した場合は、 各ファイルのリビジョンを識別するのが難しくなります。
CVS は、キーワード置換 (keyword substitution)
(もしくはキーワード展開 (keyword expansion))
と呼ばれる機構により、ファイルの識別を補助します。
ファイル中に $keyword$,
$keyword:...$ といった書式で
埋め込まれた文字列を、ファイルを取り出すときに
$keyword:value$ といった書式の文字列に置き換えます。
| 12.1 キーワード一覧 | キーワード | |
| 12.2 キーワードの使用 | ||
| 12.3 置換を止めるには | ||
| 12.4 置換モード | ||
| 12.5 キーワード $Log$ の問題点 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
これはキーワードの利用の一覧です:
$Author$
$Date$
$Header$
$Id$
$Header$ と同じです。
$Name$
cvs co -r
first を実行すると、キーワードを `Name: first' に展開します。
$Locker$
cvs admin -l が使われていなければ
それが普通です。)
$Log$
$Log:...$ の次の行に挿入します。
それぞれの新しい行には $Log キーワードの前にあるものと
同じ文字列が付きます。例えば、ファイルが以下のようになっているとします。
/* Here is what people have been up to: * * $Log: frob.c,v $ * Revision 1.1 1997/01/03 14:23:51 joe * Add the superfrobnicate option * */ |
そうすると、$Log を展開するときに追加される行はその前に
` * ' が付きます。以前のバージョンの CVS、RCS と違って、
RCS ファイル の 註釈符 (comment leader) は使用されま
せん。
$Log キーワードは、
ソース・ファイルに全てのログを残したい場合には便利ですが、
問題点も幾つかあります (see section 12.5 キーワード $Log$ の問題点)。
$RCSfile$
$Revision$
$Source$
$State$
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
キーワードを使いたい場合は、$Id$ などの適当な文字列を
ファイルに記述してから格納するだけです。
CVS は格納操作の一環として自動的に
(正確には commit の後に自動的に実行される update の一環として)
文字列を展開します。
$Id$ 文字列をソースファイルに入れて、生成されるファイル
にそれが渡されるようにするのはよくあることです。例えば、コンピュータプ
ログラムのソースコードを管理していれば、その文字列を含むように初期化さ
れている変数を入れるでしょう。またバイナリ中に直接文章を埋め込むために
#pragma ident 命令が使用できるコンパイラもあります。もしくは、
文書管理システムが生成されたファイルに文字列を渡す方法を提供するかもし
れません。
ident コマンド (RCS パッケージの一部) を使用して、
ファイルからキーワードとその値を抜き出すことができます。
もちろんテキスト・ファイルにも使えますが、
バイナリ・ファイルからキーワードを抜き出したいときに非常に便利です。
$ ident samp.c
samp.c:
$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
$ gcc samp.c
$ ident a.out
a.out:
$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
|
別のリビジョン管理システムとして有名なものに SCCS があります。
SCCS には、ident と非常によく似た
同じ用途のコマンド what が含まれます。
RCS を持たないサイトの多くは SCCS を使っています。
what コマンドは @(#) という文字列を探すため、
両方のコマンドに対応するキーワードを含めるのは簡単です。
キーワードの前に、
簡単な SCCS の魔法の呪文を唱えるだけで良いのです:
static char *id="@(#) $Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $"; |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
キーワード置換にも欠点があります。 ファイル中に表われる文字列 `$'Author$ は、 RCS によってキーワードと見倣されます。 この文字列を `$'Author: ceder $ などと解釈させずに、 そのまま使いたい事があるでしょう。
不幸なことに、選択的にキーワード置換を止めることはできません。 `-ko' によって完全にキーワード置換を止めることができます (see section 12.4 置換モード)。
RCS キーワードが最終製品に現われるとしても、
ソース・ファイル中には使いたくない場合が多くあります。
例えばこのマニュアルのソースには `$'Author$ ではなく、
`$@i{'{}Author$} と記述しています。
nroff や troff であれば、
ヌル文字である \& をキーワード中に埋め込めば
同様の効果を発揮します。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
各ファイルには既定の置換モードが設定されており、
作業ディレクトリの各ファイルの置換モードも別々に設定できます。
前者は cvs add や cvs admin に
オプション `-k' を付けて設定します。
後者は cvs checkout や cvs update に
オプション `-k' や `-A' を付けて設定します。
cvs diff にも `-k' オプションがあります。
例が幾つかありますので、9. バイナリ・ファイルの扱い と 5.10 マージとキーワード 参照。
利用できるモードを以下に示します:
Revision に対して
$Revision: 5.7 $ が生成されます。
cvs admin -l が使用されているときだけ関
係があります。
Revision に対して、
$Revision: 5.7 $ ではなく、
$Revision$ が生成されます。
このオプションは、リビジョン間の違いを比較する時、
キーワードによる違いを無視するのに便利です (see section 5.10 マージとキーワード)。
Revision に対して、
$Revision: 5.7 $ ではなく、
ファイルが格納された時の文字列である
$Revision: 1.1 $ が生成されます。
Revision に対して、
$Revision: 5.7 $ ではなく、
5.7 が生成されます。
これは、$Revision: $ といった、
キーワード識別子を除くのが困難な
プログラミング言語のファイルを生成する時に便利です。
しかし、キーワード名が削除されてしまうために、
これ以後はキーワード置換を行うことができません。
従って使用には注意が必要です。
オプション `-kv' は、cvs export で使用される事が
多くあります---see section A.11 export--CVS からソースを取り出す, checkout に類似。
しかしモジュールがバイナリ・ファイルを含む場合は、
うまく処理できないので使用しない方が賢明です。
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
キーワード $Log$ にはちょっと問題があります。
開発環境で作業をしているならば、
キーワード $Log$ を使用しなくても、
cvs log を使えば同じ情報が簡単に手に入ります。
いずれにしても出荷用のファイルに履歴情報は必要ないでしょう。
さらに重要な問題は、枝を幹にマージするときに、
RCS が $Log$ の項目をうまく扱えないことです。
このマージ操作の結果、衝突が起きることがよくあります。
またファイル中のログ・メッセージは、修復される傾向にあります。
(綴の間違いやほんとの間違い等)。
しかしこの結果、
cvs log の情報とファイルの中身が一致しないことになります。
これも問題といえば問題でしょう。
どうしてもキーワード $Log$ を使うのならば、
ファイルの先頭ではなく、
ファイルの 最後 に挿入することを推奨します。
この方法ならば、
長い変更メッセージを毎日眺めなくて済みます。
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |