CVS によるバージョン管理

Version Management with CVS

for cvs 1.9 Per Cederqvist et al

日本語訳 : 廣保誠

Copyright \begin{matrix}c \\ ◯ \end{matrix} 1992, 1993 Signum Support AB Copyright \begin{matrix}c \\ ◯ \end{matrix} 1995-1998 Makoto Hiroyasu

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies.

Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled “GNU General Public License” is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one.

Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled “GNU General Public License” and this permission notice may be included in translations approved by the Free Software Foundation instead of in the original English.

このマニュアルについて

これまで、 cvs の最も弱い部分は文書でした。以前のバージョンではマニュアル文書形式で書かれていましたが、 cvs のように複雑なプログラムを勉強するには不向きでした。

このマニュアルは幾つかの目的を念頭に置いて書かれました:

• rcs の知識を必要としない。

• 他のリビジョン管理ソフトウェアに関する知識を必要としない。つまり、リビジョン番号, リビジョン・ツリー, マージ等のすべての用語について紹介する。

• cvs コマンドの動作ではなく、 cvs の利用者がやりたい事に集中して説明する。このマニュアルの最初の部分では、開発中に利用者がやりたくなる事を挙げ、その動作に必要な cvs コマンドを紹介します。

• 情報を見付け易くする。付録の便覧では、全ての cvs のコマンドに関する情報が集められています。これらは索引でもあり、多くの相互参照先が書かれています。

このマニュアルはスウェーデンの Signum Support AB から寄贈されました。 Signum はフリーソフトウェアを支援する成長中の会社です。あなたはこのマニュアルと cvs プログラムの両方を自由にコピーするこ

とができます。詳細は ⟨undefined⟩ [Copying], page ⟨undefined⟩ 参照。 Signum Support は、 cvs, gnu

Emacs, gnu C コンパイラ等の、多くのプログラムの支援やバイナリ頒布を提供します。詳しくは以下まで連絡して下さい。

     Signum Support AB
     Box 2044
     S-580 02  Linkoping
     Sweden
     Email: info@signum.se
     Phone: +46 (0)13 - 21 46 00
     Fax:   +46 (0)13 - 21 47 00

Cyclic Software も cvs の支援を提供しています。 web: http://www.cyclic.com/, email:

info@cyclic.com.

短気な方の為の一覧表

cvs は複雑なシステムです。全ての能力を使用するためには、このマニュアルを読む必要があります。ここでは、知っていれば簡単に避けられる危険について警告します。このチェックリストは、文書を全て読まなくても、危険を避ける助けになります。全ての文書を読む気があるのなら、ここは跳ばして読んでもかまいません。

バイナリ・ファイル cvs はバイナリ・ファイルを扱うことができますが、 rcs のリリース 5.5 以降と、 ‘-a’ フラグが使える gnu の diff (リリース 1.15 以降) が必要です。 rcs と cvs の両方を、バイナリ・ファイルが扱える形でインストールしなくてはいけません。

キーワード置換は、バイナリ・ファイルでは障害の原因となります。解決は Chapter 16 [Keyword

substitution], page 63 参照。

2 CVS—Concurrent Versions System (in japanese)

admin コマンド

admin コマンドを不注意に使用すると、 cvs の動作が止まります。使用する前に Section A.5

[admin], page 75 参照。

謝辞

Cygnus Support の Roland Pesch <pesch@cygnus.com> は cvs 1.3 とともに頒布されたマニュアル

を書きました。付録 A, B の記述の多くは、彼のマニュアルから受け継いでいます。また彼はこのマニュアルの初期の草稿を読み、多くのアイディアと訂正を頂きました。

メイリングリスト info-cvs も時には有益でした。私は以下の人物が行なった投稿による情報を含めまし

た: David G. Grubbs <dgg@think.com>.

rcs のマニュアルから文章を引用しています。

David G. Grubbs 氏による cvs faq は、有用な素地を与えてくれました。 faq はもうメンテナンスされていませんが、このマニュアルが (少くとも cvs の使用方法の文書化に関して)、その後継に最も近いものでしょう。

また、次に挙げる人物が、私の誤りを訂正してくれました: Roxanne Brunskill <rbrunski@datap.ca>,

Kathy Dyer <dyer@phoenix.ocf.llnl.gov>, Karl Pingle <pingle@acuson.com>, Thomas
A Peterson <tap@src.honeywell.com>, Inge Wallin <ingwa@signum.se>, Dirk Koschuetzki
<koschuet@fmi.uni-passau.de> and Michael Brown <brown@wi.extrel.com>.

バグ

この文書は発展途上にあります。既知の欠陥のリストを示します:

• 実行例において、 cvs の出力が表示されない事もある。

• 実行例において、あなたの入力が仮定される所と、コンピュータの出力に異なるフォントを用いるべきである。

• リポジトリのファイルの使用許可を、どう設定すべきか明示されていない。

• 幾つかの章は、まだ完成していない。その旨は texinfo ファイルにコメントを書いている。

• このリストは完全ではないでしょう。何かの誤り, 脱落, 不明解な部分に気付いた場合には、 bug-cvs@prep.ai.mit.edu までメールを送って下さい。

上に挙げた欠陥もありますが、この文書により cvs に対する理解を深められることを願っています。

Linkoping, October 1993 Per Cederqvist

日本語訳について

この cvs のマニュアルは、 cvs 1.9 に付属していた、 ‘cvs.texinfo’ を日本語訳したものです。文書の構造やノード名等は (この節を除いて) そのまま使用しており、文章は自分に可能な限り忠実に訳しています。しかし、付録の便覧には未訳部分が多く残されており、またいたるところに誤訳や訳語の不一致があるでしょう。修正案、訂正等がありましたら、なるべく廣保まで御連絡下さい。

この文書は原英文と同様に、 GNU の General Public Licenses に従って修正・再配布して下さい。 GPL

の詳細は ⟨undefined⟩ [Copying], page ⟨undefined⟩ 参照。

                                              廣保誠 <hiroyasu@iedc.mke.mei.co.jp>

4 CVS—Concurrent Versions System (in japanese)

Chapter 1: CVS とは? 5

1 CVS とは?

cvs はバージョン管理システムであり、あなたのソース・ファイルの変遷を記録するのに使用します。

例えば、ソフトウェアの修正に伴なってバグが入り込み、発見されるまでに長い時間がかかったとします。 cvs を使っていれば、バグ付きの修正を加えた古いバージョンを復元することができます。これで非常に助かるはずです。

全てのバージョンの全てのファイルを保存しておくこともできますが、ディスク容量の無駄使いでしかありません。 cvs は全てのバージョンのファイルを、差分のみを保存する方法で、一つのファイルに記録します。

cvs は、同じプロジェクトの一員として仕事をする場合にも使用できます。このような場合にはよほど気を付けていないと、他の人が変更したファイルを上書きしてしまいます。 gnu Emacs のようなエディタを使えば、複数の人が同時に同じファイルを編集することはありません。しかし不幸なことに、全員が同じエディタを使うとは限りません。 cvs は開発者を互いに隔離することにより、この問題を解決しました。全ての開発者は自分のディレクトリで作業し、その仕事を cvs が組み合わせます。

cvs は Dick Grune が作成し、 1986 年 12 月に comp.sources.unix の volume 6 に投稿した、シェ

ル・スクリプトから始まりました。現在の cvs は、これらのシェル・スクリプトのコードを全く含みませんが、衝突解決のアルゴリズムの大部分を受け継いでいます。

1989 年 4 月に Brian Berliner が cvs を設計し、コーディングしました。その後、 Jeff Polk が cvs の

ベンダー枝とモジュールの設計を助けました。

cvs のソースは anonymous ftp で多くのサイトから取得することができます。例えば、 prep.ai.mit.edu

の ‘/pub/gnu’ の中などです。 anonymous ftp でソースを取得する場合は、ネットワーク全体の負荷を考えて、なるべく近い所から取ってくるようにしましょう。

info-cvs という cvs 専門のメーリングリストがあります。参加したい場合、又は脱退したい場合に

は、 <info-cvs-request@prep.ai.mit.edu> にメールを出して下さい。このメールには、あなたの email

address を書いておいて下さい。 1996 年 5 月時点では、参加申込は忙しい人間の手で行われていますから、参加や脱退が迅速に行われることを期待してはいけません。また comp.software.config-mgmt は、 cvs の議論を行うのに適した場所です (他の構成管理システムと一緒ですが)。

CVS は … ではない

cvs は多くのことができますが、全てのことはできません。

cvs は構築システムではありません。あなたの構築システム用のファイル (例えば ‘Makefile’等) をリポジトリ中に格納することはできますが、構築システムとは全く独立した存在です。

cvs は、何かの作り方を指示したりはしません。 cvs はあなたの意思に従って、ツリー構造から望むファイルを取り出すだけです。

cvs は、 checkout 先のディスク容量の使用法について指示したりはしません。あなたが ‘Makefile’やスクリプトを全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があるとすると、リポジトリ全てを取り出す必要が生じます。

あなたが仕事をモジュール化し、 (‘Makefile’に link, mount, VPASS等を使用して、 ) ファイ

ルを共有するような構築システムを構成すれば、好きな様にディスクの利用法を決めることが出来ます。しかしこれら全てのシステムは、構築と維持にに多大な労力が必要なことに、気を付けなければいけません。 cvs は、このような問題に関して考慮しません。もちろん、これらの構築システムを支援するための道具 (スクリプト, ‘Makefile’等) は、 cvs の管理下に置くと良いでしょう。何らかの変更があった際に、再構築が必要なファイルを調べるのは、やはり cvs の守備外です。伝統的な手法の一例をあげると、構築には make を用い、 make に必要な依存関係は自動化されたツールを用いて生成します。

cvs は管理者代理ではありません。あなたの管理者や上司は、期日に従っているか, マージ点, 枝の名前, リリースの日時等について、あなたと度々話しあうことを求められています。彼等がそうしないなら、 cvs は役に立ちません。 cvs は、あなたの調律に従ってソースを踊らせる楽器のようなものです。あなたは楽器奏者もしくは作曲者だとしましょう。どんな楽器も勝手に演奏をしたりしないし、音楽が勝手に書かれたりもしません。

cvs は開発者同士の意志疎通の代用にはなりません。あるファイルに衝突が起きた場合に、ほとんどの開発者はそれほど苦労せずに解決します。しかし、衝突(conflict) のより一般的な定義には、開発者同士の意志疎通なしには解決できない困難な問題も含まれます。同じファイル (もしくはファイルの集合) に、同時に加えられた変更に論理的な衝突があっても、 cvs には分りません。衝突という概念は単に文字列の比較によるもので、同じファイルを基に加えられた 2 つの変更が、 mergeコマンド (つまり diff3) を驚かせるのに十分なほど近接している場合にのみ生じます。 cvs は、プログラムの論理に衝突があったとしても、警告を表示しません。例: あなたは ‘A’ で定義された関数 X の引数を変更したとします。同じ時に、誰かが ‘B’ を編集して、古い引数を使って X を呼び出したとします。これは cvs の能力の範囲外です。仕様書を読み、同僚と話し合う習慣を付けましょう。

cvs は変更管理をしません。変更管理という言葉は様々な意味を持ちます。まずバグ追跡と解釈すれば、バグ報告と各バグの状態 (修正されたか? どのリリースか? 修正を確認した人物は? 等) についてのデータベース管理を意味します。 cvs とバグ追跡システムとの連携については、 ‘rcsinfo’ と ‘editinfo’ ファ

イルを見て下さい (see Appendix B [Administrative files], page 99)。

論理的には 1 つと考えられる変更のため、複数のファイルが同時に変更されたことを覚えておくことも、変更管理と呼ばれます。複数のファイルの変更を 1 つの cvs commit により格納した場合、 cvs はそれらのファイルが同時に格納されたことを忘れてしまいます。そして、それらのファイルを結ぶ事柄は、同じログ・メッセージを持つことだけになるのです。 gnu 形式の ‘ChangeLog’ を用いれば何らかの助けになるでしょう。各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。開発者によって加えられた変更もあれば、他の開発者によって追試中の変更もあるとか、そういったことです。一般的に cvs でこのようなことをするには、 (cvs diff や diff を用いて) diff を生成し、 patch を当てる人物にメールとして送ります。これは非常に融通のきく方法ですが、 cvs 以外の機構に依存しているので、問題が無いことを確かめられません。

cvs 自動検査プログラムではありません。 commitinfo ファイルを使えば、強制的に必須の項目を検査することは可能だと思います。しかし、そんなことをしようとしたプロジェクトのことは聞いたことがありません。

cvs は手順規範を備えていません。変更やリリースに必要とされる色々な手順や多くの承認を、確実に行なう方法を備えたシステムもあります。 cvs を用いてこれを達成することも可能ですが、ちょっと面倒だと思います。場合

Chapter 1: CVS とは? 7

によっては、 ‘commitinfo’, ‘loginfo’, ‘rcsinfo’, ‘editinfo’ 等のファイルを用いて、 cvs

が格納する前に、各手順を確実に踏むように要求できるでしょう。また枝やタグなどを用いて、開発用の木で仕事を実行し、安定性が証明された確実な変更だけを、安定化指向の木に統合することも考えられます。

8 CVS—Concurrent Versions System (in japanese)

2 基本概念

cvs は全てのファイルをリポジトリ(repository) に集めて格納します (see Chapter 4 [Repository], page 15)。

リポジトリはディレクトリやファイルを含み、任意の場所に設定できます。複数のディレクトリやファイルから成る単位を、モジュール(modules) として一括して管理できます。各モジュールは、プロジェクト毎に定義するのが普通です。

2.1 リビジョン番号

各バージョンのファイルはそれぞれリビジョン番号(revision number) を持ちます。 ‘1.1’, ‘1.2’ とか ‘1.3.2.2’ とか ‘1.3.2.2.4.5’ なんてのもあります。リビジョン番号はピリオドで分けられた偶数個の十進整数です。ファイルの最初のリビジョンは 1.1 で、リビジョンが新しくなると一番右の番号が 1 つ増えます。

       +-----+    +-----+    +-----+    +-----+    +-----+
       ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
       +-----+    +-----+    +-----+    +-----+    +-----+

cvs は直線的な発展のみに限定されません。リビジョン・ツリー (revision tree) は、独自に発展する枝 (branch) を持つことができます。各枝に加えられた変更は、簡単に元の幹(main trunk) に戻すことができます。

各枝は、ピリオドで分けられた奇数個の十進整数からなる枝番号 (branch number) を付けられます。枝番号は、枝を産んだリビジョン番号の右に、ピリオドと整数をくっつけたものです。各リビジョンは、複数の枝を持つことができます。

枝にあるリビジョンのリビジョン番号は、枝番号に数をくっつけたものになります。下図に、上記の例が枝を持った例を示します。

                                                     +-------------+
                          Branch 1.2.2.3.2 ->        ! 1.2.2.3.2.1 !
                                                   / +-------------+
                                                  /
                                                 /
                 +---------+    +---------+    +---------+    +---------+
Branch 1.2.2 -> _! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !----! 1.2.2.4 !
               / +---------+    +---------+    +---------+    +---------+
              /
             /
+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
                !
                !
                !   +---------+    +---------+    +---------+
Branch 1.2.4 -> +---! 1.2.4.1 !----! 1.2.4.2 !----! 1.2.4.3 !
                    +---------+    +---------+    +---------+

ここで注意したいのは、 cvs が枝番号を生成するときには、まだ使われていない最初の偶数である 2 から始めることです。従ってリビジョン 6.4 から枝を生成すると、 6.4.2 となります。 0 で終る枝番号は cvs 内

部で使用され (see Section D.1 [Magic branch numbers], page 111)、また枝 1.1.1 は特別な意味を持ちます (see Chapter 12 [Tracking sources], page 55)。

2.2 バージョン、リビジョン、リリース

ファイルにはそれぞれバージョンがあり、またソフトウェア製品にも ‘4.1.1’ などというバージョンがあります。

バージョンには二つの意味があり、最初のものはこの文書でリビジョンと呼ばれるものです。 2 番目はリリースと呼ばれるものです。混乱を避けるために、なるべくバージョンという単語は使わないようにします。

Chapter 3: 実行例 11

3 実行例

cvs を使って典型的な仕事をしてみます。リポジトリは準備されていると仮定します (see Chapter 4

[Repository], page 15)。

あなたの仕事は単純なコンパイラを作成することです。ソースは C 言語で書かれていて、 ‘Makefile’ を含んでいるとします。このコンパイラを ‘tc’ (Trivial Compiler) と呼ぶことにします。そして ‘tc’ というモジュール名でリポジトリに登録されています。

3.1 ソースの取得

まず、 ‘tc’ のソースの作業コピーを取ってくることから始めましょう。これには checkout コマンドを使用します:

     $ cvs checkout tc

とすると ‘tc’ という新しい作業ディレクトリが作られ、その中にソース・ファイルがコピーされます。

     $ cd tc
     $ ls
     CVS         Makefile    backend.c   driver.c    frontend.c  parser.c

‘CVS’ というディレクトリは cvs が内部的に使用するため、このディレクトリ以下は修正したり削除してはいけません。

で、あなたの好きなエディタを用いて ‘backend.c’ をハックして、コンパイラの最適化経路を加えたとします。ここで、 rcs や sccs の様に、ファイルをロックしなかったことに注意して下さい。 See Chapter 6

[Multiple developers], page 29。

3.2 変更の格納

あなたはコンパイラがコンパイル可能であることを確認し、 ‘backend.c’ の新しいバージョンとすることに決めました。

     $ cvs commit backend.c

cvs はログ・メッセージを記すためにエディタを開きます。そこで “Added an optimization pass.” などと入力し、一時ファイルに保存し、エディタを終了します。

エディタは環境変数 $CVSEDITOR に設定します。 $CVSEDITOR が設定されておらず、 $EDITOR が設定されていれば、これを使用します。 $CVSEDITOR と $EDITOR の両方が設定されてなければ、 vi になります。わざわざエディタを開くのが嫌ならば、 ‘-m’ オプションで次のように指定できます:

     $ cvs commit -m "Added an optimization pass" backend.c

3.3 お掃除

次に他の仕事をする前に、ソースのコピーを消したい場合には、もちろん次のようにするでしょう。

  $ cd ..
  $ rm -r tc

しかし、 release コマンドを使用するほうが良いでしょう (see Section A.14 [release], page 92):

  $ cd ..
  $ cvs release -d tc
  M driver.c
  ? tc
  You have [1] altered files in this repository.
  Are you sure you want to release (and delete) module `tc': n
  ** `release' aborted by user choice.

release コマンドは、あなたの修正が格納されているかどうか確認します。ログを記録する設定ならば、

ファイル ‘history’ にメモします (see Section B.9 [history file], page 106)。

release コマンドに ‘-d’ フラグを使用すると、確認と同時に作業コピーを削除します。上の例では、 release コマンドが何行か出力しています。 ‘? tc’ は cvs が ‘tc’ というファイルを知ら

ないという意味です。モジュール ‘tc’ のことではなく、生成したコンパイラ ‘tc’ を指しており、これはリポジトリに格納しなくて良いので無視して構いません。この警告を消すための情報は Section B.8 [cvsignore],

page 105 参照。 release の出力の詳細な説明は Section A.14.2 [release output], page 92 参照。

‘M driver.c’ の方は重要です。これは、 ‘driver.c’ というファイルに加えた修正が、格納されていないことを指摘しています。

release コマンドは、修正が加えられたファイルの数を報告した後、全ての作業コピーを削除して ‘history’にメモする前に、その確認を求めてきます。

で、安全のために最後に n ⟨\underline{\overline{RET}}⟩ を入力しました。

3.4 差分を見る

あなたは ‘driver.c’ に加えた修正を覚えておらず、何をしたのか見る必要があります。

  $ cd tc
  $ cvs diff driver.c

diff コマンドは、取り出した時の ‘driver.c’と、あなたの作業コピーを比較します。その出力を見て、最適化経路を有効にするオプションを、コマンド行で指定するようにしたことを思い出しました。その変更を格納して、このモジュールに対する作業を終了します。

  $ cvs commit -m "Added an optimization pass" driver.c
  Checking in driver.c;

/usr/local/cvsroot/tc/driver.c,v  <--  driver.c
new revision: 1.2; previous revision: 1.1
done
$ cd ..
$ cvs release -d tc
? tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) module `tc': y

14 CVS—Concurrent Versions System (in japanese)

Chapter 4: リポジトリ 15

4 リポジトリ

cvs のリポジトリ(repository) は、バージョン管理の対象となる全てのファイルとディレクトリの、完全なコピーを保管します。

通常、リポジトリ中のファイルを直接利用することはありません。その代わり cvs コマンドを使用して、作業者自身のファイルのコピーを取ってきて、そのコピーを用いて作業します。そして一連の変更が完了したときに、変更点をリポジトリに格納(commit) します。リポジトリは、変更を加えたものと同じになり、また同時に変更点や、変更日時などの情報も正確に記録されます。

cvs は様々な方法でリポジトリを利用することができます。リポジトリは、使用中のコンピュータ内であってもいいし、別の部屋のコンピュータや、別の国のコンピュータであってもいいのです。リポジトリを利用する方法を区別するために、リポジトリの名前の最初に利用方式(access method) を加えます。例えば :local: は、リポジトリとなるディレクトリを利用することを意味します。つまり :local:/usr/local/cvsroot で表されるリポジトリは、 cvs を実行したコンピュータの ‘/usr/local/cvsroot’ というリポジトリを意味

します。他の利用方式については Section 4.6 [Remote repositories], page 19 参照。

利用方式の指定が省略され、リポジトリに ‘:’ が含まれない場合には、 :local: が仮定されます。 ‘:’ が

含まれていた場合には、 :ext: か :server: が仮定されます。例えばリポジトリ ‘/usr/local/cvsroot’
が同コンピュータ内にある場合、 :local:/usr/local/cvsroot を省略して/usr/local/cvsroot

が使用できます。しかし (Windows NT などで)、リポジトリが ‘c:\src\cvsroot’ にある場合、

:local:c:\src\cvsroot として、利用方式を明示する必要があります。

リポジトリは 2 つの要素から構成されます。 ‘$CVSROOT/CVSROOT’ には cvs の管理用ファイルが置かれます。その他のディレクトリには、使用者が定義した実際のモジュールが置かれます。

4.1 CVS にリポジトリの場所を教える

cvs にリポジトリの場所を教えるには、 2 つの異なる方法があります。 1 つ目はコマンド行で、 -d ("directory" を示します) オプションを用いて指定する方法です:

     cvs -d /usr/local/cvsroot checkout yoyodyne/tc

2 つ目は、環境変数 $CVSROOT に、絶対パスでリポジトリを指定する方法です(例では ‘/usr/local/cvsroot’

です)。 csh や tcsh のユーザは各々‘.cshrc’ や ‘.tcshrc’ に次の行を加えて下さい:

     setenv CVSROOT /usr/local/cvsroot

sh や bash のユーザは各々‘.profile’ や ‘.bashrc’ に次の行を加えて下さい:

     CVSROOT=/usr/local/cvsroot
     export CVSROOT

-d によるリポジトリの指定は、環境変数 $CVSROOT よりも優先されます。一旦リポジトリから作業コピーを取得すれば、リポジトリの場所が記憶されます (この情報は、作業ディレクトリ内の ‘CVS/Root’ に記録されます)。

オプション -d とファイル ‘CVS/Root’ は、どちらも環境変数 $CVSROOT よりも優先されます。また、 ‘-d’ と ‘CVS/Root’ が一致しない場合は、前者が使用されます (-d の指定により ‘CVS/Root’ が更新されます)。もちろん、 2 つの方法が同じリポジトリを参照するのが、まともなやり方です。

4.2 リポジトリでのデータの保存方法

cvs がリポジトリに情報を保存する方法を知っていても、たいてい何の役にも立ちません。実際、過去に書式が変更されましたし、将来変更されることもあるでしょう。ほとんど全ての場合、 cvs コマンドを通してリポジトリを利用しますから、書式を変更しても混乱は起きません。

しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例えば cvs のロック解除が必要

な場合 (see Section 6.5 [Concurrency], page 33) や、リポジトリのファイル許可を適切に設定する必要が

ある場合などです。

4.2.1 リポジトリのどこにファイルを保存するか

リポジトリの全体構造は、作業ディレクトリと同じ構造を持つディレクトリで構成されています。例えば、リポジトリが ‘/usr/local/cvsroot’ であるとすると、ディレクトリは次に示すような木構造を持ちます (リポジトリとなるディレクトリのみ示しています):

     /usr
      |
      +--local
      |   |
      |   +--cvsroot
      |   |    |
      |   |    +--CVSROOT

| (管理用ファイル)

               |
               +--gnu
               |   |
               |   +--diff
               |   |   (gnu diff のソース)
               |   |
               |   +--rcs

| | (rcs のソース)

               |   |
               |   +--cvs

| (cvs のソース)

               |
               +--yoyodyne
                   |
                   +--tc
                   |    |
                   |    +--man
                   |    |
                   |    +--testing
                   |
                   +--(その他の Yoyodyne のソフトウェア)

ディレクトリの中身は、管理下にあるファイルの履歴ファイル(history files) です。履歴ファイルの名前は、各ファイル名の最後に ‘,v’ を付加したものです。次に、ディレクトリ ‘yoyodyne/tc’ のリポジトリ構造を示します:

       $CVSROOT
         |
         +--yoyodyne
         |   |
         |   +--tc
         |   |   |
                 +--Makefile,v
                 +--backend.c,v
                 +--driver.c,v
                 +--frontend.c,v
                 +--parser.c,v
                 +--man
                 |    |
                 |    +--tc.1,v
                 |
                 +--testing
                      |
                      +--testpgm.t,v
                      +--test2.t,v

履歴ファイルは、どのリビジョンのファイルでも再構築できる情報を持ち、また変更内容が格納された時のログ・メッセージと、その時のユーザの名前も記録しています。ファイルをこのような書式で保管した最初のプログラムが、 rcs というバージョン管理システムであったために、履歴ファイルは RCS ファイルと呼ばれます。ファイル書式の完全な記述は、 rcs の配布セットにある、 rcsfile(5) の man ページを参照して下さい。このファイル書式は非常に一般的なので、 cvs や rcs 以外のシステムでも、少くとも理解することができます。

4.2.2 ファイル使用許可

全ての ‘,v’ ファイルは読み込み専用であり、この使用許可を変えるべきではありません。これに対し、リポジトリ中のディレクトリは、ファイルの修正を行なう人物に対して、書き込みを許可しなくてはなりません。これはつまり、ファイルの修正を行なう人物からなるグループを作って (group(5) 参照)、そのディレクトリの所有グループとすることを意味しています。

従って、ディレクトリ単位でしかファイルのアクセス権を管理することができません。

ロック・ファイルを作成する必要があるため (see Section 6.5 [Concurrency], page 33)、ファイルを取

り出す使用者に、書き込み許可が必要であることに注意して下さい。

また、ファイル ‘CVSROOT/val-tags’ にも書き込み許可が必要です。このファイルは、有効なタグ名の追跡を続けるために使われます (タグ名が付けられたときだけでなく、タグ名が使われたときでも更新されます)。

新しいディレクトリを加える場合、 cvs はできるだけ適当な使用許可を与える努力をします。しかし新しいディレクトリの使用許可が、親ディレクトリのものと異なる場合には、手動で変更する必要があります。環境変数 CVSUMASK を設定すれば、リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。 CVSUMASK は、作業ディレクトリのファイル使用許可には影響しません。作業コピーの使用許可は、新たに作成したファイルに通常与えられるものと同じです。但し、 cvs が読み込みだけを許可することがありま

す (監視時 Section 6.6.1 [Setting a watch], page 34, -r 使用時 Section A.3 [Global options], page 72, CVSREAD 設定時 Appendix C [Environment variables], page 109 を各々参照)。

cvs は setuid bit を立てて実行するように設計されていません。従って setuid bit を立てたまま実行することは非常に危険です。 cvs と同じく、 rcs でも setuid を使用してはいけません。

4.3 管理用ファイルの紹介

‘$CVSROOT/CVSROOT’ には、いくつか管理用ファイル(administrative files) があります (see Appendix B [Administrative files], page 99)。これらのファイルが無くても cvs を使用することができます。し

かし、 cvs のコマンドをうまく働かせるために、少なくとも ‘modules’ というファイルは欲しいものです。

管理用ファイルの中で、最も重要なファイルは ‘modules’ です。これはリポジトリの中の全てのモジュールを定義しています。 ‘modules’ ファイルの例を次に示します。

     CVSROOT         CVSROOT
     modules         CVSROOT modules
     cvs             gnu/cvs
     rcs             gnu/rcs
     diff            gnu/diff
     tc              yoyodyne/tc

‘modules’ ファイルの各行はそれぞれ、モジュール名, 空白, モジュールのあるディレクトリ名という書式で記述されます。モジュールのあるディレクトリ名は、 $CVSROOT からの相対パスです。

モジュール ‘modules’ を定義する行については、ここでは説明しません。より詳しい説明は Section B.1

[modules], page 99 参照。

4.3.1 管理用ファイルの編集

管理用ファイルは、他のモジュールと同じ方法で編集します。 ‘cvs checkout CVSROOT’ を用いて作業コピーを得た後、編集し、通常通り変更内容を格納します。

間違いのある管理用ファイルを格納することも可能です。このような場合には、間違いを正して新たなリビジョンを登録します。しかし管理用ファイルに深刻な間違いがあれば、新たなリビジョンの登録さえも不可能になります。

4.4 複数のリポジトリ

例えば 2 つのプロジェクトがあり、全くコードが重複しないのであれば、 1 つ以上のリポジトリがあった方が良いでしょう。適切なディレクトリを、環境変数 $CVSROOT に設定するか、 cvs のオプション ‘-d’ に指定すれば、複数のリポジトリを用いることができます。また、既に作業ディレクトリを取り出した後ならば、

cvs はそのリポジトリを利用します (see Section 4.1 [Specifying a repository], page 15)。

複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。しかし、別々のリポジトリで管理されるディレクトリに対して、 1 つの cvs コマンドが再帰的に動作しない、という大きな欠点があります。また一般的に、同じマシンに複数のリポジトリを作るのならば、同じリポジトリに複数のディレクトリを作るほうが良いと思います。

この文書では、複数のリポジトリを使用した例はありません。

4.5 リポジトリの作成

cvs リポジトリの準備として、まずソース・ファイルの履歴を保存するため、広いディスク容量が使えるディレクトリを選びます。そして、サーバまたは直接 cvs を使う全てのマシンから、 (直接もしくは NFS 経由で) 利用可能にする必要があります。クライアントのマシンは cvs プロトコルを経由するため、利用可能である必要はありません。 cvs は、リポジトリにロック・ファイルを作成する必要があるため (see Section 6.5 [Concurrency], page 33)、利用者が読み込み許可しか持たないリポジトリを、 cvs から使うことはできません。

リポジトリを作成するときには、 cvs init コマンドを実行して下さい。通常の方法で指定された cvs の

ルート (see Chapter 4 [Repository], page 15) 以下の、空のリポジトリを利用できるように整えます。例え

ば次のようにします。

     cvs -d /usr/local/cvsroot init

cvs init は、リポジトリに存在するファイルを、上書きしないように注意します。従って既に利用できる状態のリポジトリに対して、 cvs init を実行しても、何の不都合もありません。

cvs init は、履歴を記録するように設定します。もしこれを望まないのであれば、 cvs init を実行した

後に、 ‘history’ ファイルを削除して下さい。 See Section B.9 [history file], page 106。

4.6 別マシンのリポジトリ

リポジトリとあなたの作業コピーは、別々のマシンに置くことができます。別のマシンのリポジトリを利用する時に、同じマシンの場合と異なるのは、リポジトリ名の書式だけです:

     :method:user@hostname:/path/to/repository

サーバに接続する方法ごとに、必要な設定事項を正確に詳細に述べます。

method が指定されず、リポジトリ名に ‘:’ が含まれる場合には、 ext か server が既定値とされます。この話は、使用するオペレーティングシステムに依存するので、詳しくは Section 4.6.1 [Connecting via

rsh], page 19 参照。

4.6.1 rsh で接続する

cvs は ‘rsh’ プロトコルを用いて動作します。この時サーバ側の使用者の ‘.rhosts’ に、クライアント側の使用者の利用許可を記述する必要があります。

例えば、仮にあなたをクライアント側のマシン ‘anklet.grunge.com’ の使用者 ‘mozart’ だとし、サー

バ側のマシンは ‘chainsaw.brickyard.com’ であるとします。この時、次の行を ‘chainsaw’ の使用者

‘bach’ のホーム・ディレクトリのファイル ‘.rhosts’ に記述して下さい。

     anklet.grunge.com  mozart

そして、 rsh の動作を次の行で確認します。

     rsh -l bach chainsaw.brickyard.com 'echo $PATH'

次に rsh が、サーバを発見できるかどうか確認する必要があります。上記の例で rsh が表示したパスの中に、サーバである cvs のあるディレクトリが含まれているかどうか確認して下さい。 ‘.login’ や ‘.profile’ でなく、 ‘.bashrc’, ‘.cshrc’ 等にパスを設定する必要があります。同時に、クライアント側で環境変数 CVS_

SERVER に、 ‘/usr/local/bin/cvs-1.6’ などと、使用したいサーバ名を設定できます。

inetd.conf を編集したり、 cvs のサーバ・デーモンを走らせる必要はありません。

rsh で $CVSROOT を使う場合の利用方式は 2 つあります。 :server: を指定した場合、 cvs が内部実装した rsh のクライアントが用いられますが、移植版では利用できないものもあります。 :ext: を指定した場合、外部の rsh プログラムが用いられます。 rsh が既定となっていますが、サーバを利用できる他のプログラムを呼び出す場合は、環境変数 CVS_RSH に設定して下さい (例えば HP-UX 9 では、 rsh が少々異なるため remsh を用いて下さい)。指定するプログラムは、データを変更しないで送受信できなくてはいけません。例えば Windows NT の rsh は、既定では CRLF を LF に換えるので不適当です。 cvs の OS/2 版はこれを回避するため、 rsh に ‘-b’ を渡して切り抜けていますが、標準的な rsh でないプログラムを黙認する形になるので、将来は別のやり方になるでしょう。 CVS_RSH に SSH 等の rsh の代替物を設定した場合、この節の残りの ‘.rhosts’ の使用説明などは、おそらく不適当でしょうから、各 rsh の代替物の文書資料を参照して下さい。

   例を続けて、仮に ‘chainsaw.brickyard.com’ のリポジトリ ‘/usr/local/cvsroot/’ 中のモジュー

ル ‘foo’ を利用したい場合には、次の様にします:

     cvs -d :ext:bach@chainsaw.brickyard.com:/usr/local/cvsroot checkout foo

(クライアント側とサーバ側で、使用者名が同じ場合には、 ‘bach@’ を省略することが出来ます。 )

4.6.2 パスワード認証による直接接続

cvs のクライアントは、パスワード・プロトコルを用いて、サーバと接続することもできます。この方法は、 rsh の使用が可能でなく (例えばサーバが防火壁の向こうにある場合)、またケルベロスも利用できない場合に特に有効です。

この方法を使用するために、サーバとクライアントの双方での調整が必要になります。

4.6.2.1 パスワード認証のためのサーバ側の設定

サーバ側では ‘/etc/inetd.conf’ を編集する必要があります。正しいポートから接続を受けた時、 inetd がコマンド cvs pserver を実行する様に変更します。ポート番号の既定値は 2401 ですが、クライアントをコンパイルした時に、 CVS_AUTH_PORT に他の値を定義した場合には異なります。

あなたの使用する inetd が、ポート番号を素のまま ‘/etc/inetd.conf’ に書いて良いならば、次の記述で十分でしょう (‘inetd.conf’ には一行で記述して下さい):

     2401  stream  tcp  nowait  root  /usr/local/bin/cvs
     cvs -b /usr/local/bin pserver

サーバ上で rcs の実行ファイルがあるディレクトリを、 ‘-b’ オプションで指定します。また一時ファイルを作成するディレクトリを、 ‘-T’ オプションで指定できます。

あなたの使用する inetd が、素のポート番号ではなく、サービス名を要求するならば、 ‘/etc/services’ に次の行を追加して下さい:

     cvspserver      2401/tcp
   そして ‘inetd.conf’ には、 2401 ではなく cvspserver と記述して下さい。

以上を注意して行なった後、 inetd を再起動するか、初期設定ファイルを再読させるのに必要な処置を取って下さい。

cvs のクライアントは、パスワードを平文のまま保存または伝送します (詳細は Section 4.6.2.3 [Password authentication security], page 22)。従って、リポジトリを利用する時に、正規のパスワードを危険に曝さないために、 cvs では別のパスワードファイルを使用します。このファイルは ‘$CVSROOT/CVSROOT/passwd’

です (see Section 4.3 [Intro administrative files], page 18)。その書式は、 2 つの欄しかない事を除けば、 ‘/etc/passwd’ と同様です。次に例示します:

     bach:ULtgRLXo7NRxs
     cwang:1sOp854gDF3DY

パスワードは、標準 Unix の関数 crypt() によって暗号化されます。従って、標準 Unix の ‘passwd’ から直接コピーすることも可能です。

パスワード認証では、まずサーバが、 cvs の ‘passwd’ ファイル中の、使用者のエントリを確認します。使用者のエントリがあれば、入力されたパスワードと比較されます。使用者のエントリが無いか、あるいは cvs の ‘passwd’ ファイルが存在しない場合には、システムが使用者の調査機構に使用するパスワードと一致するか試されます。 cvs の ‘passwd’ ファイルが使用される場合、サーバはエントリの 3 番目の欄にある使用者の権限で実行されます。 3 番目の欄が無い場合には、最初の欄にある使用者の権限が使用されます (つまり cvs の ‘passwd’ ファイルに、システムで有効な使用者を併せて記述すれば、架空の使用者名を使用できます)。どちらの場合でも、 (有効な) 使用者が持たない特権は付与されません。

現在、 cvs の ‘passwd’ ファイルにパスワードを加えるには、他のどこかからコピーするしか方法がありません。いつの日か cvs passwd コマンドができることでしょう。

4.6.2.2 パスワード認証によるクライアントの使用

サーバに接続する前に、使用者はコマンド cvs login を用いて、ログインする必要があります。サーバのパスワード確認と同時に、後のサーバとの処理のためにパスワードを保存します。コマンド cvs login は、与えられた引数もしくは環境変数 CVSROOT から、使用者名, サーバ名, リポジトリへのフルパス等の必要な情報を取得します。

cvs login はインタラクティブにパスワード入力を促します:

     cvs -d :pserver:bach@chainsaw.brickyard.com:/usr/local/cvsroot login

     CVS password:

サーバによりパスワードが照合され、正しければログインが成功しますが、誤りであれば失敗して、パスワードが正しく無いと文句を言います。

ログインが成功した後、ログイン時に記録されたパスワードを用いて認証を行ない、 cvs がサーバに直接接続します:

     cvs -d :pserver:bach@chainsaw.brickyard.com:/usr/local/cvsroot checkout foo

cvs がサーバに接続する際、 ‘:pserver:’ が無ければ、 rsh が用いられます (see Section 4.6.1 [Connecting via rsh], page 19)。従って、必ず ‘:pserver:’ を付加して下さい。 (一旦作業コピーを取り出した

後、作業ディレクトリ中で cvs を実行する場合には、面倒なリポジトリの指定は必要ありません。作業コピーのサブディレクトリ ‘CVS’ に、引数のリポジトリが記録されているためです。 )

パスワードは、既定ではファイル ‘$HOME/.cvspass’ に保存されます。ファイルは人が読める書式で書かれていますが、十分な知識無しに編集してはいけません。パスワードは平文ではありませんが、 "悪気無く"見られる事を防ぐための、簡単な暗号化しかしていません (つまり、システム管理者が偶然そのファイルを見付け、不注意に見るといった事)。

環境変数 CVS_PASSFILE は、既定値に優先します。この環境変数を使用するのであれば、 cvs login を実行する前に設定しなければいけません。 cvs login を実行した後に設定した場合、その後の cvs コマンドは、サーバに送るパスワードを見付けられません。

環境変数 CVS_PASSWORD は、記録された他の全てのパスワードに優先します。この環境変数が設定された場合、 cvs は、全てのパスワード認証においてこれを使用します。

4.6.2.3 パスワード認証における安全性の考察

パスワードは、平文の簡単な暗号でクライアント側に保存されており、送信の際も同じ暗号化が用いられます。この暗号化は、パスワードが偶然見られることを防ぐためのもので (すなわちシステム管理者が不注意に見てしまう事)、素人のパスワード攻撃さえ防ぐことが出来ません。

cvs 独自のパスワードファイルにより (see Section 4.6.2.1 [Password authentication server], page 20)、

リポジトリの利用時に、ログイン時のものとは別のパスワードを使用できます。しかし、一旦リポジトリが利用可能になれば、多様な方法により、サーバ上でプログラムが実行可能になります。つまりリポジトリの利用は、かなり広範囲にシステムが利用できる事を暗示しています。これを防止するように cvs を修正する事は可能でしょうが、現在までに誰もやっていません。さらに cvs を利用して、システムに対するより一般的な権限を獲得する別の方法が存在するでしょう。しかし誰も徹底した審査を行っていません。

要約すると、パスワードを得た人物は誰でもリポジトリを利用でき、またある程度通常のシステム利用も可能になります。ネットワークのパケットを漁ったり、保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、全ての人物がパスワードを入手可能です。あなたが本物の安全を望むのならば、ケルベロスにしましょう。

4.6.3 ケルベロスによる直接接続

rsh を利用する際の主な欠点は、全てのデータが他のプログラムを経由する必要があるため、時間がかかる事です。もしケルベロスが導入されているならば、ケルベロスの認証により、直接 tcp 接続する事が可能です

このためには、ケルベロスの支援を受けるように、 cvs をコンパイルする必要があります。 cvs のコンパイル時に、ケルベロスが利用できるかどうかを検出しようとしますが、駄目ならフラグ ‘--with-krb4’ を用いて強制させることも可能です。

既定状態では、データ転送は暗号化されません。クライアントとサーバ双方を、暗号化を有効にしてコンパイルしておく必要があります。構築時に ‘--enable-encryption’ オプションを付加して、暗号化機能を有効にして下さい。また暗号化を要求するために、使用時に広域オプション -x を付加する必要があります。

cvs kserver を実行するため、サーバの inetd.conf を編集する必要があります。クライアントが使用する既定のポート番号は 1999 です。他のポートを使用したい場合には、環境変数 CVS_CLIENT_PORT に指定して下さい。

cvs を利用する際に、通常の方法で切符を取得して下さい (一般的には kinit です)。この切符でサーバへのログインが許可されるはずです。これで準備ができました:

     cvs -d :kserver:chainsaw.brickyard.com:/user/local/cvsroot checkout foo

ここで接続に失敗した場合、以前のバージョンの cvs は rsh で再接続を試みましたが、このバージョンでは再試行されません。

24 CVS—Concurrent Versions System (in japanese)

Chapter 5: CVS でプロジェクトを始める 25

5 CVS でプロジェクトを始める

ファイルの改名とディレクトリ間の移動がうまくできないので、新しいプロジェクトを始めるときには、最初にファイルの構成をよく考えておく必要があります。ファイルの改名や移動は、不可能ではありませんが非常にやっかいです。特にディレクトリの改名に関して、 cvs は癖のある動作をします (see Chapter 13 [Moving

files], page 57)。

次に何をするかは、始める状況に依ります。

5.1 ファイルの準備

始めの一歩は、リポジトリ中にファイルを生成することです。これには幾つか異なる方法があります。

5.1.1 存在するファイルからディレクトリを生成する

cvs を使い始める場合に、おそらく cvs を使用できるプロジェクトが既に幾つかあるでしょう。この場合 import コマンドを使用するのが最も簡単です。例を挙げて説明します。 cvs に組み込みたいファイルが

‘wdir’ にあり、それを ‘$CVSROOT/yoyodyne/rdir’ に置きたい時、次のようにします。

$ cd wdir

     $ cvs import -m "Imported sources" yoyodyne/rdir yoyo start

‘-m’ フラグでログ・メッセージを与えなかった場合、 cvs によりエディタが開かれます。 ‘yoyo’ はベンダー・タグ(vendor tag) と呼ばれるものであり、 ‘start’ はリリース・タグ(release tag) と呼ばれるもの

です。詳しくは Chapter 12 [Tracking sources], page 55 参照。

では実際に確かめた後、元のディレクトリを削除します。

     $ cd ..
     $ mv wdir wdir.orig
     $ cvs checkout yoyodyne/rdir  # 下で説明
     $ ls -R yoyodyne
     $ rm -r wdir.orig

誤って wdir で作業しないように、 cvs を迂回して、元のソースを削除すると良いでしょう。もちろん削除する前に、ソースのバックアップを取るのが賢明です。

checkout コマンドはモジュールの名前、または $CVSROOT からの相対パスを引数に取ります。

‘$CVSROOT’ 中のディレクトリに、 cvs が設定した使用許可とグループ属性が、適切かどうか調べると良

いでしょう。 See Section 4.2.2 [File permissions], page 17。

取り込みたいファイルの中にバイナリ・ファイルが含まれる場合、包装機能を用いて、どのファイルがバイ

ナリなのか明示するとよいでしょう。 See Section B.2 [Wrappers], page 100。

5.1.2 他のバージョン管理システムからファイルを作成する

rcs 等の、他のバージョン管理システムで保守されてきたプロジェクトがあり、そのプロジェクトのファイルを cvs に移管する場合、各ファイルの修正履歴の維持を望むでしょう。

RCS から rcs を使用してきた場合、 rcs ファイルを見付けて下さい— 通常 ‘foo.c’ という名前のファイルには、 ‘RCS/foo.c,v’ という rcs ファイルが対応します (他の場所にあるかもしれませんので、詳細は rcs の文書を調べて下さい)。次に、 cvs リポジトリに適当なディレクトリを作成して下さい。そして cvs リポジトリの当該ディレクトリに、ファイルをコピーして下さい (リポジトリ中のファイル名は、ソース・ファイルに ‘,v’ が付加されたものでなくてはならず、またファイルは ‘RCS’ サブディレクトリではなく、当該ディレクトリに直接置いて下さい)。この例のように、 cvs コマンドを利用せず、 cvs リポジトリを直接利用するほうが適当な場合が稀にあります。以上で作業コピーを新たに取り出す準備ができました。 rcs ファイルを cvs に移動するときに、ロックされていてはいけません。ロックされている場合には、操作に支障を来します。

他のバージョン管理システムから多くのバージョン管理システムは、標準形式の rcs ファイルを出力する機能を持っています。これが可能ならば、 rcs ファイルを出力して、前項の説明に従って下さい。

SCCS から

cvs のソース配布物の中の ‘contrib’ ディレクトリの中に、 ‘sccs2rcs’ という名前のスクリプトがあります。これを用いて sccs ファイルを rcs ファイルに変換できます。注意: sccs と rcs の両方を持つマシンで実行する必要があり、また ‘contrib’ 内の他の全てと同様に動作保証はされません (使用者によって評価は異なるでしょう)。

5.1.3 ゼロからディレクトリを作る

新しいプロジェクトを始める場合、まず空のディレクトリを作ります。

$ mkdir tc
$ mkdir tc/man
$ mkdir tc/testing

その後 import コマンドを使って、リポジトリに各々の (空の) ディレクトリを登録 (作成) します。

$ cd tc
$ cvs import -m "Created directory structure" yoyodyne/dir yoyo start

そして add コマンドで、ファイル (と新しいディレクトリ) を加えていきます。

その時、 ‘$CVSROOT’ の中のファイルの使用許可が、正しいものかどうかを確認すると良いでしょう。

5.2 モジュールの定義

二歩目は ‘modules’ ファイルにモジュールの定義をする事です。必ずしも必要ではありませんが、関連するファイルやディレクトリをグループ化するのに便利です。

モジュールを定義する簡単な手順を示します。 1. ‘modules’ ファイルのコピーを取ってきます。

$ cvs checkout CVSROOT/modules
$ cd CVSROOT

2. ファイルを編集し、モジュールの定義を加えます。紹介は Section 4.3 [Intro administrative files], page 18 参照。詳細な記述は Section B.1 [modules], page 99 参照。モジュール ‘tc’ を定義するには

次の行を加えます。

tc   yoyodyne/tc

3. ‘modules’ ファイルを格納します。

$ cvs commit -m "Added the tc module." modules
4. モジュール ‘modules’ を release します。
$ cd ..
$ cvs release -d CVSROOT

28 CVS—Concurrent Versions System (in japanese)

Chapter 6: 複数の開発者 29

6 複数の開発者

複数の人間でソフトウェア開発を行なうと、色々面倒が起こります。例えば 2 人の人物が、同じファイルを同時に編集しようとすることがよくあります。解決策の 1 つは、ファイル占有(file locking) または独占取得(reserved checkouts) と呼ばれるもので、同時にファイルを編集できる人数を 1 人に制限するものです。 rcs や sccs 等の履歴管理システムでは、これが唯一の方法です。 cvs の独占取得の実装は (まだ) 美しいも

のではありませんが、動作可能です (例えば、 Section A.5.1 [admin options], page 75 の cvs admin -l

コマンドを参照して下さい)。また後述する監視機構を、適切な手順を踏んで用いれば、同時編集を避けることが可能です。

cvs の既定モデルは無条件取得(unreserved checkouts) と呼ばれるもので、開発者がそれぞれ自分の作業コピー(working copy) を編集します。最初に変更を格納した人物は、他の人物が編集を始めたことが自動的には分りません。二番目の人物が格納する時にはエラー表示を受けますから、 cvs コマンドを用いて、自分の作業コピーを最新のものにする必要があります。この手順はほぼ自動化されています。

cvs は、独占取得などの規則を強制することなく、種々の意志疎通を容易にする仕組みを用意しています。

この章の残りでは、色々なモデルの動作と、各モデルの選択に伴なう問題点について述べます。

6.1 ファイル状態

取り出した後にあなたが加えた操作や、他の人物がリポジトリに加えた操作によって、ファイルを幾つかの状態に分類します。 status コマンドによって報告される状態を以下に挙げます:

Up-to-date

このファイルは、使用している枝の最新リビジョンと同じです。

Locally Modified

このファイルを編集したが、まだ変更内容を格納していない。

Locally Added

add コマンドによりファイルを加えたが、まだその内容を格納していない。

Locally Removed

remove コマンドによりファイルを削除したが、まだその変更を格納していない。

Needs Checkout

他の人物が新しいリビジョンをリポジトリに格納したことを示す。この表示は少し紛らわしいのですが、新しいリビジョンを得る時に、 checkout ではなく、通常 update を使用して下さい。

Needs Patch

Needs Checkout と似たようなものだが、 cvs のサーバは、ファイル全てではなく差分を送る。差分を送る場合も、ファイル全てを送る場合と結果は同じです。

Needs Merge

他の人物が新しいリビジョンをリポジトリに格納したが、あなたもこのファイルを編集中であったため、マージする必要がある。

Unresolved Conflict

Locally Modified と似たようなものだが、先の update コマンドによって、変更点の重複が発

見されたことを示す。重複を解消する必要があり、その説明は Section 6.3 [Conflicts example], page 30 参照。

Unknown このファイルについて cvs は何も知らないことを示す。例えば、新たにファイルを作り add を実行していない場合などである。

status は、ファイル状態を分類する際の補助として、作業中のファイルの由来となるリビジョンを示す

Working revision と、使用中の枝のリポジトリにおける最新リビジョンを示す Repository revision も

報告します。

status コマンドのオプションについての情報は、 Section A.16 [status], page 94 参照。 Sticky tag と Sticky date についての情報は、 Section 7.4 [Sticky tags], page 42 参照。 Sticky options の情報は、 Section A.18.1 [update options], page 96 の ‘-k’ オプションを参照して下さい。

6.2 ファイルを最新にする

ファイルを更新 or マージしたい場合には、 update コマンドを使用します。これは更新されていないファイルに対しては checkout コマンドと等価です。

update コマンドを使用することにより、あなたの修正が失なわれることはありません。より新しいバージョンが無い場合には、 update は何もしません。あなたがファイルを修正しており、新しいバージョンが入手可能ならば cvs は全ての変更をマージします。

例えばリビジョン 1.4 を取り出して、編集を始めるとします。その合間に他の人物がバージョン 1.5 を格納し、またすぐに 1.6 になったとします。ここで update コマンドを使用した場合に、 cvs は 1.4 と 1.6 間の変更を、あなたのファイルに組み入れます。

1.4 と 1.6 間の変更が、あなたの変更と似たようなものであれば、重複(overlap) が起きます。このような場合には警告が出力され、ファイルには重複した行が二つとも含まれ、特別な印が付けられます。 update コ

マンドの詳細は Section A.18 [update], page 96 参照。

6.3 衝突の例

リビジョン 1.4 の ‘drive.c’ は次のような内容です:

     #include <stdio.h>
     void main()
     {
         parse();
         if (nerr == 0)
             gencode();
         else
             fprintf(stderr, "No code generated.\n");
         exit(nerr == 0 ? 0 : 1);
     }

リビジョン 1.6 では ‘drive.c’ は次のようになっています:

     #include <stdio.h>

int main(int argc,
         char **argv)
{
    parse();
    if (argc != 1)
    {
        fprintf(stderr, "tc: No args expected.\n");
        exit(1);
    }
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
    exit(!!nerr);
}

で、 1.4 を元にしたあなた自身の作業ファイルは、次のようになっています:

#include <stdlib.h>
#include <stdio.h>
void main()
{
    init_scanner();
    parse();
    if (nerr == 0)
        gencode();
    else
        fprintf(stderr, "No code generated.\n");
    exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

この時 ‘cvs update’ を実行してみます:

$ cvs update driver.c
RCS file: /usr/local/cvsroot/yoyodyne/tc/driver.c,v
retrieving revision 1.4
retrieving revision 1.6
Merging differences between 1.4 and 1.6 into driver.c
rcsmerge warning: overlaps during merge
cvs update: conflicts found in driver.c
C driver.c

上のように表示され、 cvs は衝突が起きたことを知らせます。あなたが編集したオリジナルのファイルは、 ‘.#driver.c.1.4’ という名前で保存されます。 ‘driver.c’ の新しいバージョンは次のようになります:

#include <stdlib.h>
#include <stdio.h>

int main(int argc,
     char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
    fprintf(stderr, "tc: No args expected.\n");
    exit(1);
}
if (nerr == 0)
    gencode();
else
    fprintf(stderr, "No code generated.\n");
<<<<<<< driver.c
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
=======
exit(!!nerr);
>>>>>>> 1.6
}

重複しなかった修正がどの様に組み込まれているか注意して下さい。重複した部分は、 ‘<<<<<<<’, ‘=======’ 及び ‘>>>>>>>’ で囲まれた部分です。

衝突が起きた部分はファイルを編集して解決し、印を消す必要があります。最終例を次に挙げます:

#include <stdlib.h>
#include <stdio.h>
int main(int argc,
     char **argv)
{
init_scanner();
parse();
if (argc != 1)
{
    fprintf(stderr, "tc: No args expected.\n");
    exit(1);
}
if (nerr == 0)
    gencode();
else
    fprintf(stderr, "No code generated.\n");
exit(nerr == 0 ? EXIT_SUCCESS : EXIT_FAILURE);
}

そしてこのファイルを格納してリビジョン 1.7 とします。

$ cvs commit -m "Initialize scanner. Use symbolic exit values." driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c

     new revision: 1.7; previous revision: 1.6
     done

衝突が起きて未解決のファイルは、安全を考慮して、 cvs が格納することを拒否します。衝突を解決するとき、ファイルの編集時間を変更し、ファイルに含まれる全ての衝突マークを消す必要があります。もし合法的に衝突マークが含まれていた場合 (行頭に ‘>>>>>>> ’ があっても衝突と解釈されません)、 cvs の動作がおかしくなるため、ファイル CVS/Entries や関連するところを、ハッキングする必要があります。

もしあなたが pcl-cvs (gnu Emacs 用 cvs フロントエンド) の、 1.04 よりも新しいリリースを使用しているならば、衝突を解決するのに ‘emerge’ という Emacs パッケージが利用できます。 pcl-cvs の文書を見て下さい。

6.4 格納したことを他の人に知らせる

あなたが変更内容を格納して、新しいリビジョンになったことを、他の人に知らせると何かと便利です。 ‘moduels’ か ‘loginfo’ ファイルの ‘-i’ オプションにより、この手順を自動化することができます (Sec-

tion B.1 [modules], page 99, Section B.6 [loginfo], page 104 を参照)。この機構により、例えば全ての開

発者にメールを出したり、ニュースに記事を投稿したりすることができます。

6.5 同時に CVS の実行を試みる複数の開発者

複数の開発者が同時に cvs を実行しようとした場合、次のようなメッセージが表示されます:

     [11:43:23] waiting for bach's lock in /usr/local/cvsroot/foo

cvs は 30 秒毎に実行を試み、まだ待つ必要があれば再度メッセージを表示し、そうでなければ処理を続けます。不適当な程長く待ち続けているようならば、ロックさせている人物を見付けて、実行中の cvs コマンドを訊いてみて下さい。 cvs コマンドが実行されてないのならば、リポジトリで ‘#cvs.tfl’, ‘#cvs.rfl’, ‘#cvs.wfl’ 等で始まるファイルを捜して、削除して下さい。

このロックは cvs の内部データ構造を保護するもので、 rcs で使用されるロック(lock) という言葉とは全く何の関係もありません。 rcs のロックについては、独占取得についての記述を参照して下さい (see Chapter 6

[Multiple developers], page 29)。

任意のリポジトリから何人でも、同時に読み出すことが可能です。誰かが書き込み中の場合にだけ、他の人の読み出しや書き込みが禁止されます。

次に示すような機能を望む人がいるでしょう

ある人物が、 1 つの cvs コマンドで複数の変更点を格納した時、他の人がファイルを更新すると、全ての変更点が更新されるか、全く更新されないかのどちらかである。

が、 cvs にこの機能はありません。例えば、次のファイルがあるとします。

     a/one.c
     a/two.c

     b/three.c
     b/four.c

そしてある人物が次のコマンドを実行し、

     cvs ci a/two.c b/three.c

同時に誰か他の人が cvs update を実行した場合、更新されるのは ‘b/three.c’ の変更点のみで、 ‘a/two.c’ の変更点は更新されません。

6.6 ファイル編集者の追跡機構

多くのグループは、 cvs を既定状態で使用して、完全に満足しています。しかし、使用者が自分の修正点を格納した際に、他人の修正点との重複が見つかる事があり、重複を処理して再び格納する必要があります。あるグループでは、誰がどのファイルを編集中か分るようにしています。従って、 2 人で同じファイルを編集する場合、誰が何時何をするのか相談できるため、格納時に驚かされずに済みます。この節では、このような調整作業を行なう機能について説明しますが、 2 人の開発者が同時に同じファイルを編集する能力は維持されます。

開発者は、編集するファイルを読み書き可能にする時に、 (chmod でなく) cvs edit を使用し、もう使用しない作業ディレクトリを処分する時に、 (rm でなく) cvs release を使用するのが最も良いでしょう。しかし、 cvs はこれらの手順を強制する事は出来ません。

6.6.1 監視するファイルを CVS に教える

監視機能を有効にするには、まずそのファイルが監視されるように指定する必要があります。

Command cvs watch on [-l] files …

この指定以降、 files を編集する前に、開発者は cvs edit を実行する必要があります。開発者が、編集前に cvs edit を実行するのを忘れない様に、 cvs は files の読み込みだけを許可します。

files がディレクトリを含む場合、リポジトリの対応するディレクトリ内の全てのファイルに加え、将来ディレクトリに加えられるファイル全てが、 cvs の監視対象になります。これにより、使用者はディレクトリ毎に通知方針を設定できます。オプション -l が指定されない限り、ディレクトリの内容は再帰的に処理されます。

files が省略された場合、現在のディレクトリが指定されたと解釈されます。

Command cvs watch off [-l] files …

files が編集された時の通知を行ないません。 cvs は files の作業コピーを読み書き可能にします。

files や -l を引数に指定した時の振舞いは、 cvs watch on の場合と同じです。 6.6.2 誰に通知するか CVS に教える

あるファイルに対して種々の操作が行われた時に通知を受けたい場合には、その旨を cvs に知らせます。そのファイルに対して cvs watch on を用いなくても、通知の要求は可能です。しかし、開発者がコマンド cvs edit を用いるとは限らないため、通常は cvs watch on を用いた方が良いでしょう。

Command cvs watch add [-a action] [-l] files …

files に対して操作が行なわれた時に、通知を受けるように設定されます。

オプション -a は、 cvs に通知して欲しい事項を指定します。 action は次のうちのどれかです:

edit あなた以外の人物が、ファイルに対してコマンド cvs edit(後述) を適用した場合。

unedit あなた以外の人物が、ファイルに対してコマンド cvs unedit(後述) または cvs release を適用した場合。また、ファイルが消されて cvs update により再度生成された場合。

commit あなた以外の人物が、ファイルに対する変更を格納した場合。

all 上記全て。

none 上記以外。 (これは後述の cvs edit で有用です。 )

オプション -a は何度指定しても良いし、全く指定しなくても構いません。省略された場合には、 all が指定されたと解釈します。

オプション files や -l の取り扱いは、 cvs watch on の場合と同じです。

Command cvs watch remove [-a action] [-l] files …

cvs watch add で設定した通知要求を取り下げます。オプションは同じです。オプション -a を用いた場合、指定された事項に対する通知のみを停止します。

通知すべき状態が発生した時、 cvs は管理用ファイル ‘notify’ を見ます。 ‘notify’ は他の管理用ファイ

ルと同じように編集して下さい。 (see Section 4.3 [Intro administrative files], page 18)。管理用ファイルの慣例に従って (see Section B.3.1 [syntax], page 101)、このファイルの各行には、正規表現に続いて実行

されるコマンドが記述されます。コマンドは、通知すべき使用者に置換される ‘%s’ という文字列を、 1 つだけ含む必要があり、通知される残りの情報はコマンドの標準入力に与えられます。ファイル notify に標準で書かれている行を次に示します:

ALL mail %s -s \"CVS notification\"

これにより、使用者に電子メールで通知が行なわれます。

上記そのままの方法で設定した場合、使用者はサーバ上で通知を受ける事に注意して下さい。他の場所に通知するには、もちろん ‘notify’ に記述しても良いのですが、 cvs ではもっと簡単に各使用者の通知先を設定できます。 ‘CVSROOT’ に ‘users’ というファイルを作成し、 user:value という書式で、各使用者について一行ずつ記述して下さい。 cvs は、 ‘notify’ に記述された user の代りに、 value (通常は別のマシンのメールアドレス) に通知します。 6.6.3 監視下にあるファイルの編集方法

監視下にあるファイルを取り出した場合、読み込みだけが許可されるため、単純に編集はできません。読み書きを可能にし、そのファイルを編集する意図を他の人に伝えるために、 cvs edit コマンドを使用して下さい。上記の作業を checkout と呼ぶシステムもありますが、 cvs ではこの用語をソースのコピーを得る (取

り出す) という意味で用います (see Section 3.1 [Getting the source], page 11)。他のシステムでは、この

操作は get とか fetch と呼ばれます。

Command cvs edit [options] files …

作業ファイル files を編集する準備をします。 cvs は files の読み書きを許可し、 files に対する edit 通知を求める使用者に通知します。

cvs edit コマンドでは、 cvs watch add コマンドと同じ options を使用し、一時的に files

を監視できます。 cvs は、 files が unedit もしくは commit された場合に、監視を止めます。使用者が告知を受けたくない場合には、 -a none を指定して下さい。

オプション files や -l の取り扱いは、 cvs watch コマンドの場合と同じです。

変更を全て終えた場合、通常は cvs commit を用いて、監視下にあるファイルの変更点を確認し、読み込みだけが許可された状態に戻します。しかし、途中で変更を止めたり、何も変更しないと決めた場合には、 cvs unedit コマンドを使用します。

Command cvs unedit [-l] files …

作業ファイル files に加えた変更を捨て、変更前のリポジトリのバージョンに戻します。 files に対して、 cvs watch on による通知要求がある場合、 cvs は files の読み込みだけを許可します。また cvs は、 files に対する unedit の通知を要求する使用者に、通知を行ないます。

オプション files や -l の取り扱いは、 cvs watch コマンドの場合と同じです。

ファイルが監視されていない場合には、 unedit コマンドはたぶん何もしません。リポジトリのバージョンに戻したい場合、ファイルを削除してから cvs update で新たにコピーを取得して下さい。これは正確には同じ意味ではなく、削除して更新した場合には、あなたが最後に更新した後にリポジトリに加えられた変更も付随します。

cvs のクライアント/サーバを使用していて、サーバとうまく接続できなかった場合でも、 cvs edit や cvs unedit コマンドが使用できます。次に cvs コマンドが成功した時に、一緒に通知が行なわれます。

6.6.4 誰が監視や編集をしているか

Command cvs watchers [-l] files …

現在、 files の変更を監視している人物の一覧を表示します。監視されているファイルと、各監視者のメールアドレスが報告されます。

引数 files や -l の取り扱いは、 cvs watch コマンドの場合と同じです。

Command cvs editors [-l] files …

現在、 files を編集している人物の一覧を表示します。各編集者のメールアドレス、編集作業を開始した時間、ファイルが置かれた作業ディレクトリのパス名とホスト名が報告されます。

引数 files や -l の取り扱いは、 cvs watch コマンドの場合と同じです。

6.6.5 古いバージョンの CVS と監視機能

監視機能を使用している場合、リポジトリに ‘CVS’ というディレクトリが作成され、このディレクトリに監視情報が格納されます。このリポジトリに対して、 cvs 1.6 以前のものを使用した場合には、以下のエラーメッセージが出力されます。

     cvs update: cannot open CVS/Entries for reading: No such file or directory

そして操作が途中で終了します。監視機能を使用するためには、このリポジトリを利用するクライアント/ サーバ両方で、 cvs を新しいものと交換する必要があります。もし新しいものと交換できない場合には、 watch off と watch remove コマンドを用いて全ての監視を削除すれば、リポジトリを cvs 1.6 が利用できる状態に再構築できます。

6.7 独占取得と無条件取得の選択

独占取得、無条件取得それぞれに一長一短があります。ここでは、この問題を簡単に説明しますが、残りの多くは個人的な見解の相違や、各グループの作業スタイルの相違だと思います。開発者チームを構成するには様々な方法があります。 cvs は特定の構成を強制せず、各自の方法で利用できる道具です。

独占取得には、非常に非生産的な部分があります。 2 人が同じファイルを編集する場合でも、編集部分が異なる場合には、どちらか一方の編集を禁止する必要は全くありません。また、ファイルを編集するためにロックした後、ロック解除を忘れてしまうことが、普通に起こり得ます。

独占取得に特別な安心感を持つ人々は、無条件取得を用いた場合の衝突の多さや、それを解決する困難さを、よく訴えます。しかし多くのグループの経験から言うと、衝突は稀であり、解決も普通は比較的簡単なものです。

衝突を何度も経験すれば、コード設計に正しく従わなかった場合にだけ、重篤な衝突が発生することが理解できます。このような衝突は、最初にチーム内で十分に話し合えば避けられることです。どのようなソース管理方法を採るにしても、開発者が共同で作業する際には、システム全体の設計方針に従わなければいけません。きちんと従っていれば、簡単にマージできる重複ばかりになるでしょう。

無条件取得が、全く不適当な場合があります。管理下にあるファイルの形式をマージする道具が無く (例えばワード・プロセッサによるファイルや、 CAD プログラムで編集されたファイル等)、マージ可能なデータ書式を使用するようにプログラムを変更できない場合、悪夢のような衝突解決をするよりは、独占取得を用いて簡単に衝突を避けたほうが賢明でしょう。

前述 (Section 6.6 [Watches], page 34) の監視機構は、独占取得と無条件取得の中間的なものと考えられます。ファイルを編集する前に、他の誰がファイルを編集中なのか調べることができます。これは単純に双方の同時編集を禁止するのではなく、現況を報告し、それが問題かどうかは自分で判断してもらいます。これを適切に使用すれば、独占取得と無条件取得の中でも最善の選択となるでしょう。

38 CVS—Concurrent Versions System (in japanese)

Chapter 7: 枝 39

7 枝

ここまでの説明では、リビジョン・ツリーの幹 (main trunk) を扱ってきました。つまりリビジョン番号が x.y の形になるものです。しかし、同時に複数のリリースを維持する必要があれば、リビジョン・ツリーに枝を作った方が良いでしょう。ここでは、リビジョンを表わす文字列であるタグ(Tags) について説明します。

7.1 タグ–文字によるリビジョン

リビジョン番号は勝手に増えていくため、あなたのソフトウェアのリリース番号とは全く何の関係もありません。異なる 2 つのリリース間では、 cvs が決めるリビジョン番号は異なっているでしょう。例えば cvs 5.6 を作るソース・ファイルは、次のようなリビジョン番号を持ちます。

     ci.c            5.21
     co.c            5.9
     ident.c         5.3
     rcs.c           5.12
     rcsbase.h       5.11
     rcsdiff.c       5.10
     rcsedit.c       5.11
     rcsfcmp.c       5.9
     rcsgen.c        5.10
     rcslex.c        5.11
     rcsmap.c        5.2
     rcsutil.c       5.10

tag コマンドを用いて、ファイルの特定のリビジョンを表わすのに、文字列を用いることができます。また status コマンドに ‘-v’ フラグを付けることで、ファイルの持つ全てのタグと、そのタグが付けられたリビジョン番号を知ることができます。タグには、大文字, 小文字, 数字, ‘-’, ‘_’ が使用可能です。 BASE と HEAD の 2 つのタグ名は、 cvs が使用するために予約されています。実際のタグ名との重複を避けるため、 cvs に特別な名前は、 BASE や HEAD などでなく、 ‘%’ や ‘=’ 等の文字を使うようになれば良いと思います。

次の例は、ファイルにタグを付ける方法を示したものです。コマンドはあなたの作業ディレクトリで実行して下さい。このディレクトリ中に ‘backend.c’ というファイルがあるとします。

     $ cvs tag release-0-4 backend.c
     T backend.c
     $ cvs status -v backend.c
     ===================================================================
     File: backend.c         Status: Up-to-date
         Version:            1.4     Tue Dec  1 14:39:01 1992
         RCS Version:        1.4     /usr/local/cvsroot/yoyodyne/tc/backend.c,v
         Sticky Tag:         (none)
         Sticky Date:        (none)
         Sticky Options:     (none)
         Existing Tags:
             release-0-4                     (revision: 1.4)

単独のファイルにタグを付けるべき理由はほとんどありません。タグの主な使い途は、モジュールを構成する全てのファイルに同じタグを付け、開発の流れの重要点 (リリース時等) を示すことです。

     $ cvs tag release-1-0 .
     cvs tag: Tagging .
     T Makefile
     T backend.c
     T driver.c
     T frontend.c
     T parser.c

(cvs に対する引数にディレクトリを指定した場合は、そのディレクトリに含まれる全てのファイルが操作されます。そのディレクトリ以下の全てのサブディレクトリに対しても、再帰的に動作します。 See Chapter 9

[Recursive behavior], page 49。 )

‘-r’ フラグを付けた checkout コマンドによって、モジュールから取り出すリビジョンを指定します。このフラグを用いて、モジュール ‘ tc’ のリリース 1.0 を作るソースを、将来の何時でも簡単に復元することができます。

     $ cvs checkout -r release-1-0 tc

これは、あるリリースにバグが発見されたが、現在の作業コピーにはそのバグが無い、という場合などに非常に便利です。

蛇足ですが、任意の時間を指定してモジュールを復元することもできます (see Section A.6.1 [checkout

options], page 79)。

複数のファイルに同じタグを付けるという事を、「ファイル名とリビジョン番号の行列の中に引かれた線」と考えると良いでしょう。 5 つのファイルについてのイメージを次に示します。

             file1   file2   file3   file4   file5
             1.1     1.1     1.1     1.1  /--1.1*      <-*-  TAG
             1.2*-   1.2     1.2    -1.2*-
             1.3  \- 1.3*-   1.3   / 1.3
             1.4          \  1.4  /  1.4
                           \-1.5*-   1.5
                             1.6

ここで * の付けられたバージョンにタグが付けられています。ここでタグを「タグを付けられたリビジョンを通る線を扱う名前」と考えることができます。あるいはタグを付けられたリビジョンを水平に並べた方が、分り易いかも知れません。

             file1   file2   file3   file4   file5
                             1.1
                             1.2
                     1.1     1.3                       _
             1.1     1.2     1.4     1.1              /
             1.2*----1.3*----1.5*----1.2*----1.1     (--- <--- Look here
             1.3             1.6     1.3              \_
             1.4                     1.4
                                     1.5

7.2 枝が何の役に立つのか

‘tc’ のリリース 1.0 が作られたとしましょう。あなたは ‘tc’ の開発を続け、 2ヶ月でリリース 1.1 に上げる計画です。しばらくすると、顧客は致命的なバグについて文句を言ってきます。リリース 1.0 をチェックすると (see Section 7.1 [Tags], page 39)、バグが発見されました。しかし、現在のソースのリビジョンは流動的で、安定するにはまだ 1ヶ月くらい掛りそうです。つまり現在のソースを元にして、バグ・フィックス版を出すことが出来ないのです。

こんな状況の時に、 ‘tc’ のリリース 1.0 のあるリビジョン・ツリーから、枝(branch) を作るのです。これで幹に影響を与えることなく、枝に修正を加えることが出来ます。修正が終了した時点で、その修正を幹に戻すか、枝にそのまま残しておくか選択すれば良いのです。

7.3 枝を作る

枝を作るには rtag コマンドを使用します。 rtag コマンドは tag コマンドと似ていますが、あなたがモ

ジュールの作業コピーを持っていなくても使用できます (see Section A.15 [rtag], page 93)。もちろん tag コマンドも使えます (see Section A.17 [tag], page 95)。

     $ cvs rtag -b -r release-1-0 release-1-0-patches tc

‘-b’ フラグを立てることにより、 rtag コマンドは (タグ名を付けるだけでなく) 枝を作ります。 ‘-r release-1-0’ は、新しい枝の分岐点となるリビジョンが、 ‘release-1-0’ であることを示しています。リビジョン番号がファイルごとに異なるために、リビジョン番号で指定できないことに注意して下さい。そして新しい枝の名前を ‘release-1-0-patches’ とし、モジュール ‘tc’ に対して作業を始めます。

リリース 1.0 のバグを修正するために、あなたは枝から作業コピーを取り出します。

     $ cvs checkout -r release-1-0-patches tc
     $ cvs status -v driver.c backend.c
     ===================================================================
     File: driver.c          Status: Up-to-date
         Version:            1.7     Sat Dec  5 18:25:54 1992
         RCS Version:        1.7     /usr/local/cvsroot/yoyodyne/tc/driver.c,v
         Sticky Tag:         release-1-0-patches (branch: 1.7.2)
         Sticky Date:        (none)
         Sticky Options:     (none)

Existing Tags:
    release-1-0-patches             (branch: 1.7.2)
    release-1-0                     (revision: 1.7)
===================================================================
File: backend.c         Status: Up-to-date
Version:            1.4     Tue Dec  1 14:39:01 1992
RCS Version:        1.4     /usr/local/cvsroot/yoyodyne/tc/backend.c,v
Sticky Tag:         release-1-0-patches (branch: 1.4.2)
Sticky Date:        (none)
Sticky Options:     (none)
Existing Tags:
    release-1-0-patches             (branch: 1.4.2)
    release-1-0                     (revision: 1.4)
    release-0-4                     (revision: 1.4)

status コマンドの出力から判る通り、元になったリビジョン番号の最後に数字を付けて、枝番号が作られます。 (もし ‘release-1-0’ に対応するリビジョン番号が 1.4 ならば、枝のリビジョン番号は 1.4.2 になりま

す。秘密の理由から、 cvs は枝のリビジョン番号を 2 から始めます。 See Section 2.1 [Revision numbers], page 9。 )

7.4 貼り付けられたタグ

先の例で checkout 時に付けられたフラグ ‘-r release-1-0-patches’ は、各ファイルに貼り付けら

れ (sticky)、今後このディレクトリで実行されるコマンドに与えられます。ここでどのような修正を格納しても、それらは全て枝に加えられます。また後でこれらの修正を、幹に戻すこともできます。 See Chapter 8

[Merging], page 45。

status コマンドを使用すれば、貼り付けられているタグや日付を調べることができます。

$ vi driver.c   # Fix the bugs
$ cvs commit -m "Fixed initialization bug" driver.c
Checking in driver.c;
/usr/local/cvsroot/yoyodyne/tc/driver.c,v  <--  driver.c
new revision: 1.7.2.1; previous revision: 1.7
done
$ cvs status -v driver.c
===================================================================
File: driver.c          Status: Up-to-date
Version:            1.7.2.1 Sat Dec  5 19:35:03 1992
RCS Version:        1.7.2.1 /usr/local/cvsroot/yoyodyne/tc/driver.c,v
Sticky Tag:         release-1-0-patches (branch: 1.7.2)
Sticky Date:        (none)
Sticky Options:     (none)

         Existing Tags:
             release-1-0-patches             (branch: 1.7.2)
             release-1-0                     (revision: 1.7)

作業ファイルに貼り付けられたタグは、 ‘cvs update -A’ によって削除されるまで残ります。 ‘-A’ オプションは、ファイルを幹の先頭のバージョンに戻し、貼り付けられたタグ, 日付, オプションを全て忘れます。

貼り付け可能なタグは、枝だけではありません。ここでは、他人の変更が不安定かもしれず、大事を取って作業ディレクトリを更新したくない場合を、例に挙げて考えます。もちろんこの場合、 cvs update の実行を控えれば済みます。しかし、更新したくないのは大きな木の一部分だけといった場合、貼り付けられたタグが有用です。ソースを取り出す際に、 (1.4 などと) リビジョンを指定した場合には、そのリビジョンが貼り付けられます。以後、 cvs update -A によってタグを剥がすまで、 cvs update を実行しても最新リビジョンに更新されません。同様に ‘-D’ オプションを update や checkout に使うと、貼り付けられた日付(sticky date) が有効になります。つまり、以後の取り出しの際、この日付が使用されることになります。

古いバージョンのファイルを取り出す際に、タグを貼り付けたくない場合も多いと思います。 checkout や update にオプション ‘-p’ を付けると、ファイルの内容が標準出力に送られるので、これを利用します。例えば、リビジョン 1.1 のファイル ‘file1’ を削除したとします (削除後のリビジョンは 1.2 になります)。その後、以前と同じ内容で、再度このファイルを加えることになりました。この場合の手順を以下に示します:

     $ cvs update -p -r 1.1 file1 >file1
     ===================================================================
     Checking out file1
     RCS:  /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v
     VERS: 1.1
     ***************
     $ cvs add file1
     cvs add: re-adding file file1 (in place of dead revision 1.2)
     cvs add: use 'cvs commit' to add this file permanently
     $ cvs commit -m test
     Checking in file1;
     /tmp/cvs-sanity/cvsroot/first-dir/file1,v  <--  file1
     new revision: 1.3; previous revision: 1.2
     done
     $

44 CVS—Concurrent Versions System (in japanese)

Chapter 8: マージ 45

8 マージ

2 つのリビジョン間の変更を、マージによってあなたのファイルに反映することができます。そのリビジョンを格納すれば、その変更をさらに他の枝にコピーしていくことができます。

8.1 枝全体をマージする

update コマンドに ‘-j branch’ フラグを付けると、枝に加えられた変更を、あなたの作業コピーに与えることができます。 ‘-j branch’ オプションは、枝の分岐点と枝の最新リビジョン間の違いを、あなたの作業コピーにマージします。

‘-j’ は、 “join” とは違います。

次のリビジョン・ツリーを考えます。

     +-----+    +-----+    +-----+    +-----+
     ! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
     +-----+    +-----+    +-----+    +-----+
                     !
                     !
                     !   +---------+    +---------+
     Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                         +---------+    +---------+

枝 1.2.2 には ‘R1fix’ というタグ (文字列) が付けられています。次は ‘m.c’ というファイルを 1 つ持つモジュール ‘mod’ の例です。

$ cvs checkout mod # 最新のリビジョン 1.4 を取り出した

     $ cvs update -j R1fix m.c        # 枝で行なわれた変更 (リビジョン 1.2

# と 1.2.2.2 の差分) を作業コピーに加えた

     $ cvs commit -m "Included R1fix" # リビジョン 1.5 を作った

以上で衝突が起きることがありますが、衝突が起きた場合は、それを解決してから新しいリビジョンを格

納して下さい (see Section 6.3 [Conflicts example], page 30。 )

checkout コマンドでもフラグ ‘-j branch’ を使用できます。上記と同じ作業を次のようにできます。

     $ cvs checkout -j R1fix mod
     $ cvs commit -m "Included R1fix"

8.2 枝から何度もマージする

前節の例を続けると、現在のリビジョン・ツリーは次の様になっています:

+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
                !                           *
                !                          *
                !   +---------+    +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
                    +---------+    +---------+

前節で枝 ‘R1fix’ を幹にマージした事を、ここでは星線で表します。

次に、枝 ‘R1fix’ で開発が続けられたと仮定します:

+-----+    +-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !      <- The main trunk
+-----+    +-----+    +-----+    +-----+    +-----+
                !                           *
                !                          *
                !   +---------+    +---------+    +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
                    +---------+    +---------+    +---------+

この新しい変更を幹にマージする場合を考えます。ここで再び cvs update -j R1fix m.c コマンドを用いた場合、 cvs は既にマージされた変更点を重ねてマージしようとして、望ましくない結果をもたらします。

そこで、未だ幹にマージされてない変更点だけマージしたい旨、明示する必要があります。これには、 ‘-j’ オプションで 2 つのリビジョンを指定します。 cvs は、最初のリビジョンから次のリビジョン迄の変更をマージします。

cvs update -j 1.2.2.2 -j R1fix m.c    # 1.2.2.2 から、枝 R1fix の

# 先頭までの変更をマージする

この方法の問題点は、リビジョン 1.2.2.2 を自分で指定する必要がある事です。最後にマージが行われた日時を使用する方が、少しましでしょう:

cvs update -j R1fix:yesterday -j R1fix m.c

さらに良いのは、変更点を幹にマージする度に、枝 ‘R1fix’ にタグを振っておき、後でマージする時にそのタグを用いる方法です:

cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c

8.3 二つのリビジョン間の差分をマージする

update (checkout) コマンドに ‘-j revision’ フラグを 2 つ付けることで、 2 つのリビジョン間の違いを

あなたの作業コピーに加えることができます。

$ cvs update -j 1.5 -j 1.3 backend.c

Chapter 8: マージ 47

このようにするとリビジョン 1.3 と 1.5 間の変更を全て取り除くことになります。リビジョン指定の順序に十分注意して下さい。

複数のファイルを操作する時に、このオプションを付ける場合は、モジュールを構成するファイルごとに、リビジョン番号が異なることを思い出して下さい。複数のファイルを操作する場合には、リビジョン番号ではなく、必ずタグ名を用いるようにして下さい。

8.4 ファイルの追加や削除もマージできる

マージする変更点に、ファイルの削除や追加が伴なう場合でも、削除や追加を反映するには update -j を用います。

実行例:

     cvs update -A
     touch a b c
     cvs add a b c ; cvs ci -m "added" a b c
     cvs tag -b branchtag
     cvs update -r branchtag
     touch d ; cvs add d
     rm a ; cvs rm a
     cvs ci -m "added d, removed a"
     cvs update -A
     cvs update -jbranchtag

48 CVS—Concurrent Versions System (in japanese)

9 再帰的動作

cvs のコマンドは、ディレクトリを引数に取ったときに再帰的に動作します。例えば、次のディレクトリ構造を考えます。

$HOME
|
+--tc
|   |
+--CVS
|      (internal cvs files)
+--Makefile
+--backend.c
+--driver.c
+--frontend.c
+--parser.c
+--man
|    |
|    +--CVS
|    |  (internal cvs files)
|    +--tc.1
|
+--testing
     |
     +--CVS
     |  (internal cvs files)
     +--testpgm.t
     +--test2.t

現在のディレクトリが ‘tc’ であれば、次のようになります:

• ‘cvs update testing’ は ‘cvs update testing/testpgm.t testing/test2.t’ と等価である

• ‘cvs update testing man’ はサブディレクトリ中のファイルを更新する

• ‘cvs update .’ 又は ‘cvs update’ は、モジュール tc 中の全てのファイルを最新にする。

引数を付けない update コマンドは、現在のディレクトリ中の全てのファイルと、サブディレクトリを最新にします。 update コマンドだけでなく、他の全ての cvs コマンドでも同じです。

‘-l’ オプションを付けることによって、 cvs の再帰的な動作を抑止することができます。

$ cvs update -l # サブディレクトリのファイルは更新しない

50 CVS—Concurrent Versions System (in japanese)

10 ディレクトリにファイルを加える

ディレクトリにファイルを加える手順を説明します。

• ディレクトリの作業コピーが必要です。 See Section 3.1 [Getting the source], page 11。

• ディレクトリの作業コピーの中に、新しいファイルを作ります。

• ‘cvs add filename’ を用いて、バージョン管理に加えたいファイルを cvs に伝えます。ファイルがバイ

ナリ・データを含んでいる場合には、 ‘-kb’ を指定して下さい (see Chapter 17 [Binary files], page 67)。

• ‘cvs commit filename’ を用いて、実際にリポジトリにファイルを格納します。この手順を行なうまでは、他の開発者はファイルを見ることができません。

add コマンドは、新しいディレクトリを加える場合にも使用します。

他のほとんどのコマンドと異なり、 add コマンドは再帰的に動作しません。従って、 ‘cvs add foo/bar’ とタイプする代りに、次のようにする必要があります。

$ cd foo
$ cvs add bar

Command cvs add [-k kflag] [-m message] files …

files が加えられた事をリポジトリに伝えます。 add で指定されたファイルやディレクトリは、現在のディレクトリに存在しなくてはいけません。新しいディレクトリ階層の全てをリポジトリに加える場合は (例えばサード・パーティーからのファイル等)、代りに import コマンドを使用し

た方が良いでしょう。 See Section A.11 [import], page 87。

内容を commit で格納するまで、加えたファイルは実際にはリポジトリに置かれません。 remove コマンドで削除されたファイルに対して、 commit を発行する前に add を実行した場合、 remove

が無効になります。例は Chapter 11 [Removing files], page 53 参照。

オプション ‘-k’ には、今後ファイルを取り出す際の既定方法を指定します。詳細は Section 16.4

[Substitution modes], page 64 参照。

‘-m’ オプションには、ファイルの説明を記述します。 (ログ情報を記録する設定ならば) この説明

がファイル ‘history’ に記録されます (see Section B.9 [history file], page 106)。またファイ

ルを格納する際、リポジトリの履歴ファイルにも記録されます。 log コマンドでこの説明を表示

します。 ‘admin -t’ を用いて、この説明を変更できます。 See Section A.5 [admin], page 75。

フラグ ‘-m description’ を省略した場合、空の文字列が使用され、説明を記述するよう促されることはありません。

例えば、以下のコマンドでファイル ‘backend.c’ がリポジトリに加えられます:

$ cvs add backend.c
$ cvs commit -m "Early version. Not yet compilable." backend.c

加えたファイルは、作業中の枝だけに加えられます (see Chapter 7 [Branches], page 39)。他の枝にも加えたい場合は、後でマージすることができます (see Section 8.4 [Merging adds and removals], page 47)。 52 CVS—Concurrent Versions System (in japanese)

11 モジュールからファイルを削除する

モジュールの変更に伴なって、新しいファイルが加えられ、古いファイルが消えていきます。しかし、モジュールの古いバージョンの、正確なコピーを復元したいと思うでしょう。

ここで、古いバージョンの復元が可能なまま、モジュールからファイルを削除する手順を説明します:

• ファイルに加えた修正は、必ず格納しておかなくてはなりません。その方法は Section 3.4 [Viewing

differences], page 12 参照。また、 status や update といったコマンドも使用できます。あなたの修

正を格納しないでファイルを消した場合、以前の状態を復元することは不可能になります。

• モジュールの作業コピーからファイルを削除するには、 rm などを使っても良いでしょう。

• ファイルを削除する意思を cvs に伝えるには、 ‘cvs remove filename’ を使います。

• リポジトリからファイルを実際に削除するには、 ‘cvs commit filename’ を使います。

ファイルの削除を格納する場合、 cvs は、ファイルがもう無いという事実を記録します。ファイルが他の枝に存在していても良いし、後で別のファイルを同じ名前で加えても構いません。 checkout や update に指定するオプション ‘-r’ や ‘-D’ に応じて、 cvs が正しくファイルを作成したり、しなかったりします。

Command cvs remove [-lR] files …

ファイルが削除された事実をリポジトリに伝えます (作業ディレクトリから未削除のファイルは処理されません)。このコマンドを実行しても、リポジトリのファイルは、削除が格納されるまで実際には削除されません。オプション ‘-R’ (既定値) を指定した場合、サブディレクトリまで再帰的に処理されますが、 ‘-l’ を指定した場合は再帰的に処理されません。

以下に、幾つかファイルを削除する例を挙げます:

     $ cd test
     $ rm ?.c
     $ cvs remove
     cvs remove: Removing .
     cvs remove: scheduling a.c for removal
     cvs remove: scheduling b.c for removal
     cvs remove: use 'cvs commit' to remove these files permanently
     $ cvs ci -m "Removed unneeded files"
     cvs commit: Examining .
     cvs commit: Committing .

格納前に気が変わったのなら、 add コマンドを用いて、簡単にファイルを復活させることができます。

     $ ls
     CVS   ja.h  oj.c
     $ rm oj.c
     $ cvs remove oj.c
     cvs remove: scheduling oj.c for removal
     cvs remove: use 'cvs commit' to remove this file permanently
     $ cvs add oj.c
     U oj.c
     cvs add: oj.c, version 1.1.1.1, resurrected

remove コマンドを実行する前に失敗に気付いた場合、 update コマンドを用いてファイルを復活できます:

$ rm oj.c
$ cvs update oj.c
cvs update: warning: oj.c was lost
U oj.c

削除したファイルは、作業中の枝だけから削除されます (see Chapter 7 [Branches], page 39)。他の枝からも削除したい場合は、後でマージすることができます (see Section 8.4 [Merging adds and removals], page 47)。

12 サード・パーティーのソースの追っかけ

あなたのサイトに合うようにプログラムに修正を加える場合、そのプログラムの次のリリースにも同じ修正を加えたいでしょう。 cvs はその仕事を助けることができます。

cvs の用語では、プログラムの開発元をベンダー(vendor) と呼びます。ベンダーの配布物は、修正を加えずにベンダー枝(vendor branch) という枝に格納します。 cvs はこの為に 1.1.1 という番号を予約しています。

あなたがソースを修正して格納した場合、あなたのリビジョンは幹の最後になります。ベンダーから新しいリリースが届くと、それをベンダー枝に加えて、修正を幹にコピーします。

ベンダー枝を作り、更新するには、 import コマンドを使用します。 import が成功すると、ベンダー枝に最初のリビジョンが作られ、誰でも checkout できるようになります。格納されたローカルな修正は、幹に置かれ、最初のリビジョンが作られます。

12.1 まずモジュールを持ち込む

まず最初に、 import コマンドを使ってソースを登録します。 import コマンドでサード・パーティーの追っかけをする場合には、ベンダー・タグ(vendor tag) とリリース・タグ(release tags) が便利です。ベンダー・タグは枝のタグ名です (‘-b branch’ フラグを使用しなければ、枝のリビジョンは常に 1.1.1 です—

Section A.11.1 [import options], page 88 参照)。リリース・タグは特定のリリースを指すタグ名で、ここでは ‘FSF_0_04’ とします。

wdiff というコマンドに、将来のリリースでも通用する個人的な修正を加えることにします。まず、リポジトリに wdiff のソースを加えることから始めましょう。 (wdiff は diff の変形で、空白のみの変更を無視します。 )

     $ tar xfz wdiff-0.04.tar.gz
     $ cd wdiff-0.04
     $ cvs import -m "Import of FSF v. 0.04" fsf/wdiff FSF_DIST WDIFF_0_04

上の例では、ベンダー・タグを ‘FSF_DIST’ とし、リリース・タグを ‘WDIFF_0_04’ としています。

12.2 import コマンドでモジュールを更新する

新しいリリースのソースが届いたら、それを最初と同じく import コマンドでリポジトリに加えます。違いは、最初と異なるリリース・タグを用いることだけです。

     $ tar xfz wdiff-0.05.tar.gz
     $ cd wdiff-0.05
     $ cvs import -m "Import of FSF v. 0.05" fsf/wdiff FSF_DIST WDIFF_0_05

ファイルがローカルな修正を受けてなければ、今加えたものが最初のリビジョンになります。ローカルな変更を加えていれば、 import コマンドは変更を幹にマージするように警告を出し、 ‘checkout -j’ を使うように促します。

     $ cvs checkout -jFSF_DIST:yesterday -jFSF_DIST wdiff

このコマンドで ‘wdiff’ の最新のリビジョンが取り出され、 ‘yesterday’ までにベンダー枝 ‘FSF_DIST’ に加えられた変更を、作業コピーにマージします。マージの過程で衝突が起きれば、通常の方法で解決して下さ

い (see Section 6.3 [Conflicts example], page 30)。その後、変更したファイルを格納します。

上記の実行例のように日時を使用する場合、 1 日に 1 つ以上のリリースを import しないと仮定しています。この仮定に反するならば、次のようにして下さい。

     $ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff

今の例では、上の 2 つのコマンドは等価です。

12.3 cvs import 時のバイナリ・ファイルの扱い

取り込む際に、包装を指定するオプション ‘-k’ を用いて、どのファイルがバイナリなのか伝えて下さい。

See Section B.2 [Wrappers], page 100。 Chapter 13: ファイルの改名と移動 57

13 ファイルの改名と移動

ファイルを他のディレクトリに移動したり、改名したりするのは、難しくはありません。しかし、難解な方法でこれを実現するものがあります。 (ディレクトリの移動と改名は、より困難です。 See Chapter 14 [Moving

directories], page 59)。

以降の例では、 old というファイルを new に改名します。

13.1 通常の改名方法

ファイルを移動する通常の方法は、 old を new にコピーして、普通の cvs コマンドで old をリポジトリから削除し、 new を加えることです。 (old と new には、 ‘foo/bar.c’ といった相対パスを用いることもできます。 )

$ mv old new

     $ cvs remove old
     $ cvs add new
     $ cvs commit -m "Renamed old to new" old new

これがファイルを移動する最も単純な方法であり、間違いがなく、この操作の履歴も記録されます。このファイルの履歴を利用する際、古い名前か、新しい名前のどちらかを指定して、履歴のどの部分が欲しいのか知らせなくてはいけません。例えば、 cvs log old を実行しても、改名が行なわれた時までのログ情報しか得られません。

new が格納される場合には、リビジョン番号は再び 1.0 から始まります。それが嫌ならば、格納時にオプ

ション ‘-r rev’ を用いると良いでしょう (see Section A.7.1 [commit options], page 81)。

13.2 履歴ファイルを移動する

この方法は、リポジトリ中のファイルの移動を含むため、さらに危険です。この節を全部読んでから実行して下さい。

     $ cd $CVSROOT/module
     $ mv old,v new,v

利点:

• 変更の記録が完全に保たれる。

• リビジョン番号に影響がない。

欠点:

• リポジトリから、モジュールの古いリリースを簡単に復元できない。 (改名される以前のリビジョンでもファイルの名前が new になる。 )

• ファイルがいつ改名されたかの記録がない。 • ファイルの移動の最中に、誰かが履歴ファイルにアクセスした場合、酷いことが起きる。あなたがファイ

ルを移動させている間は、誰にも cvs コマンドを発行させてはいけません。

13.3 履歴ファイルをコピーする

この方法も、リポジトリ中のファイルの移動を含みます。欠点が無い訳ではありませんが、安全です。

# リポジトリ中の rcs ファイルをコピーする

   $ cd $CVSROOT/module
   $ cp old,v new,v

# 以前のファイルを削除する

$ cd ~/module

   $ rm old
   $ cvs remove old
   $ cvs commit old

# new の全てのタグを削除する

   $ cvs update new

$ cvs log new # 枝でないタグ名を思い出す

   $ cvs tag -d tag1 new
   $ cvs tag -d tag2 new

…

タグを削除することで、モジュールの以前のリビジョンを復元することができます。

利点:

• ‘-rtag’ や、 ‘-Ddate’ を使うことで、以前のリビジョンのファイルを正しく復元できる。

• 変更の記録を完全に維持できる。

• リビジョン番号に影響しない。

欠点:

• 改名の前後で履歴を辿ることが困難である。

• ‘-r rev’ フラグを付けて commit しないと、 new のリビジョン番号はまた 1.0 から始まる (see Sec-

tion A.7.1 [commit options], page 81)。 Chapter 14: ディレクトリの改名と移動 59

14 ディレクトリの改名と移動

モジュールの以前のバージョンも復元可能にしたいならば、ディレクトリの中の各ファイルも、 cvs コマ

ンドで移動させる必要があります (see Section 13.1 [Outside], page 57)。古い、空のディレクトリがリポジ

トリ中に残されますが、将来モジュールを取り出すときに、作業領域に現われることはありません。

実際にディレクトリを改名あるいは削除する場合には、次のようにして下さい:

1. ディレクトリを改名する前に、モジュールの作業コピーを持っている全ての人に、その旨を知らせます。次のステップに進む前に、彼等全員が変更内容を格納し、作業コピーを削除しなければなりません。

2. リポジトリ中のディレクトリを改名します。

         $ cd $CVSROOT/module

$ mv old-dir new-dir

3. cvs の管理用ファイルを修正します。 (例えばモジュール名を改名する場合等)。

4. モジュールを取り出して作業を続けられることを、全員に知らせます。

誰かがモジュールの作業コピーを消さずに持っていた場合、彼がリポジトリから消されたディレクトリを削除するまで、彼の発行する cvs コマンドは無視されます。

ディレクトリを移動させるよりは、ディレクトリ中のファイルを移動させる方を推奨します。ディレクトリを移動させれば、ディレクトリ名に依存している古いリリースを正確に復元する事は、ほとんど不可能になります。

60 CVS—Concurrent Versions System (in japanese)

Chapter 15: 履歴の閲覧 61

15 履歴の閲覧

何時、誰が、どのように、どのファイルを変更したか、といったバージョン管理の履歴を、 cvs を使って保存してきたならば、様々な機構を用いてこの履歴を調べることができます。

15.1 ログ・メッセージ

ファイルを格納する時には、必ずログ・メッセージを記述します。

各リビジョンの格納時に記述されたログ・メッセージを調べる場合、 cvs log コマンドを使用して下さい

(see Section A.12 [log], page 89)。

15.2 履歴データベース

様々な cvs の実行履歴を記録するために、ファイル ‘history’ が使用できます (see Section B.9 [history file], page 106)。ファイル ‘history’ の情報を検索するには、 cvs history コマンドを使用して下さい (see Section A.10 [history], page 85)。

15.3 ログ方法を使用者自身が設定する

cvs を用いた様々な作業の履歴は、利用者自身が選択する方法で記録されます。 cvs は、様々な場面でスクリプトを実行し、この機構を実現します。これらのスクリプトには、ログ・ファイルに情報を追記したり、開発者グループにメールを送ったり、特定のニュース・グループに記事を投稿したりするものがあります。格納時の

ログ方法は ‘loginfo’ で設定します (see Section B.6 [loginfo], page 104)。 commit, checkout, export, tag 等を実行した時のログ方法は、各々オプション ‘-i’, ‘-o’, ‘-e’, ‘-t’ を用いて、ファイル ‘modules’ に

設定できます。これらのスクリプトほどのものは必要としない使用者にも、 cvs watch add コマンドを使用

して、様々な告知をする弾力的な方法を提供します (see Section 6.6.2 [Getting Notified], page 35)。この

方法は cvs watch on を使用していない場合でも利用できます。

誰かが tag か rtag コマンドを実行した時に実行されるプログラムを、 ‘taginfo’ ファイルに設定しま

す。管理用ファイルの標準書式に従い (see Appendix B [Administrative files], page 99)、 ‘taginfo’ の各

行には、正規表現に続いて実行されるコマンドが記述されます。コマンドに渡される引数を順に挙げると、タ

グ名, 操作(tag なら add, tag -F なら mov, tag -d なら del), リポジトリ, 残りは全てファイル名とリ

ビジョンの組です。フィルタ・プログラムが非零で終了した場合は、タグ処理が中止されます。

15.4 コマンド annotate

Command cvs annotate [-lf] [-r rev|-D date] files …

files で指定された各ファイルについて、幹の先頭リビジョンの内容と、各行が最後に修正された時の情報を、併せて表示します。以下に例示します:

          $ cvs annotate ssfile
          Annotations for ssfile
          ***************

1.1          (mary     27-Mar-96): ssfile line 1
1.2          (joe      28-Mar-96): ssfile line 2

ファイル ‘ssfile’ は現在 2 行から成り、 ssfile line 1 という行は 3 月 27 日に mary が

格納しました。そして 3 月 28 日に joe が、 ssfile line 1 という行を修正せずに、 ssfile line 2 という行を格納しました。この報告では、削除されたり修正された行については何も分

らないので、 cvs diff を用いる必要があるでしょう (see Section A.8 [diff], page 83)。

annotate では、以下の標準オプションが利用できます (完全な記述は Section A.4 [Common options], page 73 参照):

-D date date 以前の最も新しいリビジョンに註釈を付けます。

-f フラグ ‘-D date’ か ‘-r tag’ を指定した場合にのみ有効になります。一致するリビジョンが見付からない場合に (そのファイルを無視せずに)、最新リビジョンに註釈を付けます。

-l 再帰的動作を抑制し、現在の作業ディレクトリのみで動作します。 See Chapter 9 [Recursive

behavior], page 49。

-r tag リビジョン tag に註釈を付けます。

Chapter 16: キーワード置換 63

16 キーワード置換

モジュールの作業ファイル中のファイルを編集する間、 ‘cvs status’ や ‘cvs log’ を使ってそのファイルの状態を調べます。しかしファイルの開発が終わると、すぐにリビジョンの識別は困難になります。

rcs は、キーワード置換(keyword substitution) もしくはキーワード展開(keyword expansion) と呼ば

れる機構により、ファイルの識別を補助します。ファイル中に $keyword$, $keyword:…$ といった形式で埋め込まれた文字列を、ファイルを取り出すときに$keyword:value$ といった書式の文字列に置き換えます。

16.1 RCS キーワード

現在の rcs (リリース 5.6.0.1) が実装するキーワードのリストです。

$Author$ そのリビジョンを格納したユーザのログイン名

$Date$ そのリビジョンを格納した日付と時間 (UTC)

$Header$ 標準のヘッダは、 rcs ファイルのフルパス名, リビジョン番号, 日付 (UTC), 最終変更者, ファイル状態, (ロックされているならば) ロックをしているユーザという情報で構成されます。 cvs を使用する場合、通常、ファイルはロックされません。

$Id$ rcs ファイル名がフルパスでないことを除けば、 $Header$ と同じです。

$Name$ このファイルを取り出したときに使用したタグ名です。

$Locker$ そのリビジョンをロックしている人物のログイン名です。 (ロックされていなければ空です。従って cvs を使用する限り、常に無意味です。 )

$Log$ rcs ファイル名, リビジョン番号, 最終変更者, 日付 (UTC) を含むヘッダに続く、格納されたときのログ・メッセージです。以前のログ・メッセージは置き換えられません。その代り、新しいメッセージが$Log:…$ の次の行に挿入されます。各行の先頭には註釈符(comment leader)

が挿入されます。これは cvs admin -c で変更することが可能です (see Section A.5.1 [admin

options], page 75)。このキーワードは、ソース・ファイルに全てのログを残す場合に便利です

が、幾つかの点で問題となることもあります (see Section 16.5 [Log keyword], page 65)。

$RCSfile$

パスを含まない rcs ファイル名です。

$Revision$

そのリビジョンを表わすリビジョン番号です。

$Source$ rcs ファイルのフルパス名です。

$State$ そのリビジョンの状態です。ファイルの状態は、 cvs admin -s で割り当てることができます

(see Section A.5.1 [admin options], page 75)。

16.2 キーワードの使用

キーワード文字列をファイルの中に含めるには、 $Id$ などの文字列を、ファイルの関連する場所に書いて格納します。 cvs は格納操作の一部分として自動的に文字列を展開します。

次例は、 C のソース中に $Id$ を埋め込む典型的な方法です。この例では、置換が行なわれた後の、ファイルの最初の何行かを示します。

     static char *rcsid="$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";

/* The following lines will prevent gcc version 2.x from issuing an "unused variable" warning. */

     #if __GNUC__== 2
     #define USE(var) static void * use_##var = (&use_##var, (void *) &var)
     USE (rcsid);
     #endif

ちょっと賢いコンパイラで最適化すると、使用しない変数 rcsid は削除されてしまいますが、ほとんどのコンパイラで、文字列がバイナリに埋め込まれます。また幾つかのコンパイラでは、バイナリ中に直接文章を埋め込むのに#pragma が使用できます。

ファイルからキーワードとその値を展開するのに、 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 コマンドは、 @(#) という文字列を探すため、両方のコマンドに対応するキーワードを含めるのは簡単です。 rcs のキーワードの前に、簡単な sccs の魔法の呪文を唱えるだけで良いのです。

     static char *id="@(#) $Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";

16.3 置換を止めるには

キーワード置換にも欠点があります。ファイル中に表われる文字列 ‘$Author$’ は、 rcs によってキーワードと見倣されます。この文字列を ‘$Author: ceder $’ などと解釈させずに、そのまま使いたい事があるでしょう。

不幸なことに、選択的にキーワード置換を止めることはできません。 ‘-ko’ によって完全にキーワード置換

を止めることができます (see Section 16.4 [Substitution modes], page 64)。

rcs キーワードが最終製品に現われるとしても、ソース・ファイル中には使いたくない場合が多くあります。例えば、このマニュアルのソースでは ‘$Author$’ を使わずに、 ‘$@asis{}Author$’ を使っています。 nroff や troff であれば、ヌル文字である \& をキーワード中に埋め込めば、同様の効果を発揮します。

16.4 置換モード

各ファイルには既定の置換モードが設定されており、作業ディレクトリの各ファイルの置換モードも別に設定できます。前者は、 cvs add や cvs admin に、オプション ‘-k’ を付けて設定します。後者は、 cvs

Chapter 16: キーワード置換 65

checkout や cvs update に、オプション ‘-k’ や ‘-A’ を付けて設定します。 cvs diff にも ‘-k’ オプションがあります。例が幾つかありますので、 Chapter 17 [Binary files], page 67 参照。

利用できるモードを以下に示します:

‘-kkv’ 既定形式でキーワード文字列を生成する。例えば、キーワード Revision に対して$Revision: 5.7 $ が生成される。

‘-kkvl’ 現在のリビジョンがロックされているならば、常にロックしているユーザ名を表示すること以外は、 ‘-kkv’ と同じである。通常、 cvs でこのオプションは役に立たない。

‘-kk’ キーワード文字列からキーワードのみを生成し、その値は省略される。例えば、キーワード

          Revision に対して、 $Revision: 5.7 $ ではなく、 $Revision$ が生成される。このオプ

ションは、リビジョン間の違いを比較する時、キーワードによる違いを無視するのに便利である。

‘-ko’ そのファイルが格納される前の、古いキーワード文字列を生成する。例えば、キーワード Revision に対して、 $Revision: 5.7 $ ではなく、ファイルが格納された時の文字列である$Revision: 1.1 $ が生成される。

‘-kb’ ‘-ko’ と同様だが、リポジトリに格納される標準的な行末形式 (ラインフィードのみ) を、クライアント側のオペレーティングシステムに適した形式へ変換しない。行端にラインフィードのみが使用されるシステム (unix 等) では、このオプションは ‘-ko’ と同じである。バイナリファイ

ルの詳細情報は Chapter 17 [Binary files], page 67 参照。

‘-kv’ キーワードの値のみを生成する。例えば、キーワード Revision に対して、 $Revision: 5.7 $ ではなく、 5.7 が生成される。これは、 $Revision: $ といった、キーワード識別子を除くのが困難なプログラミング言語のファイルを生成する時に便利である。しかし、キーワード名が削除されてしまうために、これ以後はキーワード置換を行うことができない。従って、注意して使用すべきである。

オプション ‘-kv’ は、 cvs export で使用される事が多い (see Section A.9 [export], page 84)。

しかし、バイナリ・ファイルに含まれるものは処理しない事に注意すべきである。

16.5 キーワード $Log$ の問題点

キーワード $Log$ にはちょっと問題があります。開発システム上で作業をしているならば、キーワード $Log$ を使用しなくても、 cvs log とすることでその情報は簡単に手に入ります。一度 export すれば、履歴情報は必要ありません。

さらに重要な問題は、枝が幹にマージされた場合に、 rcs が $Log$ の見出しをうまく扱えないことです。マージ操作の結果、よく衝突が起きてしまいます。

ファイルの中のログ・メッセージは、修復される傾向にあります。 (綴の間違いやほんとのエラー等)。しかしこれをすると、 cvs log の情報とファイルの中身が一致しないことになります。これも問題といえば問題でしょう。

どうしてもキーワード $Log$ を使うのならば、ファイルの先頭ではなく、ファイルの最後に挿入することを推奨します。この方法ならば、長い変更メッセージを毎日眺めなくて済みます。

66 CVS—Concurrent Versions System (in japanese)

Chapter 17: バイナリ・ファイルの扱い 67

17 バイナリ・ファイルの扱い

cvs でバイナリ・ファイルを保管するには、 2 つの問題点があります。 1 つ目の問題点は、既定状態の cvs が、リポジトリに格納する標準的な行末形式 (ラインフィードのみ) を、クライアント側のオペレーティングシステムに適した形式に変換する事です (例えば Windows NT にはラインフィードにキャリッジリターンが付加される)。

2 つ目の問題点は、キーワードと同じデータが、偶然バイナリ・ファイルに含まれる可能性がある事です (see

Chapter 16 [Keyword substitution], page 63)。そのためキーワード展開を無効にする必要があります。

幾つかの cvs コマンドで ‘-kb’ オプションを用いれば、確実に行末変換とキーワード展開を止めることができます。古いバージョンの rcs を使用していて、このオプションが使えない場合でも、 unix のようにラインフィードのみを行末に用いるオペレーティングシステムを使用しているならば、代りに ‘-ko’ が使えます。他のオペレーティングシステムならば、 rcs を新しいバージョンに入れ替えて下さい。 5.7 以降であれば ‘-kb’ が使えます。

‘-kb’ フラグを用いて新しいファイルを登録する方法を、以下に例示します:

     $ echo '$Id$' > kotest
     $ cvs add -kb -m"A test file" kotest
     $ cvs ci -m"First checkin; contains a keyword" kotest

ふと油断して ‘-kb’ 無しでファイルを加えてしまった場合、 cvs admin コマンドを使用して正常な状態に戻す必要があります。以下に例示します:

     $ echo '$Id$' > kotest
     $ cvs add -m"A test file" kotest
     $ cvs ci -m"First checkin; contains a keyword" kotest
     $ cvs admin -kb kotest
     $ cvs update -A kotest
     $ cvs commit -m "make it binary" kotest  # unix 以外のシステムの場合

ファイル ‘kotest’ を登録した時に、キーワードが展開されます (上記例の全てのコマンドの後で cat kotest を実行してみて下さい)。 cvs admin -kb コマンドは、このファイルに対するキーワード置換の既定方法を設定しますが、既にある作業コピーは変更されません。従って、展開されないバージョンの ‘kotest’ を得るには、 cvs update -A が最も簡単な方法です。行末を適切に処理する必要がある場合 (cvs のクライアントとして unix 以外のシステムを使用している場合)、上記の例に示した cvs commit コマンドのように、新たにファイルのコピーを格納する必要があります。

しかしながら cvs admin -k でキーワード展開を変更する際、キーワード展開モードはバージョン管理されないことを認識しておいて下さい。これは例えば、古いリリースにテキスト・ファイルがあり、新しいリリースに同じ名前のバイナリ・ファイルがあった場合、バージョンによってテキストとバイナリを区別して取り出す方法を、 cvs が備えていないことを意味しています。この問題を解決する方法は今のところありません。

cvs add や cvs import を実行する際、バイナリとして扱うかどうかを、ファイルの名前によって判断するように設定できます。例えば、ファイル名が ‘.exe’ で終わるファイルをバイナリと判断するように設定で

きます。 See Section B.2 [Wrappers], page 100。 68 CVS—Concurrent Versions System (in japanese)

Chapter 18: リビジョン管理 69

18 リビジョン管理

ここまで読んだあなたは、 cvs を使って何ができるかをもう随分理解しているでしょう。ここでは、あなたが決めるべき事柄について少し説明します。

あなたが 1 人で cvs を使用して開発しているならば、ここは読み飛ばして結構です。 1 人よりも多い人物がリポジトリで作業する場合に、ここで説明される質問が重要になってきます。

18.1 いつ格納するか?

あなたのグループは、格納の時期に関して、どのような方針を採るか決定しなくてはなりません。幾つかの方針が可能であり、 cvs での経験を重ねることによって、独自の方法を見付けることができるでしょう。

とにかく早く格納することにして、コンパイルもせずに格納してしまったとします。あなたの同僚が、作業ソースを更新してあなたのバギーなファイルを取り込んだ場合、彼はコンパイルができません。逆にめったに格納しない場合、同僚はあなたがコードに加えた改良の利益を得ることができず、衝突がより多くなるでしょう。

コンパイルできるかどうか確認したファイルだけを格納する方法がよく採られます。あるサイトでは、ファ

イルが検査に合格することを要求します。 ‘commitinfo’ ファイルを使用して (see Section B.4 [commitinfo],

page 102)、このような方針を強制できますが、その前によく考えなくてはなりません。十分過ぎる程管理された開発環境を作ると、厳格になり過ぎて、非生産的になり、ソフトウェアを書くという目的が果たせなくなります。

70 CVS—Concurrent Versions System (in japanese)

Appendix A: CVS のコマンド便覧 71

Appendix A CVS のコマンド便覧

この付録では、 cvs の実施方法と、他所で完全には記述されなかった cvs のサブコマンドを、詳細に説

明します。特定のサブコマンドの探索には ⟨undefined⟩ [Index], page ⟨undefined⟩ 参照。

A.1 CVS コマンド構造の全て

cvs のコマンド形式を示します:

     cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]

cvs cvs プログラムの名前です。

cvs_options

cvs コマンド全体に適用されるオプションです。

cvs_command

cvs コマンドの内の 1 つです。幾つかのコマンドでは別名が使用できます。 ‘cvs_command’ を省略できるのは、次の 2 つの場合だけです。つまり、 ‘cvs -H’ として利用可能なコマンドのリストを得る場合か、 ‘cvs -v’ として cvs 自身のバージョン情報を得る場合です。

command_options

コマンド固有のオプションです。

command_args

コマンドの引数です。

   不幸な事に、 cvs_options と command_options の間で幾つか重複があります。 ‘-l’ は cvs_option

であると同時に、多くのコマンドで command_option としても用いられており、それぞれ違った意味を持っています。しかし、これらの分類についてあまり深刻になり過ぎてもいけません。代わりに文書を見るようにしましょう。

A.2 ~/.cvsrc ファイルの設定

よく使用する command_option が幾つかあり、そのオプションを必ず指定するように設定したいことがあります。例えば (実際に .cvsrc を実装した要因の 1 つである) ‘diff’ の既定出力は大変読みにくく、コンテキスト形式かユニディフ形式の方が理解し易いと思われます。

シェルスクリプトやエイリアスに頼る代わりに、 ‘~/.cvsrc’ ファイルによって、 cvs の cvs_commands に既定のオプションを加えることができます。

‘~/.cvsrc’ の形式は簡単です。実行された cvs_command と同じ名前で始まる行が検索されます。一致した行を発見したら、行の残りの部分をオプションに分割し、コマンド行からのオプションを与える前に、得られたオプションをコマンドの引数として与えます。

コマンドが別名を持つ場合 (checkoutと co等)、コマンド行での指定とは関係無く、公式名がファイルの検索に使用されます。 ‘~/.cvsrc’ の内容が次の様であるとします:

log -N
diff -u
update -P
co -P

‘cvs co foo’ と同様に、 ‘cvs checkout foo’ というコマンドにも、 ‘-P’ が引数として与えられます。

上記の例だと、 ‘cvs diff foobar’ の出力はユニディフ形式になります。 ‘cvs diff -c foobar’ だと通

常通りコンテキスト形式になります。 ‘diff’ には古い形式を使用するためのオプションが無いため、古い形式を使いたい場合には少し面倒になり、 ‘cvs -f diff foobar’ とする必要があります。

コマンド名の部分に cvs と記述すれば、広域オプションを指定することができます (see Section A.3

[Global options], page 72)。例として、 ‘.cvsrc’ 中の以下の行は、

cvs -z6

cvs が圧縮レベル 6 を用いるように指定しています。

A.3 広域オプション

‘cvs_options’ (‘cvs_command’ の左側に与えられる) として利用できるものを以下に示します:

-b bindir rcs プログラムのあるディレクトリを bindir とします。環境変数 $RCSBIN よりも優先します。この値は絶対パス名で指定して下さい。

-T tempdir

一時ファイルが置かれるディレクトリを tempdir に指定します。環境変数 $TMPDIR の設定や、コンパイル時のディレクトリ設定よりも優先されます。この値は絶対パス名で指定して下さい。

-d cvs ṙoot ḋirectory

リポジトリのディレクトリのパス名を cvs root directory とします。環境変数 $CVSROOT より

も優先します。 See Chapter 4 [Repository], page 15。

-e editor リビジョンのログ情報の入力に editor を使用します。環境変数 $CVSEDITOR や $EDITOR よりも優先します。

-f ‘~/.cvsrc’ を読みません。このオプションが最も良く使われるのは、 cvs のオプション設定に直交性がない時です。例えば ‘cvs log’ のオプション ‘-N’ はタグの表示を抑制しますが、これに対して表示を行なうオプションはありません。従って、 ‘~/.cvsrc’ の ‘log’ エントリに ‘-N’ があったとき、タグを表示するには ‘-f’ を使用する他ありません。

-H 指定された ‘cvs_command’ の使用法を表示します (コマンドが実際に実行されることはありません)。コマンド名を指定しない場合には、 ‘cvs -H’ は利用できる全てのコマンドの要約を表示します。

-l ‘cvs_command’ をコマンド履歴に記録しません (しかしコマンドは実行されます)。コマンド履

歴の情報は Section A.10 [history], page 85 参照。

-n ファイルを更新しません。 ‘cvs_command’ を実行しようとしますが、報告のみが行なわれます。既存のファイルを削除, 更新, マージしたり、新しいファイルを作成することはありません。

-Q コマンドの出力が完全に抑止され、重大な問題が発生した場合にのみ出力が行なわれます。

-q 冗長なコマンドの出力が抑止され、再帰的にサブディレクトリを辿る時の報告などは行なわれません。

Appendix A: CVS のコマンド便覧 73

-r 新たな作業ファイルを読み込み専用にします。環境変数 $CVSREAD を設定するのと同じ効果が

あります (see Appendix C [Environment variables], page 109)。監視されていない限り、既定では、作業ファイルは書き込み可能です (see Section 6.6 [Watches], page 34)。

-s variable=value ユーザ変数を設定します (see Section B.10 [Variables], page 106)。

-t プログラムの実行状態をトレースします。 cvs が実行する各ステップの情報を表示します。 ‘-n’ オプションと共に使用し、不慣れなコマンドの潜在的な影響を調べるのに便利です。

-v cvs のバージョンと著作権情報を表示します。

-w 新しい作業ファイルを読み書き可能にします。環境変数 $CVSREAD の設定を無効にします。 $CVSREAD が設定されず、 ‘-r’ オプションも無い場合には、既定では、作成されるファイルは読み書き可能です。

-x クライアントとサーバ間の全ての通信を暗号化します。これは cvs クライアントでだけ意味を持ち、またケルベロス接続を用いる場合にしか実装されません (see Section 4.6.3

[Kerberos authenticated], page 23)。暗号化機能は既定状態では実装されず、特別に ‘--enable-encryption’ を指定して、 cvs を構築する必要があります。

-z gzip-level

圧縮レベルを設定します。 cvs クライアントでだけ意味を持ちます。

A.4 共通のコマンド・オプション

ここでは、幾つかの ‘cvs_command’ の間で使用可能な ‘cvs_options’ について説明します。これらのオプションは、常に ‘cvs_command’ の右側に付けられます。以下に示す全てのオプションは、全てのコマンドで使えるわけではありません。各オプションは、意味をなすコマンドにおいてのみ使用可能です。しかし以下のオプションを持つコマンドがあるならば、そのオプションは他のコマンドのものと同じ動作であると考えて良いでしょう。 (個々のコマンドを説明する節に示されるオプションは、大体において他の cvs コマンドとは異なる意味を持っています。 )

注意: ‘history’ コマンドは例外です。このコマンドは、ここに示す共通オプションと重複する多くのオプションを持っています。

-D date ṡpec

date spec より以前で、かつ最新のリビジョンを使用します。 date spec は、過去の日付を示すものを 1 つだけ指定します。ソース・ファイルの個人用コピーを得るときにこのオプションを用いた場合には、指定した日付が貼り付けられます (sticky)。つまり ‘-D’ オプションを用いて作業ファイルを得た場合には、 cvs は指定した日付を記録し、以後そのディレクトリで行なわれる update には同じ日付が用いられ

ます (貼り付けられたタグ/日付についての詳細は see Section 7.4 [Sticky tags], page 42)。

cvs では、様々な形式で日付を指定できます。 date spec は、特に指定されない限り地方時だと見倣されます。以下に日付の指定例を示します:

                                   1 month ago
                                   2 hours ago
                                   400000 seconds ago
                                   last year
                                   last Monday
                                   yesterday
                                   a fortnight ago
                                   3/31/92 10:00:07 PST

                         January 23, 1987 10:05pm
                         22:00 GMT
‘-D’ オプションは以下のコマンドで利用できます: checkout, diff, export, history, rdiff,

rtag, update. (history はこのオプションを少し異なる方法で使用します。 see Section A.10.1 [history options], page 86). ‘3/31/92’ のように日付を指定した場合、 month/day/year と

解釈されることに注意して下さい。従って ‘1/4/96’ は 1 月 4 日であって、 4 月 1 日ではありません。シェルは空白を引数の区切りにするので、 ‘-D’ の引数を引用符で囲むのを忘れてはいけません。 ‘-D’ オプションを付けたコマンド行は、次の様になるでしょう:

     $ cvs diff -D "1 hour ago" cvs.texinfo

-f 日付やタグ名を指定して cvs コマンドを用いた場合、そのタグ名を持たない (その時には存在しなかった) ファイルは、普通無視されます。タグでも日付でも引っ掛からなかったファイルを復元したい場合に、 ‘-f’ オプションを使用します (そのファイルの最新のリビジョンが取り出されます)。

‘-f’ は以下のコマンドで利用できます: checkout, export, rdiff, rtag, update.

注意: commit にも ‘-f’ オプションがありますが、異なる動作をします。 See Section A.7.1 [commit options], page 81。

-H ヘルプです。そのコマンドで利用できるオプションを表示します。このオプションだけが、全ての cvs コマンドでサポートされます。

-k kflag rcs のキーワード処理の動作を変更します。 kflag の詳細は Chapter 16 [Keyword substitu-

tion], page 63 参照。ソース・ファイルの個人用コピーを得るときにこのオプションを用いた場合には、 kflag が貼り付けられます。つまり、このオプションを checkout か update コマンドに用いた場合、 cvs は選ばれた kflag をそのファイルに結合します。これ以後、同ファイルに対する update コマンドには kflag が使用され続けます。この効果は別の指定を行なうまで止みません。

‘-k’ オプションは以下のコマンドで利用できます: add, checkout, diff, update.

-l Local の頭文字です。再帰的にサブディレクトリを辿らず、カレントディレクトリのみでコマンドを実行します。注意: ‘cvs_command’ の左側に指定する ‘cvs -l’ と混同しないようにして下さい。

以下のコマンドで利用できます: checkout, commit, diff, export, log, remove, rdiff,
rtag, status, tag, update.

-m message

エディタを立ち上げる代りに、ログ情報を message に指定します。

以下のコマンドで利用できます: add, commit, import.

-n checkout/commit/tag コマンド実行時に、どのプログラムも実行しません。各コマンド実

行時のプログラムは、データベース ‘modules’ に記述されます (see Section B.1 [modules],

page 99)。このオプションは、 ‘modules’ の記述を無効にします。注意: ‘cvs_command’ の左側に指定する ‘cvs -n’ と混同しないようにして下さい。

以下のコマンドで利用できます: checkout, commit, export, rtag.

-P checkout や、 update による更新の後、空になったディレクトリを削除 (prune) します。リビジョン管理下のファイルを持たない空のディレクトリは、通常はそのまま残されます。 ‘-P’ を指定すると、このようなディレクトリは、あなたの作業ディレクトリから黙って消されます。このオプションは、リポジトリからディレクトリを消すのではなく、あなたの作業コピーからディレクトリを消すだけです。 checkout と export で、 ‘-r’ または ‘-D’ オプションを付けると、 ‘-P’ オプションも実行されることに注意して下さい。

-p リポジトリから復元したファイルをカレントディレクトリに書く代りに、標準出力に送り (pipe)

ます。以下のコマンドで利用できます: checkout, update.

-W フィルターを掛けるべきファイル名を指定します。このオプションは繰り返し利用することができます。ファイル ‘.cvswrappers’ での指定方法と同じ形式で指定します。利用できるコマン

          ド: import, update.

-r tag 既定の先頭(head) リビジョンの代りに、引数 tag で指定されたリビジョンを使用します。 tag か rtag コマンドで任意に定義されたタグの他に、 2 つの特別なタグ ‘HEAD’ と ‘BASE’ が常に利用できます。 ‘HEAD’ は、リポジトリにある最新のリビジョンを参照します。 ‘BASE’ は、作業コピーの由来となるリビジョンを参照します。タグを指定して checkout や update コマンドを実行し、自分の作業ファイルを作った場合、そのタグは貼り付けられます。 cvs はタグを記録し、これ以後に update コマンドを使用する時に、他のものを指定するまでそのタグを使い続けます (貼り付けられたタグ/日付についての詳

細は see Section 7.4 [Sticky tags], page 42)。指定するタグは、文字列でも数字でも構いません。 See Section 7.1 [Tags], page 39。

コマンド・オプション ‘-r’ と一緒に広域オプション ‘-q’ を指定すると、 rcs の履歴ファイルが指定したタグを含まない場合に、警告出力が抑止されるので便利です。注意: ‘cvs\_command’ の左側に指定する ‘cvs -r’ と混同しないようにして下さい。

          ‘-r’ は以下のコマンドで利用できます: checkout, commit, diff, history, export, rdiff,
          rtag, update.

A.5 admin—Administration front end for rcs

• Requires: repository, working directory.

• Changes: repository.

• Synonym: rcs

This is the cvs interface to assorted administrative rcs facilities, documented in rcs(1). admin simply passes all its options and arguments to the rcs command; it does no filtering or other processing. This command does work recursively, however, so extreme care should be used.

If there is a group whose name matches a compiled in value which defaults to cvsadmin, only members of that group can use cvs admin. To disallow cvs admin for all users, create a group with no users in it.

A.5.1 admin options

Not all valid rcs options are useful together with cvs. Some even makes it impossible to use cvs until you undo the effect!

This description of the available options is based on the ‘rcs(1)’ man page, but modified to suit readers that are more interrested in cvs than rcs.

-Aoldfile Might not work together with cvs. Append the access list of oldfile to the access list of the rcs file.

-alogins Might not work together with cvs. Append the login names appearing in the commaseparated list logins to the access list of the rcs file.

-b[rev] When used with bare rcs, this option sets the default branch to rev; in cvs sticky tags (see Section 7.4 [Sticky tags], page 42) are a better way to decide which branch you want to work on. With cvs, this option can be used to control behavior with respect to the vendor branch.

-cstring Useful with cvs. Sets the comment leader to string. The comment leader is printed before every log message line generated by the keyword $Log$ (see Chapter 16 [Keyword substitution], page 63). This is useful for programming languages without multi-line comments. Rcs initially guesses the value of the comment leader from the file name extension when the file is first committed.

-e[logins] Might not work together with cvs. Erase the login names appearing in the commaseparated list logins from the access list of the RCS file. If logins is omitted, erase the entire access list.

-I Run interactively, even if the standard input is not a terminal.

-i Useless with cvs. When using bare rcs, this is used to create and initialize a new rcs file, without depositing a revision.

-ksubst Useful with cvs. Set the default keyword substitution to subst. See Chapter 16 [Keyword substitution], page 63. Giving an explicit ‘-k’ option to cvs update, cvs export, or cvs checkout overrides this default.

-l[rev] Lock the revision with number rev. If a branch is given, lock the latest revision on that branch. If rev is omitted, lock the latest revision on the default branch. This can be used in conjunction with the ‘rcslock.pl’ script in the ‘contrib’ directory of the cvs source distribution to provide reserved checkouts (where only one user can be editing a given file at a time). See the comments in that file for details (and see the ‘README’ file in that directory for disclaimers about the unsupported nature of contrib). According to comments in that file, locking must set to strict (which is the default).

-L Set locking to strict. Strict locking means that the owner of an RCS file is not exempt from locking for checkin. For use with cvs, strict locking must be set; see the discussion under the ‘-l’ option above.

-mrev:msg Replace the log message of revision rev with msg.

-Nname[:[rev]]

Act like ‘-n’, except override any previous assignment of name.

-nname[:[rev]]

Associate the symbolic name name with the branch or revision rev. It is normally better to use ‘cvs tag’ or ‘cvs rtag’ instead. Delete the symbolic name if both ‘:’ and rev are omitted; otherwise, print an error message if name is already associated with another number. If rev is symbolic, it is expanded before association. A rev consisting of a branch number followed by a ‘.’ stands for the current latest revision in the branch. A ‘:’ with an empty rev stands for the current latest revision on the default branch, normally the trunk. For example, ‘rcs -nname: RCS/*’ associates name with the current latest revision of all the named RCS files; this contrasts with ‘rcs -nname:$ RCS/*’ which associates name with the revision numbers extracted from keyword strings in the corresponding working files.

-orange Potentially useful, but dangerous, with cvs (see below). Deletes (outdates) the revisions given by range. A range consisting of a single revision number means that revision. A range consisting of a branch number means the latest revision on that branch. A range of the form ‘rev1:rev2’ means revisions rev1 to rev2 on the same branch, ‘:rev’ means from the beginning of the branch containing rev up to and including rev, and ‘rev:’ means from revision rev to the end of the branch containing rev. None of the outdated revisions may have branches or locks.

Due to the way cvs handles branches rev cannot be specified symbolically if it is a branch. See Section D.1 [Magic branch numbers], page 111, for an explanation. Make sure that no-one has checked out a copy of the revision you outdate. Strange things will happen if he starts to edit it and tries to check it back in. For this reason, this option is not a good way to take back a bogus commit; commit a new revision undoing the bogus change instead (see Section 8.3 [Merging two revisions], page 46).

-q Run quietly; do not print diagnostics.

-sstate[:rev] Useful with cvs. Set the state attribute of the revision rev to state. If rev is a branch number, assume the latest revision on that branch. If rev is omitted, assume the latest revision on the default branch. Any identifier is acceptable for state. A useful set of states is ‘Exp’ (for experimental), ‘Stab’ (for stable), and ‘Rel’ (for released). By default, the state of a new revision is set to ‘Exp’ when it is created. The state is visible in the output from cvs log (see Section A.12 [log], page 89), and in the ‘$Log$’ and ‘$State$’ keywords (see Chapter 16 [Keyword substitution], page 63). Note that cvs uses the dead state for its own purposes; to take a file to or from the dead state use

commands like cvs remove and cvs add, not cvs admin -s.

-t[file] Useful with cvs. Write descriptive text from the contents of the named file into the RCS file, deleting the existing text. The file pathname may not begin with ‘-’. If file is omitted, obtain the text from standard input, terminated by end-of-file or by a line containing ‘.’ by itself. Prompt for the text if interaction is possible; see ‘-I’. The descriptive text can be seen in the output from ‘cvs log’ (see Section A.12 [log], page 89).

-t-string Similar to ‘-tfile’. Write descriptive text from the string into the rcs file, deleting the existing text.

-U Set locking to non-strict. Non-strict locking means that the owner of a file need not lock a revision for checkin. For use with cvs, strict locking must be set; see the discussion under the ‘-l’ option above.

-u[rev] See the option ‘-l’ above, for a discussion of using this option with cvs. Unlock the revision with number rev. If a branch is given, unlock the latest revision on that branch. If rev is omitted, remove the latest lock held by the caller. Normally, only the locker of a revision may unlock it. Somebody else unlocking a revision breaks the lock. This causes a mail message to be sent to the original locker. The message contains a commentary solicited from the breaker. The commentary is terminated by end-of-file or by a line containing . by itself.

-Vn Emulate rcs version n. Use -Vn to make an rcs file acceptable to rcs version n by discarding information that would confuse version n.

-xsuffixes Useless with cvs. Use suffixes to characterize RCS files.

A.5.2 admin examples

A.5.2.1 Outdating is dangerous

First, an example of how not to use the admin command. It is included to stress the fact that this command can be quite dangerous unless you know exactly what you are doing.

The ‘-o’ option can be used to outdate old revisions from the history file. If you are short on disc this option might help you. But think twice before using it—there is no way short of restoring the latest backup to undo this command!

The next line is an example of a command that you would not like to execute.

     $ cvs admin -o:R_1_02 .

The above command will delete all revisions up to, and including, the revision that corresponds to the tag R 1 02. But beware! If there are files that have not changed between R 1 02 and R 1 03 the file will have the same numerical revision number assigned to the tags R 1 02 and R 1 03. So not only will it be impossible to retrieve R 1 02; R 1 03 will also have to be restored from the tapes!

A.5.2.2 Comment leaders

If you use the $Log$ keyword and you do not agree with the guess for comment leader that cvs has done, you can enforce your will with cvs admin -c. This might be suitable for nroff source:

     $ cvs admin -c'.\" ' *.man
     $ rm *.man
     $ cvs update

The two last steps are to make sure that you get the versions with correct comment leaders in your working files.

A.6 checkout—Check out sources for editing

• Synopsis: checkout [options] modules…

• Requires: repository.

• Changes: working directory.

• Synonyms: co, get

Make a working directory containing copies of the source files specified by modules. You must execute checkout before using most of the other cvs commands, since most of them operate on your working directory.

The modules part of the command are either symbolic names for some collection of source directories and files, or paths to directories or files in the repository. The symbolic names are defined in the ‘modules’ file. See Section B.1 [modules], page 99.

Depending on the modules you specify, checkout may recursively create directories and populate them with the appropriate source files. You can then edit these source files at any time (regardless of whether other software developers are editing their own copies of the sources); update them to include new changes applied by others to the source repository; or commit your work as a permanent change to the source repository.

Note that checkout is used to create directories. The top-level directory created is always added to the directory where checkout is invoked, and usually has the same name as the specified module. In the case of a module alias, the created sub-directory may have a different name, but you can be sure that it will be a sub-directory, and that checkout will show the relative path leading to each file as it is extracted into your private work area (unless you specify the ‘-Q’ global option).

The files created by checkout are created read-write, unless the ‘-r’ option to cvs (see Section A.3 [Global options], page 72) is specified, the CVSREAD environment variable is specified (see Appendix C [Environment variables], page 109), or a watch is in effect for that file (see Section 6.6 [Watches], page 34).

Running checkout on a directory that was already built by a prior checkout is also permitted, and has the same effect as specifying the ‘-d’ option to the update command, that is, any new directories that have been created in the repository will appear in your work area. See Section A.18 [update], page 96.

For the output produced by the checkout command see Section A.18.2 [update output], page 97.

A.6.1 checkout options

These standard options are supported by checkout (see Section A.4 [Common options], page 73, for a complete description of them):

-D date Use the most recent revision no later than date. This option is sticky, and implies ‘-P’. See Section 7.4 [Sticky tags], page 42, for more information on sticky tags/dates.

-f Only useful with the ‘-D date’ or ‘-r tag’ flags. If no matching revision is found, retrieve the most recent revision (instead of ignoring the file).

-k kflag Process rcs keywords according to kflag. See co(1). This option is sticky; future updates of this file in this working directory will use the same kflag. The status command can be viewed to see the sticky options. See Section A.16 [status], page 94.

-l Local; run only in current working directory.

-n Do not run any checkout program (as specified with the ‘-o’ option in the modules file; see Section B.1 [modules], page 99).

-P Prune empty directories.

-p Pipe files to the standard output.

-r tag Use revision tag. This option is sticky, and implies ‘-P’. See Section 7.4 [Sticky tags], page 42, for more information on sticky tags/dates.

In addition to those, you can use these special command options with checkout:

-A Reset any sticky tags, dates, or ‘-k’ options. See Section 7.4 [Sticky tags], page 42, for more information on sticky tags/dates.

-c Copy the module file, sorted, to the standard output, instead of creating or modifying any files or directories in your working directory.

-d dir Create a directory called dir for the working files, instead of using the module name. Unless you also use ‘-N’, the paths created under dir will be as short as possible.

-j tag With two ‘-j’ options, merge changes from the revision specified with the first ‘-j’ option to the revision specified with the second ‘j’ option, into the working directory. With one ‘-j’ option, merge changes from the ancestor revision to the revision specified with the ‘-j’ option, into the working directory. The ancestor revision is the common ancestor of the revision which the working directory is based on, and the revision specified in the ‘-j’ option. In addition, each -j option can contain an optional date specification which, when used with branches, can limit the chosen revision to one within a specific date. An optional date is specified by adding a colon (:) to the tag: ‘-jSymbolic Tag:Date Specifier’. See Chapter 8 [Merging], page 45.

-N Only useful together with ‘-d dir’. With this option, cvs will not shorten module paths in your working directory. (Normally, cvs shortens paths as much as possible when you specify an explicit target directory).

-s Like ‘-c’, but include the status of all modules, and sort it by the status string. See Section B.1 [modules], page 99, for info about the ‘-s’ option that is used inside the modules file to set the module status.

A.6.2 checkout examples

Get a copy of the module ‘tc’:

$ cvs checkout tc

Get a copy of the module ‘tc’ as it looked one day ago:

$ cvs checkout -D yesterday tc

A.7 commit—Check files into the repository

• Version 1.3 Synopsis: commit [-lnR] [-m ’log message’ | -f file] [-r revision] [files…]

• Version 1.3.1 Synopsis: commit [-lnRf] [-m ’log message’ | -F file] [-r revision] [files…]

• Requires: working directory, repository.

• Changes: repository.

• Synonym: ci

Warning: The ‘-f file’ option will probably be renamed to ‘-F file’, and ‘-f’ will be given a new behavior in future releases of cvs.

Use commit when you want to incorporate changes from your working source files into the source repository.

If you don’t specify particular files to commit, all of the files in your working current directory are examined. commit is careful to change in the repository only those files that you have really changed. By default (or if you explicitly specify the ‘-R’ option), files in subdirectories are also examined and committed if they have changed; you can use the ‘-l’ option to limit commit to the current directory only.

commit verifies that the selected files are up to date with the current revisions in the source repository; it will notify you, and exit without committing, if any of the specified files must be made current first with update (see Section A.18 [update], page 96). commit does not call the update command for you, but rather leaves that for you to do when the time is right.

When all is well, an editor is invoked to allow you to enter a log message that will be written to one or more logging programs (see Section B.1 [modules], page 99, and see Section B.6 [loginfo], page 104) and placed in the rcs history file inside the repository. This log message can be retrieved with the log command; See Section A.12 [log], page 89. You can specify the log message on the command line with the ‘-m message’ option, and thus avoid the editor invocation, or use the ‘-f file’ option to specify that the argument file contains the log message.

A.7.1 commit options

These standard options are supported by commit (see Section A.4 [Common options], page 73, for a complete description of them):

-l Local; run only in current working directory.

-n Do not run any module program.

-R Commit directories recursively. This is on by default.

-r revision Commit to revision. revision must be either a branch, or a revision on the main trunk that is higher than any existing revision number. You cannot commit to a specific revision on a branch.

commit also supports these options:

-F file This option is present in cvs releases 1.3-s3 and later. Read the log message from file, instead of invoking an editor.

-f This option is present in cvs 1.3-s3 and later releases of cvs. Note that this is not the standard behavior of the ‘-f’ option as defined in See Section A.4 [Common options], page 73. Force cvs to commit a new revision even if you haven’t made any changes to the file. If the current revision of file is 1.7, then the following two commands are equivalent:

               $ cvs commit -f file
               $ cvs commit -r 1.8 file

-f file This option is present in cvs releases 1.3, 1.3-s1 and 1.3-s2. Note that this is not the standard behavior of the ‘-f’ option as defined in See Section A.4 [Common options], page 73. Read the log message from file, instead of invoking an editor.

-m message Use message as the log message, instead of invoking an editor.

A.7.2 commit examples

A.7.2.1 New major release number

When you make a major release of your product, you might want the revision numbers to track your major release number. You should normally not care about the revision numbers, but this is a thing that many people want to do, and it can be done without doing any harm.

To bring all your files up to the rcs revision 3.0 (including those that haven’t changed), you might do:

     $ cvs commit -r 3.0

Note that it is generally a bad idea to try to make the rcs revision number equal to the current release number of your product. You should think of the revision number as an internal number that the cvs package maintains, and that you generally never need to care much about. Using the tag and rtag commands you can give symbolic names to the releases instead. See Section A.17 [tag], page 95 and See Section A.15 [rtag], page 93.

Note that the number you specify with ‘-r’ must be larger than any existing revision number. That is, if revision 3.0 exists, you cannot ‘cvs commit -r 1.3’.

A.7.2.2 Committing to a branch

You can commit to a branch revision (one that has an even number of dots) with the ‘-r’ option. To create a branch revision, use the ‘-b’ option of the rtag or tag commands (see Section A.17 [tag], page 95 or see Section A.15 [rtag], page 93). Then, either checkout or update can be used to base your sources on the newly created branch. From that point on, all commit changes made within these working sources will be automatically added to a branch revision, thereby not disturbing main-line development in any way. For example, if you had to create a patch to the 1.2 version of the product, even though the 2.0 version is already under development, you might do:

     $ cvs rtag -b -r FCS1_2 FCS1_2_Patch product_module
     $ cvs checkout -r FCS1_2_Patch product_module
     $ cd product_module
     [[ hack away ]]
     $ cvs commit

This works automatically since the ‘-r’ option is sticky.

A.7.2.3 Creating the branch after editing

Say you have been working on some extremely experimental software, based on whatever revision you happened to checkout last week. If others in your group would like to work on this software with you, but without disturbing main-line development, you could commit your change to a new branch. Others can then checkout your experimental stuff and utilize the full benefit of cvs conflict resolution. The scenario might look like:

     [[ hacked sources are present ]]
     $ cvs tag -b EXPR1
     $ cvs update -r EXPR1
     $ cvs commit

The update command will make the ‘-r EXPR1’ option sticky on all files. Note that your changes to the files will never be removed by the update command. The commit will automatically commit to the correct branch, because the ‘-r’ is sticky. You could also do like this:

     [[ hacked sources are present ]]
     $ cvs tag -b EXPR1
     $ cvs commit -r EXPR1

but then, only those files that were changed by you will have the ‘-r EXPR1’ sticky flag. If you hack away, and commit without specifying the ‘-r EXPR1’ flag, some files may accidentally end up on the main trunk.

To work with you on the experimental change, others would simply do

     $ cvs checkout -r EXPR1 whatever_module

A.8 diff—Run diffs between revisions

• Synopsis: diff [-l] [rcsdiff options] [[-r rev1 | -D date1] [-r rev2 | -D date2]] [files…]

• Requires: working directory, repository.

• Changes: nothing.

The diff command is used to compare different revisions of files. The default action is to compare your working files with the revisions they were based on, and report any differences that are found.

If any file names are given, only those files are compared. If any directories are given, all files under them will be compared.

The exit status will be 0 if no differences were found, 1 if some differences were found, and 2 if any error occurred.

A.8.1 diff options

These standard options are supported by diff (see Section A.4 [Common options], page 73, for a complete description of them):

-D date Use the most recent revision no later than date. See ‘-r’ for how this affects the comparison. cvs can be configured to pass the ‘-D’ option through to rcsdiff (which in turn passes it on to diff. Gnu diff uses ‘-D’ as a way to put cpp-style ‘#define’ statements around the output differences. There is no way short of testing to figure out how cvs was configured. In the default configuration cvs will use the ‘-D date’ option.

-k kflag Process rcs keywords according to kflag. See co(1).

-l Local; run only in current working directory.

-R Examine directories recursively. This option is on by default.

-r tag Compare with revision tag. Zero, one or two ‘-r’ options can be present. With no ‘-r’ option, the working file will be compared with the revision it was based on. With one ‘-r’, that revision will be compared to your current working file. With two ‘-r’ options those two revisions will be compared (and your working file will not affect the outcome in any way). One or both ‘-r’ options can be replaced by a ‘-D date’ option, described above.

Any other options that are found are passed through to rcsdiff, which in turn passes them to diff. The exact meaning of the options depends on which diff you are using. The long options introduced in gnu diff 2.0 are not yet supported in cvs. See the documentation for your diff to see which options are supported.

A.8.2 diff examples

The following line produces a Unidiff (‘-u’ flag) between revision 1.14 and 1.19 of ‘backend.c’. Due to the ‘-kk’ flag no keywords are substituted, so differences that only depend on keyword substitution are ignored.

     $ cvs diff -kk -u -r 1.14 -r 1.19 backend.c

Suppose the experimental branch EXPR1 was based on a set of files tagged RELEASE 1 0. To see what has happened on that branch, the following can be used:

     $ cvs diff -r RELEASE_1_0 -r EXPR1

A command like this can be used to produce a context diff between two releases:

     $ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs

If you are maintaining ChangeLogs, a command like the following just before you commit your changes may help you write the ChangeLog entry. All local modifications that have not yet been committed will be printed.

     $ cvs diff -u | less

A.9 export—Export sources from CVS, similar to checkout

• Synopsis: export [-flNn] [-r rev|-D date] [-k subst] [-d dir] module…

• Requires: repository.

• Changes: current directory.

This command is a variant of checkout; use it when you want a copy of the source for module without the cvs administrative directories. For example, you might use export to prepare source for shipment off-site. This command requires that you specify a date or tag (with ‘-D’ or ‘-r’), so that you can count on reproducing the source you ship to others.

One often would like to use ‘-kv’ with cvs export. This causes any rcs keywords to be expanded such that an import done at some other site will not lose the keyword revision information. But be aware that doesn’t handle an export containing binary files correctly. Also be aware that after having used ‘-kv’, one can no longer use the ident command (which is part of the rcs suite—see ident(1)) which looks for rcs keyword strings. If you want to be able to use ident you must not use ‘-kv’.

A.9.1 export options

These standard options are supported by export (see Section A.4 [Common options], page 73, for a complete description of them):

-D date Use the most recent revision no later than date.

-f If no matching revision is found, retrieve the most recent revision (instead of ignoring the file).

-l Local; run only in current working directory.

-n Do not run any checkout program.

-R Export directories recursively. This is on by default.

-r tag Use revision tag.

In addition, these options (that are common to checkout and export) are also supported:

-d dir Create a directory called dir for the working files, instead of using the module name. Unless you also use ‘-N’, the paths created under dir will be as short as possible.

-k subst Set keyword expansion mode (see Section 16.4 [Substitution modes], page 64).

-N Only useful together with ‘-d dir’. With this option, cvs will not shorten module paths in your working directory. (Normally, cvs shortens paths as much as possible when you specify an explicit target directory.)

A.10 history—Show status of files and users

• Synopsis: history [-report] [-flags] [-options args] [files…]

  • Requires: the file ‘$CVSROOT/CVSROOT/history’

• Changes: nothing.

cvs can keep a history file that tracks each use of the checkout, commit, rtag, update, and release commands. You can use history to display this information in various formats.

Logging must be enabled by creating the file ‘$CVSROOT/CVSROOT/history’.

Warning: history uses ‘-f’, ‘-l’, ‘-n’, and ‘-p’ in ways that conflict with the normal use inside cvs (see Section A.4 [Common options], page 73).

A.10.1 history options

Several options (shown above as ‘-report’) control what kind of report is generated:

-c Report on each time commit was used (i.e., each time the repository was modified). -e Everything (all record types); equivalent to specifying ‘-xMACFROGWUT’. -m module

Report on a particular module. (You can meaningfully use ‘-m’ more than once on the command line.)

-o Report on checked-out modules. -T Report on all tags. -x type Extract a particular set of record types type from the cvs history. The types are

indicated by single letters, which you may specify in combination. Certain commands have a single record type: F release O checkout T rtag One of four record types may result from an update: C A merge was necessary but collisions were detected (requiring manual merg-

ing).

G A merge was necessary and it succeeded. U A working file was copied from the repository. W The working copy of a file was deleted during update (because it was gone

from the repository).

One of three record types results from commit: A A file was added for the first time. M A file was modified. R A file was removed.

The options shown as ‘-flags’ constrain or expand the report without requiring option arguments:

-a Show data for all users (the default is to show data only for the user executing history). -l Show last modification only. -w Show only the records for modifications done from the same working directory where

history is executing.

The options shown as ‘-options args’ constrain the report based on an argument:

-b str Show data back to a record containing the string str in either the module name, the file name, or the repository path.

-D date Show data since date. This is slightly different from the normal use of ‘-D date’, which selects the newest revision older than date.

-p repository Show data for a particular source repository (you can specify several ‘-p’ options on the same command line).

-r rev Show records referring to revisions since the revision or tag named rev appears in individual rcs files. Each rcs file is searched for the revision or tag.

-t tag Show records since tag tag was last added to the the history file. This differs from the ‘-r’ flag above in that it reads only the history file, not the rcs files, and is much faster.

-u name Show records for user name.

A.11 import—Import sources into CVS, using vendor branches

• Synopsis: import [-options] repository vendortag releasetag…

• Requires: Repository, source distribution directory.

• Changes: repository.

Use import to incorporate an entire source distribution from an outside source (e.g., a source vendor) into your source repository directory. You can use this command both for initial creation of a repository, and for wholesale updates to the module from the outside source. See Chapter 12 [Tracking sources], page 55, for a discussion on this subject.

The repository argument gives a directory name (or a path to a directory) under the cvs root directory for repositories; if the directory did not exist, import creates it.

When you use import for updates to source that has been modified in your source repository (since a prior import), it will notify you of any files that conflict in the two branches of development; use ‘checkout -j’ to reconcile the differences, as import instructs you to do.

If cvs decides a file should be ignored (see Section B.8 [cvsignore], page 105), it does not import it and prints ‘I ’ followed by the filename (see Section A.11.2 [import output], page 88, for a complete description of the output).

If the file ‘$CVSROOT/CVSROOT/cvswrappers’ exists, any file whose names match the specifications in that file will be treated as packages and the appropriate filtering will be performed on the file/directory before being imported, See Section B.2 [Wrappers], page 100.

The outside source is saved in a first-level rcs branch, by default 1.1.1. Updates are leaves of this branch; for example, files from the first imported collection of source will be revision 1.1.1.1, then files from the first imported update will be revision 1.1.1.2, and so on.

At least three arguments are required. repository is needed to identify the collection of source. vendortag is a tag for the entire branch (e.g., for 1.1.1). You must also specify at least one releasetag to identify the files at the leaves created each time you execute import.

A.11.1 import options

This standard option is supported by import (see Section A.4 [Common options], page 73, for a complete description):

-m message Use message as log information, instead of invoking an editor.

There are three additional special options.

-b branch Specify a first-level branch other than 1.1.1. Unless the ‘-b branch’ flag is given, revisions will always be made to the branch 1.1.1—even if a vendortag that matches another branch is given! What happens in that case, is that the tag will be reset to 1.1.1. Warning: This behavior might change in the future.

-k subst Indicate the RCS keyword expansion mode desired. This setting will apply to all files created during the import, but not to any files that previously existed in the repository. See Section 16.4 [Substitution modes], page 64 for a list of valid ‘-k’ settings.

-I name Specify file names that should be ignored during import. You can use this option repeatedly. To avoid ignoring any files at all (even those ignored by default), specify ‘-I !’. name can be a file name pattern of the same type that you can specify in the ‘.cvsignore’ file. See Section B.8 [cvsignore], page 105.

-W spec Specify file names that should be filtered during import. You can use this option repeatedly. spec can be a file name pattern of the same type that you can specify in the ‘.cvswrappers’ file. See Section B.2 [Wrappers], page 100.

A.11.2 import output

import keeps you informed of its progress by printing a line for each file, preceded by one character indicating the status of the file:

U file The file already exists in the repository and has not been locally modified; a new revision has been created (if necessary).

N file The file is a new file which has been added to the repository.

C file The file already exists in the repository but has been locally modified; you will have to merge the changes.

I file The file is being ignored (see Section B.8 [cvsignore], page 105).

L file The file is a symbolic link; at the moment (and for the forseeable future), symbolic links are ignored. (Various options in the ‘modules’ file can be used to recreate symbolic links on checkout, update, etc.; see Section B.1 [modules], page 99.)

A.11.3 import examples

See Chapter 12 [Tracking sources], page 55, and See Section 5.1.1 [From files], page 25.

A.12 log—Print out log information for files

• Synopsis: log [options] [files…]

• Requires: repository, working directory.

• Changes: nothing.

Display log information for files. log used to call the rcs utility rlog. Although this is no longer true in the current sources, this history determines the format of the output and the options, which are not quite in the style of the other cvs commands.

The output includes the location of the rcs file, the head revision (the latest revision on the trunk), all symbolic names (tags) and some other things. For each revision, the revision number, the author, the number of lines added/deleted and the log message are printed. All times are displayed in Coordinated Universal Time (UTC). (Other parts of cvs print times in the local timezone).

A.12.1 log options

By default, log prints all information that is available. All other options restrict the output.

-b Print information about the revisions on the default branch, normally the highest branch on the trunk.

-d dates Print information about revisions with a checkin date/time in the range given by the semicolon-separated list of dates. The date formats accepted are those accepted by the ‘-D’ option to many other cvs commands (see Section A.4 [Common options], page 73). Dates can be combined into ranges as follows: d1<d2 d2>d1 Select the revisions that were deposited between d1 and d2.

<d

d> Select all revisions dated d or earlier.

d<

>d Select all revisions dated d or later. d Select the single, latest revision dated d or earlier. The ‘>’ or ‘<’ characters may be followed by ‘=’ to indicate an inclusive range rather than an exclusive one. Note that the separator is a semicolon (;).

-h Print only the rcs pathname, working pathname, head, default branch, access list, locks, symbolic names, and suffix.

-l Local; run only in current working directory. (Default is to run recursively). -N Do not print the list of tags for this file. This option can be very useful when your site

uses a lot of tags, so rather than "more"’ing over 3 pages of tag information, the log information is presented without tags at all.

-R Print only the name of the rcs history file.

-rrevisions Print information about revisions given in the comma-separated list revisions of revisions and ranges. The following table explains the available range formats:

rev1:rev2 Revisions rev1 to rev2 (which must be on the same branch).

:rev Revisions from the beginning of the branch up to and including rev.

rev: Revisions starting with rev to the end of the branch containing rev.

branch An argument that is a branch means all revisions on that branch.

branch1:branch2 A range of branches means all revisions on the branches in that range.

branch. The latest revision in branch.

A bare ‘-r’ with no revisions means the latest revision on the default branch, normally the trunk. There can be no space between the ‘-r’ option and its argument.

-s states Print information about revisions whose state attributes match one of the states given in the comma-separated list states.

-t Print the same as ‘-h’, plus the descriptive text.

-wlogins Print information about revisions checked in by users with login names appearing in the comma-separated list logins. If logins is omitted, the user’s login is assumed. There can be no space between the ‘-w’ option and its argument.

log prints the intersection of the revisions selected with the options ‘-d’, ‘-s’, and ‘-w’, intersected with the union of the revisions selected by ‘-b’ and ‘-r’.

A.12.2 log examples

Contributed examples are gratefully accepted.

A.13 rdiff—’patch’ format diffs between releases

• rdiff [-flags] [-V vn] [-r t|-D d [-r t2|-D d2]] modules…

• Requires: repository.

• Changes: nothing.

• Synonym: patch

Builds a Larry Wall format patch(1) file between two releases, that can be fed directly into the patch program to bring an old release up-to-date with the new release. (This is one of the few cvs commands that operates directly from the repository, and doesn’t require a prior checkout.) The diff output is sent to the standard output device.

You can specify (using the standard ‘-r’ and ‘-D’ options) any combination of one or two revisions or dates. If only one revision or date is specified, the patch file reflects differences between that revision or date and the current head revisions in the rcs file.

Note that if the software release affected is contained in more than one directory, then it may be necessary to specify the ‘-p’ option to the patch command when patching the old sources, so that patch is able to find the files that are located in other directories.

A.13.1 rdiff options

These standard options are supported by rdiff (see Section A.4 [Common options], page 73, for a complete description of them):

-D date Use the most recent revision no later than date.

-f If no matching revision is found, retrieve the most recent revision (instead of ignoring the file).

-l Local; don’t descend subdirectories.

-r tag Use revision tag.

In addition to the above, these options are available:

-c Use the context diff format. This is the default format.

-s Create a summary change report instead of a patch. The summary includes information about files that were changed or added between the releases. It is sent to the standard output device. This is useful for finding out, for example, which files have changed between two dates or revisions.

-t A diff of the top two revisions is sent to the standard output device. This is most useful for seeing what the last change to a file was.

-u Use the unidiff format for the context diffs. This option is not available if your diff does not support the unidiff format. Remember that old versions of the patch program can’t handle the unidiff format, so if you plan to post this patch to the net you should probably not use ‘-u’.

-V vn Expand rcs keywords according to the rules current in rcs version vn (the expansion format changed with rcs version 5).

A.13.2 rdiff examples

Suppose you receive mail from foo@bar.com asking for an update from release 1.2 to 1.4 of the tc compiler. You have no such patches on hand, but with cvs that can easily be fixed with a command such as this:

     $ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \
     $$ Mail -s 'The patches you asked for' foo@bar.com

Suppose you have made release 1.3, and forked a branch called ‘R_1_3fix’ for bugfixes. ‘R_1_3_1’ corresponds to release 1.3.1, which was made some time ago. Now, you want to see how much development has been done on the branch. This command can be used:

     $ cvs patch -s -r R_1_3_1 -r R_1_3fix module-name

     cvs rdiff: Diffing module-name
     File ChangeLog,v changed from revision 1.52.2.5 to 1.52.2.6
     File foo.c,v changed from revision 1.52.2.3 to 1.52.2.4
     File bar.h,v changed from revision 1.29.2.1 to 1.2

A.14 release—Indicate that a Module is no longer in use

• release [-d] directories…

• Requires: Working directory.

• Changes: Working directory, history log.

This command is meant to safely cancel the effect of ‘cvs checkout’. Since cvs doesn’t lock files, it isn’t strictly necessary to use this command. You can always simply delete your working directory, if you like; but you risk losing changes you may have forgotten, and you leave no trace in the cvs history file (see Section B.9 [history file], page 106) that you’ve abandoned your checkout.

Use ‘cvs release’ to avoid these problems. This command checks that no uncommitted changes are present; that you are executing it from immediately above a cvs working directory; and that the repository recorded for your files is the same as the repository defined in the module database.

If all these conditions are true, ‘cvs release’ leaves a record of its execution (attesting to your intentionally abandoning your checkout) in the cvs history log.

A.14.1 release options

The release command supports one command option:

-d Delete your working copy of the file if the release succeeds. If this flag is not given your files will remain in your working directory. Warning: The release command deletes all directories and files recursively. This has the very serious side-effect that any directory that you have created inside your checked-out sources, and not added to the repository (using the add command; see Chapter 10 [Adding files], page 51) will be silently deleted—even if it is non-empty!

A.14.2 release output

Before release releases your sources it will print a one-line message for any file that is not up-to-date.

Warning: Any new directories that you have created, but not added to the cvs directory hierarchy with the add command (see Chapter 10 [Adding files], page 51) will be silently ignored (and deleted, if ‘-d’ is specified), even if they contain files.

U file There exists a newer revision of this file in the repository, and you have not modified your local copy of the file.

A file The file has been added to your private copy of the sources, but has not yet been committed to the repository. If you delete your copy of the sources this file will be lost.

R file The file has been removed from your private copy of the sources, but has not yet been removed from the repository, since you have not yet committed the removal. See Section A.7 [commit], page 80.

M file The file is modified in your working directory. There might also be a newer revision inside the repository.

? file file is in your working directory, but does not correspond to anything in the source repository, and is not in the list of files for cvs to ignore (see the description of the ‘-I’ option, and see Section B.8 [cvsignore], page 105). If you remove your working sources, this file will be lost. Note that no warning message like this is printed for spurious directories that cvs encounters. The directory, and all its contents, are silently ignored.

A.14.3 release examples

Release the module, and delete your local working copy of the files.

$ cd .. # You must stand immediately above the

# sources when you issue ‘cvs release’.

     $ cvs release -d tc
     You have [0] altered files in this repository.
     Are you sure you want to release (and delete) module `tc': y
     $

A.15 rtag—Add a symbolic tag to a module

• rtag [-falnR] [-b] [-d] [-r tag | -Ddate] symbolic tag modules…

• Requires: repository.

• Changes: repository.

• Synonym: rfreeze

You can use this command to assign symbolic tags to particular, explicitly specified source revisions in the repository. rtag works directly on the repository contents (and requires no prior checkout). Use tag instead (see Section A.17 [tag], page 95), to base the selection of revisions on the contents of your working directory.

If you attempt to use a tag name that already exists, cvs will complain and not overwrite that tag. Use the ‘-F’ option to force the new tag value.

A.15.1 rtag options

These standard options are supported by rtag (see Section A.4 [Common options], page 73, for a complete description of them):

-D date Tag the most recent revision no later than date.

-f Only useful with the ‘-D date’ or ‘-r tag’ flags. If no matching revision is found, use the most recent revision (instead of ignoring the file).

-F Overwrite an existing tag of the same name on a different revision. This option is new in cvs 1.4. The old behavior is matched by ‘cvs tag -F’.

-l Local; run only in current working directory.

-n Do not run any tag program that was specified with the ‘-t’ flag inside the ‘modules’ file. (see Section B.1 [modules], page 99).

-R Commit directories recursively. This is on by default.

-r tag Only tag those files that contain tag. This can be used to rename a tag: tag only the files identified by the old tag, then delete the old tag, leaving the new tag on exactly the same files as the old tag.

In addition to the above common options, these options are available:

-a Use the ‘-a’ option to have rtag look in the ‘Attic’ (see Chapter 11 [Removing files], page 53) for removed files that contain the specified tag. The tag is removed from these files, which makes it convenient to re-use a symbolic tag as development continues (and files get removed from the up-coming distribution).

-b Make the tag a branch tag. See Chapter 7 [Branches], page 39.

-d Delete the tag instead of creating it.

In general, tags (often the symbolic names of software distributions) should not be removed, but the ‘-d’ option is available as a means to remove completely obsolete symbolic names if necessary (as might be the case for an Alpha release, or if you mistagged a module).

A.16 status—Display status information on checked out files

• status [-lR] [-v] [files…]

• Requires: working directory, repository.

• Changes: nothing.

Display a brief report on the current status of files with respect to the source repository. For information on the basic output see Section 6.1 [File status], page 29. For information on the Sticky tag and Sticky date output, see Section 7.4 [Sticky tags], page 42. For information on the Sticky options output, see the ‘-k’ option in Section A.18.1 [update options], page 96.

You can also use this command to determine the potential impact of a ‘cvs update’ on your working source directory—but remember that things might change in the repository before you run

update.

A.16.1 status options

These standard options are supported by status (see Section A.4 [Common options], page 73, for a complete description of them):

-l Local; run only in current working directory.

-R Commit directories recursively. This is on by default.

There is one additional option:

-v Verbose. In addition to the information normally displayed, print all symbolic tags, together with the numerical value of the revision or branch they refer to. For more information, see Section 7.1 [Tags], page 39

A.17 tag—Add a symbolic tag to checked out versions of files

• tag [-lR] [-b] [-c] [-d] symbolic tag [files…]

• Requires: working directory, repository.

• Changes: repository.

• Synonym: freeze

Use this command to assign symbolic tags to the nearest repository versions to your working sources. The tags are applied immediately to the repository, as with rtag, but the versions are supplied implicitly by the cvs records of your working files’ history rather than applied explicitly.

One use for tags is to record a snapshot of the current sources when the software freeze date of a project arrives. As bugs are fixed after the freeze date, only those changed sources that are to be part of the release need be re-tagged.

The symbolic tags are meant to permanently record which revisions of which files were used in creating a software distribution. The checkout and update commands allow you to extract an exact copy of a tagged release at any time in the future, regardless of whether files have been changed, added, or removed since the release was tagged.

This command can also be used to delete a symbolic tag, or to create a branch. See the options section below.

If you attempt to use a tag name that already exists, cvs will complain and not overwrite that tag. Use the ‘-F’ option to force the new tag value.

A.17.1 tag options

These standard options are supported by tag (see Section A.4 [Common options], page 73, for a complete description of them):

-F Overwrite an existing tag of the same name on a different revision. This option is new in cvs 1.4. The old behavior is matched by ‘cvs tag -F’.

-l Local; run only in current working directory.

-R Commit directories recursively. This is on by default.

Two special options are available:

-b The -b option makes the tag a branch tag (see Chapter 7 [Branches], page 39), allowing concurrent, isolated development. This is most useful for creating a patch to a previously released software distribution.

-c The -c option checks that all files which are to be tagged are unmodified. This can be used to make sure that you can reconstruct the current file contents.

-d Delete a tag.

If you use ‘cvs tag -d symbolic_tag’, the symbolic tag you specify is deleted instead of being added. Warning: Be very certain of your ground before you delete a tag; doing this permanently discards some historical information, which may later turn out to be valuable.

A.18 update—Bring work tree in sync with repository

• update [-AdflPpR] [-d] [-r tag|-D date] files…

• Requires: repository, working directory.

• Changes: working directory.

After you’ve run checkout to create your private copy of source from the common repository, other developers will continue changing the central source. From time to time, when it is convenient in your development process, you can use the update command from within your working directory to reconcile your work with any revisions applied to the source repository since your last checkout or update.

A.18.1 update options

These standard options are available with update (see Section A.4 [Common options], page 73, for a complete description of them):

-D date Use the most recent revision no later than date. This option is sticky, and implies ‘-P’. See Section 7.4 [Sticky tags], page 42, for more information on sticky tags/dates.

-f Only useful with the ‘-D date’ or ‘-r tag’ flags. If no matching revision is found, retrieve the most recent revision (instead of ignoring the file).

-k kflag Process rcs keywords according to kflag. See co(1). This option is sticky; future updates of this file in this working directory will use the same kflag. The status command can be viewed to see the sticky options. See Section A.16 [status], page 94.

-l Local; run only in current working directory. See Chapter 9 [Recursive behavior], page 49.

-P Prune empty directories.

-p Pipe files to the standard output.

-R Operate recursively. This is on by default. See Chapter 9 [Recursive behavior], page 49.

-r tag Retrieve revision tag. This option is sticky, and implies ‘-P’. See Section 7.4 [Sticky tags], page 42, for more information on sticky tags/dates.

These special options are also available with update.

-A Reset any sticky tags, dates, or ‘-k’ options. See Section 7.4 [Sticky tags], page 42, for more information on sticky tags/dates.

-d Create any directories that exist in the repository if they’re missing from the working directory. Normally, update acts only on directories and files that were already enrolled in your working directory. This is useful for updating directories that were created in the repository since the initial checkout; but it has an unfortunate side effect. If you deliberately avoided certain directories in the repository when you created your working directory (either through use of a module name or by listing explicitly the files and directories you wanted on the command line), then updating with ‘-d’ will create those directories, which may not be what you want.

-I name Ignore files whose names match name (in your working directory) during the update. You can specify ‘-I’ more than once on the command line to specify several files to ignore. Use ‘-I !’ to avoid ignoring any files at all. See Section B.8 [cvsignore], page 105, for other ways to make cvs ignore some files.

-Wspec Specify file names that should be filtered during update. You can use this option repeatedly. spec can be a file name pattern of the same type that you can specify in the ‘.cvswrappers’ file. See Section B.2 [Wrappers], page 100.

-jrevision With two ‘-j’ options, merge changes from the revision specified with the first ‘-j’ option to the revision specified with the second ‘j’ option, into the working directory. With one ‘-j’ option, merge changes from the ancestor revision to the revision specified with the ‘-j’ option, into the working directory. The ancestor revision is the common ancestor of the revision which the working directory is based on, and the revision specified in the ‘-j’ option. In addition, each -j option can contain an optional date specification which, when used with branches, can limit the chosen revision to one within a specific date. An optional date is specified by adding a colon (:) to the tag: ‘-jSymbolic Tag:Date Specifier’. See Chapter 8 [Merging], page 45.

A.18.2 update output

update and checkout keep you informed of its progress by printing a line for each file, preceded by one character indicating the status of the file:

U file The file was brought up to date with respect to the repository. This is done for any file that exists in the repository but not in your source, and for files that you haven’t changed but are not the most recent versions available in the repository.

A file The file has been added to your private copy of the sources, and will be added to the source repository when you run commit on the file. This is a reminder to you that the file needs to be committed.

R file The file has been removed from your private copy of the sources, and will be removed from the source repository when you run commit on the file. This is a reminder to you that the file needs to be committed.

M file The file is modified in your working directory.

‘M’ can indicate one of two states for a file you’re working on: either there were no modifications to the same file in the repository, so that your file remains as you last saw it; or there were modifications in the repository as well as in your copy, but they were merged successfully, without conflict, in your working directory. cvs will print some messages if it merges your work, and a backup copy of your working file (as it looked before you ran update) will be made. The exact name of that file is printed while update runs.

C file A conflict was detected while trying to merge your changes to file with changes from the source repository. file (the copy in your working directory) is now the output of the rcsmerge(1) command on the two revisions; an unmodified copy of your file is also in your working directory, with the name ‘.#file.revision’ where revision is the rcs revision that your modified file started from. Resolve the conflict as described in Section 6.3 [Conflicts example], page 30 (Note that some systems automatically purge files that begin with ‘.#’ if they have not been accessed for a few days. If you intend to keep a copy of your original file, it is a very good idea to rename it.) Under vms, the file name starts with ‘__’ rather than ‘.#’.

? file file is in your working directory, but does not correspond to anything in the source repository, and is not in the list of files for cvs to ignore (see the description of the ‘-I’ option, and see Section B.8 [cvsignore], page 105). Note that no warning message like this is printed for spurious directories that cvs encounters. The directory, and all its contents, are silently ignored.

A.18.3 update examples

The following line will display all files which are not up-to-date without actually change anything in your working directory. It can be used to check what has been going on with the project.

$ cvs -n -q update

Appendix B: 管理用ファイル便覧 99

Appendix B 管理用ファイル便覧

リポジトリ中のディレクトリ ‘$CVSROOT/CVSROOT’ に、 cvs を支援する多くのファイルが置かれます。これらのファイル無しでも、 cvs を限定された方法で使うことが可能です。しかし適正に設定することで、物事を

容易にすることが可能です。これらの編集方法の説明は、 Section 4.3 [Intro administrative files], page 18

参照。

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

B.1 管理用ファイル modules

管理用ファイル ‘modules’ は、ソース・コードの集合体の名前の定義を記録します。 cvs を用いてファイル ‘modules’ を更新すれば、 cvs はその定義を使用するようになります (add, commit などの普通のコマンドを使用して下さい)。

ファイル ‘modules’ は、モジュールの定義以外にも、空白行や註釈行 (‘#’ で始まる行) を含むことができます。バックスラッシュ (‘\’) を行の最後に記述すれば、長い行を次の行にまで続けることができます。

モジュールの定義は、ファイル ‘modules’ の単一行から成り、 2 つの書式で記述されます。どちらの場合でも mname はモジュール名を表わし、行の残りの部分にはその定義が記述されます。

mname -a aliases…

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

mname [ options ] dir [ files…] [ &module…]

この形式のモジュール定義を最も単純にすると、 ‘mname dir’ となります。これはディレクトリ dir の全てのファイルを、モジュール mname と定義します。 dir は、 ($CVSROOT から) ソースのあるディレクトリへの相対パス名です。この場合にソースを取り出すと、 mname というディレクトリのみが作業ディレクトリに作成されます。つまり dir が複数のディレクトリ階層からなるパス名であっても、既定では途中のディレクトリ階層は使用されません。モジュール定義の dir の後にファイル名を明示することで、ディレクトリ dir から特定のファイルを選択することができます。上に挙げた ‘modules’ の定義は、あるディレクトリの単一ファイルをモジュールとして定義した例になっています。ここでは別の例を挙げます:

     m4test  unsupported/gnu/m4 foreach.m4 forloop.m4

これを定義して、 ‘cvs checkout m4test’ を実行すれば、まず作業ディレクトリ ‘m4test’ が

作成されます。そして cvs のリポジトリ中の、数階層の深さにある共通のディレクトリから、指定された 2 つのファイルが含められます。モジュールの定義に ‘&module’ を含めれば、他のモジュールを参照することができます。 checkout すると、それぞれのモジュールごとのサブディレクトリが、作業ディレクトリに作成されます。

-d name 作業ディレクトリに、モジュール名とは違う名前を付ける。

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

する。 prog は、リポジトリ中の当該ディレクトリのフルパス名を引数として実行

されます。 ‘commitinfo’, ‘loginfo’, ‘editinfo’ を利用すれば、他の方法で格

納時にプログラムを呼出すことができます。

-o prog モジュール中のファイルを取り出したとき、常に実行されるプログラム prog を指定する。 prog は、モジュール名を引数として実行されます。

-s status モジュールに状態を割り当てる。 ‘cvs checkout -s’ でモジュールのファイルを表示するとき、モジュールはまず状態により並べられ、次にモジュール名により並べられます。このオプションは他に何の意味もありません。このオプションを、状態ではない色々な用途に利用することもできます。例えば各モジュールの責任者一覧などです。

-t prog rtag によってモジュール中のファイルにタグが付けられたとき、常に実行されるプログラム prog を指定する。 prog は、モジュール名と rtag で指定されたタグ名の、 2 つの引数をとります。 tag が用いられるときに、実行されるプログラムを指定する方法はありません。

-u prog 取り出し済みのモジュールの最上層のディレクトリで ‘cvs update’ が用いられたとき、常に実行されるプログラム prog を指定する。 prog は、このモジュールのリポジトリへのフルパス名を引数として実行されます。

B.2 The cvswrappers file

Wrappers allow you to set a hook which transforms files on their way in and out of cvs. Most or all of the wrappers features do not work with client/server cvs.

The file ‘cvswrappers’ defines the script that will be run on a file when its name matches a regular expresion. There are two scripts that can be run on a file or directory. One script is executed on the file/directory before being checked into the repository (this is denoted with the -t flag) and the other when the file is checked out of the repository (this is denoted with the -f flag)

The ‘cvswrappers’ also has a ‘-m’ option to specify the merge methodology that should be used when the file is updated. MERGE means the usual cvs behavior: try to merge the files (this generally will not work for binary files). COPY means that cvs update will merely copy one version over the other, and require the user using mechanisms outside cvs, to insert any necessary changes. The ‘-m’ wrapper option only affects behavior when merging is done on update; it does not affect how files are stored. See See Chapter 17 [Binary files], page 67, for more on binary files.

The basic format of the file ‘cvswrappers’ is:

     wildcard     [option value][option value]...
     where option is one of
     -f           from cvs filter         value: path to filter
     -t           to cvs filter           value: path to filter
     -m           update methodology      value: MERGE or COPY
     -k           keyword expansion       value: expansion mode
     and value is a single-quote delimited value.
     *.nib    -f 'unwrap %s' -t 'wrap %s %s' -m 'COPY'

     *.c      -t 'indent %s %s'

The above example of a ‘cvswrappers’ file states that all files/directories that end with a .nib should be filtered with the ‘wrap’ program before checking the file into the repository. The file should be filtered though the ‘unwrap’ program when the file is checked out of the repository. The ‘cvswrappers’ file also states that a COPY methodology should be used when updating the files in the repository (that is no merging should be performed).

The last example line says that all files that end with a *.c should be filtered with ‘indent’ before being checked into the repository. Unlike the previous example no filtering of the *.c file is done when it is checked out of the repository. The -t filter is called with two arguments, the first is the name of the file/directory to filter and the second is the pathname to where the resulting filtered file should be placed.

The -f filter is called with one argument, which is the name of the file to filter from. The end result of this filter will be a file in the users directory that they can work on as they normally would.

For another example, the following command imports a directory, treating files whose name ends in ‘.exe’ as binary:

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

B.3 commit 支援ファイル

ファイル ‘modules’ 中の ‘-i’ フラグは、ファイルが格納された時に、指定されたプログラムを実行する

のに用いられます (see Section B.1 [modules], page 99)。この節で説明されるファイルは、ファイルの格納

時にプログラムを実行するための、より柔軟な方法をを提供します。

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

‘commitinfo’

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

‘editinfo’

ここに記述されるプログラムは、ログ出力を編集するのに用いられ、全ての要求される項目が含まれるかどうか可能な限り確かめます。ログ出力の書式を記述する ‘rcsinfo’ ファイルと組み

合せるることで、より便利になります (see Section B.7 [rcsinfo], page 105)。

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

B.3.1 共通の構文

‘commitinfo’, ‘loginfo’, ‘rcsinfo’, ‘editinfo’ の 4 つのファイルは、共通の書式を持ちます。各ファ

イルの目的は後述します。ここでは共通の構文について説明します。

各行は次の要素を含みます:

• 正規表現

• 項目間の空白—1 つ以上のスペース又はタブ

• ファイル名又はコマンド行の形式

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

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

B.4 Commitinfo

The ‘commitinfo’ file defines programs to execute whenever ‘cvs commit’ is about to execute. These programs are used for pre-commit checking to verify that the modified, added and removed files are really ready to be committed. This could be used, for instance, to verify that the changed files conform to to your site’s standards for coding practice.

As mentioned earlier, each line in the ‘commitinfo’ file consists of a regular expression and a command-line template. The template can include a program name and any number of arguments you wish to supply to it. The full path to the current source repository is appended to the template, followed by the file names of any files involved in the commit (added, removed, and modified files).

The first line with a regular expression matching the relative path to the module will be used. If the command returns a non-zero exit status the commit will be aborted.

If the repository name does not match any of the regular expressions in this file, the ‘DEFAULT’ line is used, if it is specified.

All occurances of the name ‘ALL’ appearing as a regular expression are used in addition to the first matching regular expression or the name ‘DEFAULT’.

Note: when CVS is accessing a remote repository, ‘commitinfo’ will be run on the remote (i.e., server) side, not the client side (see Section 4.6 [Remote repositories], page 19).

B.5 Editinfo

If you want to make sure that all log messages look the same way, you can use the ‘editinfo’ file to specify a program that is used to edit the log message. This program could be a custom-made editor that always enforces a certain style of the log message, or maybe a simple shell script that calls an editor, and checks that the entered message contains the required fields.

If no matching line is found in the ‘editinfo’ file, the editor specified in the environment variable $CVSEDITOR is used instead. If that variable is not set, then the environment variable $EDITOR is used instead. If that variable is not set a precompiled default, normally vi, will be used.

The ‘editinfo’ file is often most useful together with the ‘rcsinfo’ file, which can be used to specify a log message template.

Each line in the ‘editinfo’ file consists of a regular expression and a command-line template. The template must include a program name, and can include any number of arguments. The full path to the current log message template file is appended to the template.

One thing that should be noted is that the ‘ALL’ keyword is not supported. If more than one matching line is found, the first one is used. This can be useful for specifying a default edit script in a module, and then overriding it in a subdirectory.

If the repository name does not match any of the regular expressions in this file, the ‘DEFAULT’ line is used, if it is specified.

If the edit script exits with a non-zero exit status, the commit is aborted.

Note: when CVS is accessing a remote repository, or when the ‘-m’ or ‘-F’ options to cvs commit are used, ‘editinfo’ will not be consulted. There is no good workaround for this.

B.5.1 Editinfo example

The following is a little silly example of a ‘editinfo’ file, together with the corresponding ‘rcsinfo’ file, the log message template and an editor script. We begin with the log message template. We want to always record a bug-id number on the first line of the log message. The rest of log message is free text. The following template is found in the file ‘/usr/cvssupport/tc.template’.

BugId:

The script ‘/usr/cvssupport/bugid.edit’ is used to edit the log message.

#!/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

The ‘editinfo’ file contains this line:

^tc     /usr/cvssupport/bugid.edit

The ‘rcsinfo’ file contains this line:

^tc     /usr/cvssupport/tc.template

B.6 ファイル loginfo

‘loginfo’ を用いて、 ‘cvs commit’ によるログ情報の送り先を管理します。各行の第 1 項目には、正規表現 (regular expression) が記述され、行の残りの部分はフィルターでなくてはなりません。変更を加えたディレクトリを$CVSROOT からの相対パスで表わしたものと、各行の正規表現が合致するかどうか試されます。合致した場合は、その行の残りの部分であるフィルター・プログラムの標準入力に、ログ情報を与えます。

フィルター・プログラムは、修飾子 ‘%’ を (printf 風に) 1 つだけ使用できます。 ‘%s’ がフィルター・プログラム内で記述された場合には、修正されたファイルを示す簡潔な表題 (を単引用符で囲んだもの) に展開されます。

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

第 1 項目が ‘ALL’ である行の記述は、最初に合致した正規表現や ‘DEFAULT’ に加えて、全ての場合に適用されます。

最初に合致した正規表現を持つ行が実行されます。

ファイル ‘loginfo’ の構文についての記述は Section B.3 [commit files], page 101 参照。

注意: CVS が別のマシンのリポジトリを利用している場合、 ‘loginfo’ はクライアント側ではなく、別

のマシン(サーバ) 側で実行されます (see Section 4.6 [Remote repositories], page 19)。

B.6.1 loginfo 記述例

ここで示す ‘loginfo’ ファイルと付属のシェル・スクリプトは、格納時に次のような動作をします。まず全

てのログ出力を、 ‘$CVSROOT/CVSROOT/commitlog’ に追記します。次に全ての管理用ファイル (‘CVSROOT’
内) の格納時のログを、 ‘/usr/adm/cvsroot-log’ に追記します。
ALL             /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog
^CVSROOT        /usr/local/bin/cvs-log /usr/adm/cvsroot-log
シェル・スクリプト ‘/usr/local/bin/cvs-log’ の内容:
#!/bin/sh
(echo "-----------------------------------------------------------------";
 echo -n $USER"  ";
 date;
 echo;
 sed '1s+'${CVSROOT}'++') >> $1

B.6.2 取得済のコピーを最新に保つ

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

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

     ^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’ を更新します。

B.7 Rcsinfo

The ‘rcsinfo’ file can be used to specify a form to edit when filling out the commit log. The ‘rcsinfo’ file has a syntax similar to the ‘editinfo’, ‘commitinfo’ and ‘loginfo’ files. See Section B.3.1 [syntax], page 101. Unlike the other files the second part is not a command-line template. Instead, the part after the regular expression should be a full pathname to a file containing the log message template.

If the repository name does not match any of the regular expressions in this file, the ‘DEFAULT’ line is used, if it is specified.

All occurances of the name ‘ALL’ appearing as a regular expression are used in addition to the first matching regular expression or ‘DEFAULT’.

The log message template will be used as a default log message. If you specify a log message with ‘cvs commit -m message’ or ‘cvs commit -f file’ that log message will override the template.

See Section B.5.1 [editinfo example], page 103, for an example ‘rcsinfo’ file.

When CVS is accessing a remote repository, the contents of ‘rcsinfo’ at the time a directory is first checked out will specify a template which does not then change. If you edit ‘rcsinfo’ or its templates, you may need to check out a new working directory.

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

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

Section A.18.2 [update output], page 97)。

cvs は、 update, import, release の実行時に無視すべきファイルのリストを (sh(1) のファイル名形

式で) 保持します。このリストは、以下の方法で構築されます。 • リストは以下のファイル名形式で初期化される: これらは、 cvs の管理に関するものの他、他のソース

管理システムと共通のもの、一般的なパッチ・ファイル名、オブジェクト・ファイル、書庫ファイル、エディタのバックアップ・ファイル、他のユーティリティの通常の生成ファイル名等から構成される。現在、既定で無視されるファイル名形式のリストを以下に挙げる:

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

• リポジトリ毎のリスト ‘$CVSROOT/CVSROOT/cvsignore’ が存在すれば、その内容がリストに付加される。

• 使用者毎のリスト ‘.cvsignore’ があなたのホーム・ディレクトリに存在すれば、その内容がリストに付加される。

• 環境変数 $CVSIGNORE の全ての内容がリストに付加される。

• ‘-I’ オプションによって cvs に与えられた内容が、リストに付加される。

• あなたのディレクトリを一通り見て ‘.cvsignore’ があれば、その内容をリストに付加する。 ‘.cvsignore’ 内の形式は、それが含まれるディレクトリのみで有効であり、サブディレクトリに対しては効果を持たない。

上記 5 つのファイル内に単感嘆符 (‘!’) があれば、無視するファイルのリストを空にします。これは、通常は cvs に無視されるファイルを、リポジトリに格納したい場合に使用されます。

B.9 ファイル history

ファイル ‘$CVSROOT/CVSROOT/history’ は、 history コマンドのために、ログ情報を記録します (see

Section A.10 [history], page 85)。ログを記録したい場合には、このファイルを作成する必要があります。ス

クリプト cvsinit でリポジトリを準備した場合には、自動的に作成されます (see Section 4.5 [Creating a repository], page 19)。

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

B.10 Expansions in administrative files

Sometimes in writing an administrative file, you might want the file to be able to know various things based on environment cvs is running in. There are several mechanisms to do that.

To find the home directory of the user running cvs (from the HOME environment variable), use ‘~’ followed by ‘/’ or the end of the line. Likewise for the home directory of user, use ‘~user’. These variables are expanded on the server machine, and don’t get any resonable expansion if pserver (see Section 4.6.2 [Password authenticated], page 20) is in used; therefore user variables (see below) may be a better choice to customize behavior based on the user running cvs.

One may want to know about various pieces of information internal to cvs. A cvs internal variable has the syntax ${variable}, where variable starts with a letter and consists of alphanumberic characters and ‘_’. If the character following variable is a non-alphanumeric character other than ‘_’, the ‘{’ and ‘}’ can be omitted. The cvs internal variables are:

CVSROOT This is the value of the cvs root in use. See Chapter 4 [Repository], page 15, for a description of the various ways to specify this.

RCSBIN This is the value cvs is using for where to find rcs binaries. See Section A.3 [Global options], page 72, for a description of how to specify this.

CVSEDITOR
VISUAL

EDITOR These all expand to the same value, which is the editor that cvs is using. See Section A.3 [Global options], page 72, for how to specify this.

USER Username of the user running cvs (on the cvs server machine).

If you want to pass a value to the administrative files which the user that is running cvs can specify, use a user variable. To expand a user variable, the administrative file contains ${=variable}. To set a user variable, specify the global option ‘-s’ to cvs, with argument variable=value. It may be particularly useful to specify this option via ‘.cvsrc’ (see Section A.2 [~/.cvsrc], page 71).

For example, if you want the administrative file to refer to a test directory you might create a user variable TESTDIR. Then if cvs is invoked as cvs -s TESTDIR=/work/local/tests, and the administrative file contains sh ${=TESTDIR}/runtests, then that string is expanded to sh

/work/local/tests/runtests.

All other strings containing ‘$’ are reserved; there is no way to quote a ‘$’ character so that ‘$’ represents itself.

108 CVS—Concurrent Versions System (in japanese)

Appendix C: CVS に影響する全ての環境変数 109

Appendix C CVS に影響する全ての環境変数

これは、 cvs に影響する全ての環境変数の完全なリストです。

$CVSIGNORE

cvs が無視するファイル名を、空白で区切ったリストです。 See Section B.8 [cvsignore], page 105。

$CVSWRAPPERS

cvs が包装して扱うファイル名形式を、空白で区切ったリストです。 See Section B.2 [Wrappers],

page 100。

$CVSREAD この変数が設定されていると、 checkout と update により作成される作業コピーが、強制的に読み込み専用となります。設定しなければ、作業ファイルの修正許可が与えられます。

$CVSROOT (rcs の履歴ファイルが置かれる) cvs のリポジトリのルート・ディレクトリを、絶対パスで指定しなければいけません。 cvs の大部分のコマンドを実行するときに、この情報が利用されます。 $CVSROOT が設定されていない場合や、他のものを優先させたい場合には、コマンド行で ‘cvs -d cvsroot cvs_command…’ としてリポジトリを指定することができます。一旦作業ディレクトリを取り出した後は、 cvs が適切なリポジトリを (‘CVS/Root’ に) 記録します。従って、最初に作業ディレクトリを取り出す時を除いて、通常はこの値に注意する必要はありません。

$EDITOR
$CVSEDITOR

格納時にログ情報を記録する際に、使用するプログラムを指定します。設定しなければ、

‘/usr/ucb/vi’ が使用されます。 $CVSEDITOR は $EDITOR よりも優先されます。 $CVSEDITOR

は cvs 1.3 には存在しませんが、次のリリースには含まれるでしょう。

$PATH $RCSBIN が設定されておらず、 cvs にパス名が埋め込まれていない場合、使用する全てのプログラムを捜す時に $PATH が使用されます。

$RCSBIN cvs が、 rcs のバイナリを捜す時に使用されます。指定方法の説明は、 Section A.3 [Global options], page 72 参照。これが設定されていない場合、コンパイル時に指定された値か、 $PATH を用いて捜します。

$HOME
$HOMEPATH

これを使用して、 ‘.cvsrc’ が置かれたディレクトリを捜します。 (Windows-NT では $HOMEPATH を使用します)。 See Section A.2 [~/.cvsrc], page 71。

$CVS_RSH 利用方式に :ext: が指定された時、 cvs が接続に使用する外部プログラムを指定します。 See

Section 4.6.1 [Connecting via rsh], page 19。

$CVS_SERVER

rsh を用いたクライアント/サーバ・モードで、別マシンのリポジトリを利用する時に使用されます。 rsh を用いて別マシンのリポジトリを利用する時に、サーバ側で起動するプログラムの名

前を指定します。既定値は cvs です。 See Section 4.6.1 [Connecting via rsh], page 19。

$CVS_PASSFILE

クライアント/サーバ・モードで、 cvs login server が実行された時に使用されます。既定値は

‘$HOME/.cvspass’ です。 See Section 4.6.2.2 [Password authentication client], page 21。

$CVS_PASSWORD

クライアント/サーバ・モードで、 cvs login server が実行された時に使用されます。 See

Section 4.6.2.2 [Password authentication client], page 21。

$CVS_CLIENT_PORT

ケルベロスを用いたクライアント/サーバ・モードで使用されます。 See Section 4.6.3 [Kerberos

authenticated], page 23。

$CVS_RCMD_PORT

クライアント/サーバ・モードで使用されます。これを設定した場合、サーバの rcmd デーモンを利用する時に、ここで指定したポート番号が使用されます。 (現在 Unix クライアントでは使用されません)。

$CVS_CLIENT_LOG

クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。これを設定した場合、サーバに送られた全てが ‘$CVS_CLIENT_LOG.in’ に記録され、サーバから送られた

全てが ‘$CVS_CLIENT_LOG.out’ に記録されます。
$CVS_SERVER_SLEEP

クライアント/サーバ・モードの不具合を探して修正するためだけに使用されます。これを設定して、子プロセスを起動する前に指定した秒数を待ち、デバッガを応答させます。

$CVS_IGNORE_REMOTE_ROOT

(この変数の目的は何?)

$COMSPEC OS/2 だけで使用されます。コマンド解釈プログラムを指定します。既定値は cmd.exe です。

$TMPDIR
$TMP

$TEMP 一時ファイルが置かれるディレクトリを指定します。 cvs の内、 rcs を用いて実装されている部分で、上記の順に変数が調べられ、最初に発見された値が使用されます。全てが設定されていなかった場合、一般的には ‘/tmp’ ですが、マシン依存の既定値が使用されます。 cvs サーバは

TMPDIR を使用します。この指定方法は、 Section A.3 [Global options], page 72 参照。 cvs

には、 (システムが提供する tmpnam 関数経由で) 常に ‘/tmp’ を使用する部分があります。 Windows NT では (システムが提供する _tempnam 関数経由で)、 TMP が使用されます。 cvs のクライアントが用いる patch プログラムは、 TMPDIR を使用します。設定されていない

場合、 (少なくとも GNU patch 2.1 は) ‘/tmp’ を使用します。

特定の操作をする際に、 cvs は rcs を呼び出します。以下の環境変数は rcs で用いられるものです。 cvs のクライアント/サーバを用いる場合、これらの変数は、 (接続方法により不可能な場合もあるでしょうが) サーバ側で設定する必要があることに注意して下さい。しかし、全てを設定する必要はないでしょう。

$LOGNAME

$USER 設定すれば、あなたが誰であるかを rcs に伝えます。あなたのアカウント名と、例えば $LOGNAME が違っていた場合は、ファイルを格納する時に異常が現われることがあります。

$RCSINIT 引数の先頭に指定するオプションを、空白で区切ったリストです。オプション内の空白を空白として用いる場合、バックスラッシュを使用して下さい。 $RCSINIT で指定したオプションは、 rcs コマンドの引数の先頭で指定されたものと解釈されます。

Appendix D: トラブルシューティング 111

Appendix D トラブルシューティング

D.1 魔法の枝番号

表面的には、枝番号はドットで分けられた奇数個の整数です (see Section 2.1 [Revision numbers],

page 9)。しかし、これは真実の姿ではありません。 cvs は能率のために、余分な 0 を右から 2 番目の位

置に挿入することがあります (1.2.3 は 1.2.0.3 となり、 8.9.10.11.12 は 8.9.10.11.0.12 になります)。

この魔法の枝(magic branch) と呼ばれるものを、 cvs はうまく隠しています。しかし、完璧に隠し切れていないところも数ヶ所あります。

• 魔法の枝番号が cvs log の出力に現われてしまう。

• cvs admin で枝のタグ名が指定できない。

admin コマンドを使用して、 rcs が枝のタグ名を理解できるように再設定する方法があります。 R4patches というタグ名が、ファイル ‘number.c’ の枝 1.4.2 に付けられている場合 (魔法の枝番号は 1.4.0.2 です)、次のようにします:

     $ cvs admin -NR4patches:1.4.2 numbers.c

この方法を用いる場合は、 1 つ以上のリビジョンが、枝に格納されている必要があります。タグに間違った番号を設定しないように、注意しなくてはいけません。 (実行以前にタグがどう設定されていたか調べる方法はありません)。

112 CVS—Concurrent Versions System (in japanese)

Appendix E: GNU GENERAL PUBLIC LICENSE 113

Appendix E GNU GENERAL PUBLIC LICENSE

114 CVS—Concurrent Versions System (in japanese)

索引 115

索引

(Index is nonexistent)

116 CVS—Concurrent Versions System (in japanese)

Short Contents

このマニュアルについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 CVS とは? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 基本概念. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3 実行例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4 リポジトリ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5 CVS でプロジェクトを始める . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6 複数の開発者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

7 枝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

8 マージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 9 再帰的動作. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 10 ディレクトリにファイルを加える . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 11 モジュールからファイルを削除する. . . . . . . . . . . . . . . . . . . . . . . . . . . 53 12 サード・パーティーのソースの追っかけ . . . . . . . . . . . . . . . . . . . . . . . . 55 13 ファイルの改名と移動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 14 ディレクトリの改名と移動. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 15 履歴の閲覧. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 16 キーワード置換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 17 バイナリ・ファイルの扱い. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 18 リビジョン管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Appendix A CVS のコマンド便覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 Appendix B 管理用ファイル便覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Appendix C CVS に影響する全ての環境変数. . . . . . . . . . . . . . . . . . . . . 109 Appendix D トラブルシューティング . . . . . . . . . . . . . . . . . . . . . . . . . 111

Appendix E GNU GENERAL PUBLIC LICENSE . . . . . . . . . . . . . . 113 索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

ii CVS—Concurrent Versions System (in japanese)

Table of Contents

このマニュアルについて . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 短気な方の為の一覧表 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 バグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 日本語訳について. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1 CVS とは? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

CVS は … ではない. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 基本概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 リビジョン番号. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.2 バージョン、リビジョン、リリース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 実行例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 ソースの取得 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 変更の格納 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3 お掃除 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4 差分を見る . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4 リポジトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1 CVS にリポジトリの場所を教える . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2 リポジトリでのデータの保存方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2.1 リポジトリのどこにファイルを保存するか . . . . . . . . . . . . . . . . . . 16 4.2.2 ファイル使用許可 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3 管理用ファイルの紹介 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.3.1 管理用ファイルの編集 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4 複数のリポジトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5 リポジトリの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.6 別マシンのリポジトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.6.1 rsh で接続する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.6.2 パスワード認証による直接接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.6.2.1 パスワード認証のためのサーバ側の設定 . . . . . . . . . . . 20 4.6.2.2 パスワード認証によるクライアントの使用 . . . . . . . . . 21 4.6.2.3 パスワード認証における安全性の考察 . . . . . . . . . . . . . 22

4.6.3 ケルベロスによる直接接続 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5 CVS でプロジェクトを始める . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.1 ファイルの準備. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.1.1 存在するファイルからディレクトリを生成する . . . . . . . . . . . . . . 25 5.1.2 他のバージョン管理システムからファイルを作成する . . . . . . . . 26 5.1.3 ゼロからディレクトリを作る . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.2 モジュールの定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iv CVS—Concurrent Versions System (in japanese)

6 複数の開発者. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1 ファイル状態 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2 ファイルを最新にする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.3 衝突の例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.4 格納したことを他の人に知らせる . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.5 同時に CVS の実行を試みる複数の開発者 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.6 ファイル編集者の追跡機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.6.1 監視するファイルを CVS に教える . . . . . . . . . . . . . . . . . . . . . . . 34 6.6.2 誰に通知するか CVS に教える . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.6.3 監視下にあるファイルの編集方法 . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.6.4 誰が監視や編集をしているか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.6.5 古いバージョンの CVS と監視機能 . . . . . . . . . . . . . . . . . . . . . . . 37

6.7 独占取得と無条件取得の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

7 枝 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1 タグ–文字によるリビジョン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2 枝が何の役に立つのか . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.3 枝を作る . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.4 貼り付けられたタグ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

8 マージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

8.1 枝全体をマージする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.2 枝から何度もマージする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 8.3 二つのリビジョン間の差分をマージする . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.4 ファイルの追加や削除もマージできる . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

9 再帰的動作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

10 ディレクトリにファイルを加える . . . . . . . . . . . . . . . . . . . . . . . . . . 51

11 モジュールからファイルを削除する . . . . . . . . . . . . . . . . . . . . . . . . . 53

12 サード・パーティーのソースの追っかけ . . . . . . . . . . . . . . . . . . . . . . 55 12.1 まずモジュールを持ち込む . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 12.2 import コマンドでモジュールを更新する . . . . . . . . . . . . . . . . . . . . . . . . . . 55

12.3 cvs import 時のバイナリ・ファイルの扱い . . . . . . . . . . . . . . . . . . . . . . . . 56

13 ファイルの改名と移動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.1 通常の改名方法. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.2 履歴ファイルを移動する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 13.3 履歴ファイルをコピーする . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

14 ディレクトリの改名と移動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

15 履歴の閲覧 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 15.1 ログ・メッセージ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 15.2 履歴データベース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 15.3 ログ方法を使用者自身が設定する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

15.4 コマンド annotate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

16 キーワード置換 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

16.1 RCS キーワード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

16.2 キーワードの使用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 16.3 置換を止めるには . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

16.4 置換モード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 16.5 キーワード $Log$ の問題点 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

17 バイナリ・ファイルの扱い . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

18 リビジョン管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

18.1 いつ格納するか?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Appendix A CVS のコマンド便覧 . . . . . . . . . . . . . . . . . . . . . . 71

A.1 CVS コマンド構造の全て . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.2 ~/.cvsrc ファイルの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.3 広域オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 A.4 共通のコマンド・オプション . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

A.5 admin—Administration front end for rcs . . . . . . . . . . . . . . . . . . . . . . . 75 A.5.1 admin options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 A.5.2 admin examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

A.5.2.1 Outdating is dangerous . . . . . . . . . . . . . . . . . . . . . . 77 A.5.2.2 Comment leaders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

A.6 checkout—Check out sources for editing . . . . . . . . . . . . . . . . . . . . . . . . 78 A.6.1 checkout options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 A.6.2 checkout examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

A.7 commit—Check files into the repository . . . . . . . . . . . . . . . . . . . . . . . . 80 A.7.1 commit options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 A.7.2 commit examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

A.7.2.1 New major release number . . . . . . . . . . . . . . . . . . . 82 A.7.2.2 Committing to a branch . . . . . . . . . . . . . . . . . . . . . 82 A.7.2.3 Creating the branch after editing . . . . . . . . . . . . . 82

A.8 diff—Run diffs between revisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.8.1 diff options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 A.8.2 diff examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

A.9 export—Export sources from CVS, similar to checkout . . . . . . . . . . 84

A.9.1 export options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 A.10 history—Show status of files and users . . . . . . . . . . . . . . . . . . . . . . . . 85

A.10.1 history options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 A.11 import—Import sources into CVS, using vendor branches . . . . . . . 87

A.11.1 import options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 A.11.2 import output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 A.11.3 import examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

A.12 log—Print out log information for files . . . . . . . . . . . . . . . . . . . . . . . . 89 A.12.1 log options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 A.12.2 log examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

A.13 rdiff—’patch’ format diffs between releases. . . . . . . . . . . . . . . . . . . . . 90 A.13.1 rdiff options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 A.13.2 rdiff examples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

A.14 release—Indicate that a Module is no longer in use . . . . . . . . . . . . . 92 A.14.1 release options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.14.2 release output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 A.14.3 release examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

A.15 rtag—Add a symbolic tag to a module . . . . . . . . . . . . . . . . . . . . . . . . 93 A.15.1 rtag options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 A.16 status—Display status information on checked out files . . . . . . . . . 94

A.16.1 status options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 A.17 tag—Add a symbolic tag to checked out versions of files . . . . . . . . 95

A.17.1 tag options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 A.18 update—Bring work tree in sync with repository . . . . . . . . . . . . . . . 96

A.18.1 update options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 A.18.2 update output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 A.18.3 update examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

Appendix B 管理用ファイル便覧 . . . . . . . . . . . . . . . . . . . . . . . . 99

B.1 管理用ファイル modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 B.2 The cvswrappers file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 B.3 commit 支援ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B.3.1 共通の構文 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 B.4 Commitinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 B.5 Editinfo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

B.5.1 Editinfo example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 B.6 ファイル loginfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

B.6.1 loginfo 記述例 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

B.6.2 取得済のコピーを最新に保つ . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

B.7 Rcsinfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 B.8 cvsignore でファイルを無視する . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 B.9 ファイル history. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 B.10 Expansions in administrative files . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Appendix C CVS に影響する全ての環境変数 . . . . . . . . . . . . . . 109

Appendix D トラブルシューティング. . . . . . . . . . . . . . . . . . . . . 111

D.1 魔法の枝番号 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111

Appendix E GNU GENERAL PUBLIC LICENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

索引 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115