CVS と現実の世界 -----------------------
リファレンス -----------
この章は CVS を一度も使ったことが無く、おそらく以前にバージョン管 理ソフトを使ったことの無い人のためのものです。
既に 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 をインターネットからの自由なダウンロードなど、いろいろな方法 で取得することができます。 CVS のダウンロードや、他の CVS の 話題の情報は、以下のところを参照してください。
http://www.cyclic.com/ http://www.loria.fr/~molli/cvs-index.html
info-cvs という CVS 専門のメーリング・リストがあります。
参加、又は脱退したい場合には、
info-cvs-request@gnu.org にメールを出して下さい。
Usenet グループの方を好むのであれば、正しいグループは
comp.software.config-mgmt で、CVS の議論を
するために適した場所です (他の構成管理システムと一緒で
すが)。 将来は comp.software.config-mgmt.cvs を
作ることも可能かもしれませんが、おそらく
comp.software.config-mgmt に十分な流量があるよう
になったときだけでしょう。
BUGS でより詳細に説明されている bug-cvs メーリン
グリストを講読するともできます。講読するためには、
bug-cvs-request@gnu.org にメールを送ってください。
CVS は多くのことができますが、全ての人に全てのことを するようにはなっていません。
Makefile) とは相互作用するかもしれませんが、本質的
に独立したものです。
CVS は、何かの作り方を指示したりはしません。 CVS はあなたの意思に従って、 ツリー構造から望むファイルを取り出すだけです。
CVS は、checkout 先の作業ディレクトリのディスク容量の使用
法について指示したりはしません。あなたが Makefile やスクリプトを
全てのディレクトリで書き、それらが各々全ての相対的な位置を知る必要があ
るとすると、リポジトリ全てを取り出す必要が生じます。
あなたが仕事をモジュール化し、(Makefile に link,
mount, VPATH等を使用して、)ファイルを共有するよ
うな構築システムを構成すれば、好きな様にディスクの利用
法を決めることが出来ます。
しかしこれら全てのシステムは、 構築と維持に多大な労力が必要なことに、 気を付けなければいけません。 CVS は、このような問題に関して考慮しません。
もちろん、これらの構築システムを支援するための道具
(スクリプト, Makefile 等) は、
CVS の管理下に置くと良いでしょう。
何らかの変更があった際に、再構築が必要なファイルを調べるのは、
やはり CVS の守備外です。
伝統的な手法の一例をあげると、
構築には make を用い、
make に必要な依存関係は自動化されたツールを用いて生成します。
CVS と結合して構築を行うための情報は Builds
を参照してください。
CVS は、あなたの調律に従ってソースを踊らせる楽器の
ようなものです。あなたは楽器奏者もしくは作曲者のような
ものです。どんな楽器も勝手に演奏をしたりしないし、音楽
が勝手に書かれたりもしません。
同じファイル (もしくはファイルの集合) に、
同時に加えられた変更に論理的な衝突があっても、
CVS には分りません。
衝突という概念は単に文字列の比較によるもので、
同じファイルを基に加えられた二つの変更が、
merge コマンド (つまり diff3) を驚かせるのに
十分なほど近接している場合にのみ生じます。
CVS は、 プログラムの論理に、文字列でない衝突や、散らばった衝突 があったとしても、警告を表示しません。
例:
あなたは A で定義された関数 X の引数を変更したとします。
同じ時に、誰かが B を編集して、
古い引数を使って X を呼び出したとします。
これは CVS の能力の範囲外です。
仕様書を読み、同僚と話し合う習慣を付けましょう。
rcsinfo と editinfo ファイルを見て下さい
(see Administrative files)。
論理的には一つと考えられる変更のため、
複数のファイルが同時に変更されたことを覚えておくことも、
変更管理と呼ばれます。
複数のファイルの変更を一つの cvs commit により格納した場合、
CVS はそれらのファイルが同時に格納されたことを忘れてしまいます。
そして、それらのファイルを結ぶ事柄は、
同じログ・メッセージを持つことだけになるのです。
GNU 形式の ChangeLog を用いれば何らかの助けになるでしょう。
各変更の状態を覚えておく能力を、変更管理と呼ぶシステムもあります。
開発者によって加えられた変更もあれば、
他の開発者によって追試中の変更もあるとか、そういったことです。
一般的に CVS でこのようなことをするには、
(cvs diff や diff を用いて) 差分を生成し、
patch を当てる人物にメールとして送ります。
これは非常に融通のきく方法ですが、
CVS 以外の機構に依存しているので、
問題が無いことを保証できません。
commitinfo ファイルを使えば、
強制的に必須の項目を検査することは可能だと思います。
しかし、
そんなことをしようとしたプロジェクトのことは聞いたことがありません。
commitinfo, loginfo, rcsinfo, verifymsg
等のファイルを用いて、変更点を格納する前に、
必要な手順を確実に踏むように設定できるでしょう。
また枝やタグといった機構を用いて、
開発用の枝で仕事を実行し、
安定性が証明された確実な変更だけを
安定化指向の枝に統合することも考えられます。
CVS を紹介する方法として、CVS を使って典型的な仕事をしてみま す。最初に理解すべきことは CVS は全てのファイルを中央に集められた リポジトリ (repository) (see Repository) に保存すると いうことです。この節ではリポジトリは準備されていると仮定します。
あなたの仕事は単純なコンパイラを作成することです。ソースは少しの C言語
で書かれたファイルでできていて、Makefile を含んでいるとします。
このコンパイラを tc (Trivial Compiler) と呼ぶことにします。そし
て tc というモジュール名でリポジトリに登録されています。
まず、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 Multiple developers.
あなたはコンパイラが相変わらずコンパイル可能であることを確認し、
backend.c の新しいバージョンとすることに決めました。これは新し
い backend.c をリポジトリに格納し、同じリポジトリを使っている他
の人が使用できるようにします。
$ cvs commit backend.c
CVS はログ・メッセージを記すためにエディタを開きます。 そこで "Added an optimization pass." などと入力し、 一時ファイルに保存し、エディタを終了します。
どのエディタが開かれるかは環境変数 $CVSEDITOR により決定されま
す。$CVSEDITOR が設定されておらず、環境変数 $EDITOR が設
定されていれば、これを使用します。$CVSEDITOR と $EDITOR
の両方が設定されていなければ、オペレーティングシステムに依って違ったデ
フォルトが使われます。例えば、unix では viで、Windows NT/95 で
は notepad です。
加えて、CVS は $VISUAL 環境変数も調べます。この動作が望ま
しいか、また CVS の将来のリリースが $VISUAL を調べるべきか
どうか、という意見は人によって異なります。$VISUAL が設定されて
いないか、$EDITOR に設定されていることを確実にすることで、どち
らになっても対処することができます。
CVS がエディタを開始したときは、修正されたファイルのリストを含ん
でいます。CVS のクライアントでは、このリストはファイルの修正時刻
を、最後にファイルを得た時刻か更新された時刻と比較したものに基づいてい
ます。ですから、ファイルの修正時刻が変わっているけれど内容が変更されて
いないというときも、修正されたものとして表示されます。これに対する最も
簡単な対処法は単純に気にしないことです--それを commitすると、CVS
は内容は修正されていないことを発見し、無修正ファイルであるとして扱いま
す。次の updateはファイルが無修正であるという事実に基づき、将来
のセッションでファイルが表示されないように、タイムスタンプを保存されて
いるものに設定し直します。
わざわざエディタを開くのが嫌ならば、代わりにコマンド行の -m フ
ラグを使うことでログメッセージを以下のように指定することができます:
$ cvs commit -m "Added an optimization pass" backend.c
他の仕事に取りかかる前に、tc の作業コピーを消去することにしました。も ちろん、次のようにしても可能です
$ cd .. $ rm -r tc
しかし、release コマンドを使用するほうが良いでしょう
(see release):
$ 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) directory `tc': n ** `release' aborted by user choice.
release コマンドは、あなたの修正が格納されているかどうか確認し
ます。ログを記録する設定ならば、ファイル history にメモします。
See history file.
release コマンドに -d フラグを使用すると、
確認と同時に作業コピーを削除します。
上の例では、release コマンドが何行か出力しています。
? tc は CVS が tc というファイルを知らないという意味です。
モジュール tc のことではなく、
生成したコンパイラ tc を指しており、
これはリポジトリに格納しなくて良いので無視して構いません。
この警告を消すための情報は cvsignore 参照。
release の出力の詳細な説明は release output 参照。
M driver.c の方は重要です。
これは、driver.c というファイルに加えた修正が、
格納されていないことを指摘しています。
release コマンドは、常に作業コピーの
修正が加えられたファイルの数を報告した後、
ファイルを削除したり履歴ファイルにメモする前に、
その確認を求めてきます。
ここでは大事を取って、最後に release が確認を求めたときに
n <RET> を入力しました。
あなたは 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) directory `tc': y
CVS のリポジトリ (repository) は、 バージョン管理の対象となる全てのファイルとディレクトリの、 完全なコピーを保管します。
通常、リポジトリ中のファイルを直接利用することはありません。 その代わりに CVS コマンドを使用して、 作業者自身のファイルのコピーを 作業ディレクトリ に取り出し、そのコピーを用いて作業します。
そして一連の変更が完了したときに、変更点をリポジトリに書き戻します (も しくは 格納 します (commit))。リポジトリは、変更を加えたも のと同じになり、また同時に変更点や、変更日時などの情報も正確に記録され ます。リポジトリは作業ディレクトリのサブディレクトリやその逆ではないこ とに注意してください。別の位置にあるべきです。
CVS は様々な方法でリポジトリを利用することができます。
リポジトリは、使用中のコンピュータ内であってもいいし、
別の部屋のコンピュータや、別の国のコンピュータであっても構いません。
リポジトリに接続する方法を区別するために、
リポジトリの名前の最初に接続経路 (access
method) を加えることがあります。例えば :local: は、リポジトリ
であるディレクトリを利用することを意味します。つまり
:local:/usr/local/cvsroot で表されるリポジトリは、CVS を実
行したコンピュータの /usr/local/cvsroot というリポジトリを意味
します。他の接続経路については Remote repositories 参照。
接続経路の指定が省略され、リポジトリに : が含まれない場合には、
:local: が仮定されます。
: が含まれていた場合には、
:ext: か :server: が仮定されます。
例えばリポジトリ /usr/local/cvsroot が同じコンピュータ内にある場合、
:local:/usr/local/cvsroot を省略して
/usr/local/cvsroot と記述しても構いません。
しかし(Windows NT などで)、
リポジトリが c:\src\cvsroot にある場合、
:local:c:\src\cvsroot として、
接続経路を明示する必要があります。
リポジトリは二つの要素から構成されます。
$CVSROOT/CVSROOT には CVS の管理用ファイルが置かれます。
その他のディレクトリには、使用者が定義したモジュールの実体が置かれます。
CVS にリポジトリの場所を教えるには、
いくつか方法があります。
一つ目はコマンド行で、
-d ("directory" を示します) オプションを用いて
指定する方法です:
cvs -d /usr/local/cvsroot checkout yoyodyne/tc
二つ目は、環境変数 $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 が一致しない場合は、
前者が使用されます。
もちろん、
二つともが同じリポジトリを参照するのが、まともなやり方です。
CVS がリポジトリに情報を保存する方法を知っていても、 たいてい何の役にも立ちません。 実際、過去に書式が変更されましたし、 将来変更されることもあるでしょう。 ほとんど全ての場合、 CVS コマンドを通してリポジトリを利用しますから、 書式を変更しても混乱は起きません。
しかし、リポジトリでのデータ保存方法の知識が必要な場合もあります。例え ば CVS のロック解除が必要な場合 (see Concurrency) や、リポジ トリのファイルの許可属性を適切に設定する必要がある場合などです。
リポジトリの全体構造は作業コピーに対応するディレクトリ木で構成されてい ます。例えば、リポジトリが
/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 のソー
ス配布のファイル doc/RCSFILES を参照してください。
このファイル書式は非常に一般的なので、
CVS や RCS 以外のシステムでも、
少くとも理解をすることができます。
CVS で使用されている RCS ファイルは標準の書式と少し違います。 最大の違いは魔法の枝です。詳細は Magic branch numbers を参照して ください。CVS では、有効なタグ名は RCS で使用できるもののサ ブセットになっています。CVS の規則は Tags を参照してくださ い。
全ての ,v ファイルは読み込み専用であり、
この使用許可を変えるべきではありません。
これに対し、リポジトリ中のディレクトリは、
ファイルの修正を行なう人物に対して、
書き込みを許可しなくてはいけません。
これはつまり、
ファイルの修正を行なう人物からなるグループを作って
(group(5)参照)、
そのディレクトリの所有グループとすることを意味しています。
従って、 ディレクトリ単位でしかファイルのアクセス権を 管理することができません。
CVS はロック・ファイルを作成する必要があるため (see Concurrency)、ファイルを取り出す使用者にも、書き込み許可が必 要であることに注意して下さい。
利用者は CVSROOT/val-tags ファイルに書き込み許可が必要なことも
注意してください。CVS はそれをどのタグが有効かを記録するために使
います (作成時と、ときどきタグが使用されたときに更新されます)。
それぞれの RCS ファイルは最後に書き込んだ利用者に所有されます。こ れはあまり重要ではありません。重要なのは誰がディレクトリを所有している かです。
木の中に新しいディレクトリを加える場合、
CVS はできるだけ適当な使用許可を与える努力をします。
しかし新しいディレクトリの使用許可が、
親ディレクトリのものと異なる必要がある場合には、
手動で変更する必要があります。
環境変数 CVSUMASK を設定すれば、
リポジトリに作成されるディレクトリやファイルの使用許可を管理できます。
CVSUMASK は、作業ディレクトリのファイル使用許可には影響しません。
作業コピーの使用許可は、
新たに作成したファイルに通常与えられるものと同じです。
但し、CVS が読み込みだけを許可することがあります
(監視時 Setting a watch, -r 使用時 Global options,
CVSREAD 設定時 Environment variables を各々参照)。
クライアント/サーバ CVS を使用すると (see Remote repositories)、CVSUMASK を設定する良い方法はありません。クライ
アントマシンでの設定は効果がありません。rsh で接続しているなら、
オペーレーティングシステムの説明に書いてあるように、.bashrc や
.cshrc で CVSUMASK を設定することができます。この振る舞
いは将来のバージョンの CVS では変更されるかもしれません。クライア
ントの CVSUMASK の設定には頼らず、それは無効になるでしょう。
pserver を使う場合は、一般的に、 CVSROOT ディレクトリと木構造でそ れより上のディレクトリには厳しい使用許可が必要です。Password authentication security を参照してください。
オペレーティングシステムには特定のプログラムが、プログラムの呼び手には できないような動作をする能力とともに実行される機能があるものがあります。 例えば、unix の set user ID (setuid) や set group ID (setgid) 機能や VMS の installed image 機能です。CVS はそのような機能を使用するように 書かれていませんので、そのような方法で CVS をインストールすると事故の 過失に対する保護しか提供できなくなります。方法を欺くことを試そうとして いる人は誰でもそうすることができ、設定に応じて CVS だけに留まらない使 用許可を得るかもしれません。代わりに pserver を使用することを考えるか もしれません。それは同じ属性のいくつかを共有していますので、間違ったセ キュリティの設定や、修正したいものよりも大きなセキュリティホールを提供 する可能性がありますので、このオプションを考えているなら、pserver の説 明文書を注意深く読んでください。(Password authentication security)。
ファイルの使用許可には Windows オペレーティングシステムに特有の問題も あります (Windows 95, Windows NT, とおそらくこの系統の将来のオペレーティ ングシステムです。以下の項目で OS/2 に当てはまることもあるでしょうが、 確かではありません)。
ローカルの CVS を使っていて、リポジトリが Samba SMB サーバによってネッ トワーク接続されたファイルシステムにあるときに、使用許可で問題がおこる ことがあることが報告されています。Samba の設定で WRITE=YES にすると修 正される/何とかなると言われています。 責任放棄: 私はそのオプションを使用可にしたときの副作用について十分な調 査をしていません。加えて、問題を避けるために CVS が違ったようにするこ とができるかどうかも調べていません。何か発見したなら、BUGS に書 かれているように我々に報せてください。
ときどき CVS は RCS ファイルを Attic に保存することが
あることに気付くでしょう。例えば、CVSROOT が
/usr/local/cvsroot でディレクトリ yoyodyne/tc のファイル
backend.c について話をしているとき、普通はファイルは以下のとこ
ろにあります
/usr/local/cvsroot/yoyodyne/tc/backend.c,v
しかし、attic に行けば、代わりに
/usr/local/cvsroot/yoyodyne/tc/Attic/backend.c,v
になります。利用者にとってはファイルが attic にあるかどうかは関係あり
ません。CVS はこれを記録し、必要なときは attic を調べます。詳細を
知りたい人のために書くと、幹の先頭リビジョンが dead の状態であ
るまさにそのときだけ、ファイルは attic に保存されます。dead の
状態とはそのリビジョンでファイルが消去されたか、一度も加えられたことが
ない、ということです。例えば、枝にファイルを加えると、幹のリビジョンは
dead の状態になり枝のリビジョンは dead ではない状態にな
ります。
それぞれのリポジトリのディレクトリの CVS ディレクトリはファイル
属性などの情報が収められています (CVS/fileattr というファイルで
す。)。将来はこのディレクトリには他のファイルが加えられる可能性があり
ますから、実装は追加のファイルを静かに無視するのが良いでしょう。
この動作は CVS 1.7 とその後のものだけで実装されています。詳細は Watches Compatibility を参照してください。
fileattr ファイルの書式は以下の形式の登録の連続したものです ({
と } は括弧の中のテキストを0回以上繰り返すことができるというこ
とです):
ent-type filename <tab> attrname = attrval {; attrname = attrval} <linefeed>
ent-type はファイルでは F で、その場合は登録はそのファイ
ルの属性を指定します。
ent-type が D で、filename が空であると、新しく追加
されたファイルへの既定属性を指定します。
他の ent-type は将来の拡張のために予約されています。CVS 1.9 とそ れ以前のものはファイル属性を書き込むときにいつでもそれらを消すでしょう。 CVS 1.10 とそれ以降はそれらを保存します。
行の順番は関係無いことに注意してください。 fileattr ファイルを書き込むプログラムは便利な様に再編成するかもしれま せん。
ファイル名でのタブとラインフィード、attrname での =,
attrval での ;、などを引用する方法は今はありません。
習慣では、attrname は CVS により特別な意味を持っている属性は
_ で始まります。他の attrname は使用者定義の属性のために
あります (もしくは、実装が使用者定義の属性のサポートを始めたときにそう
なるでしょう)。
作りつけの属性です:
_watched
_watchers
cvs
edit コマンド (もしくはそれと等価なもの) が発生したときで、
hostname と pathname は作業ディレクトリのためです。
例:
Ffile1 _watched=;_watchers=joe>edit,mary>commit Ffile2 _watched=;_editors=sue>8 Jan 1975+workstn1+/home/sue/cvs D _watched=
は file1 は読み込み専用で取り出されるべきだということです。加え
て、joe は edit を監視しており、mary は commit を監視しています。ファ
イル file2 は読み込み専用で取り出されるべきです。sue は 1975年1
月8日にマシン workstn1 のディレクトリ /home/sue/cs編集を
始めました。この例を表現するために、D, Ffile1,
Ffile2 の後に空白を表示していますが、実際は単独のタブ文字がそこ
にあり、空白があってはいけません。
利用者から見える部分の CVS のロックに焦点をあてた紹介は Concurrency を参照してください。次の部分は同じリポジトリをアクセ スする他のツールに干渉することなく CVS のリポジトリにアクセスするよう なツールを書きたい人を対象にしています。読み込みロック (read lock), 書き込みロック (write lock), デッ ドロック (deadlock) のような概念がよくわからなかったら、オペレー ティングシステムやデータベースの文献を参照すると良いかもしれません。
リポジトリ中の #cvs.rfl. で始まる全てのファイルは読み込みロック
です。リポジトリ中の #cvs.wfl で始まる全てのファイルは書き込み
ロックです。古いバージョンの CVS (CVS 1.5 以前) は #cvs.tfl で
始まる名前のファイルも作成していましたが、ここではそれらは議論しません。
ディレクトリ #cvs.lock はマスターロックとして働きます。すなわち、
他のロックを取得する前に、まずこのロックを取得しなければならない、とい
うことです。
書き込みロックを取得するためには、まず #cvs.lock ディレクトリを
作成します。この操作は原子的操作でなければなりません (これはたいていの
オペレーティングシステムで真のはずです)。 既にディレクトリが存在したた
めに失敗すれば、しばらく待ってもう一度試します。#cvs.lock ロッ
クを取得した後、#cvs.rfl. の後に選択した情報 (例えば、ホスト名
とプロセス番号) が続いた名前のファイルを作成します。それからマスターロッ
クを解放するために #cvs.lock ディレクトリを消去します。それから
リポジトリを読んで続行します。終った後、読み込みロックを解放するために
#cvs.rfl ファイルを消去します。
書き込みロックを取得するためには、読み込みロックと同様にまず
#cvs.lock ディレクトリを作成します。それから #cvs.rfl.
で始まるファイルが無いかどうかを調べます。もしあれば、#cvs.lock
を消去し、しばらく待って、もう一度試します。読み込み手がいないときは、
#cvs.wfl の後に選択した情報を続けた名前のファイルを作成します
(例えば、ホスト名とプロセス番号)。ロック #cvs.lock を続けます。
リポジトリへの書き込みを実行します。それが終わると、まず
#cvs.wfl ファイルを消去し、それから #cvs.lock ディレクト
リを消去します。#cvs.rfl ファイルと違って、#cvs.wfl ファ
イルは情報提供のためだけにあることに注意してください。#cvs.lock
そのもののロックを続ける以上のロック操作の効果はありません。
それぞれのロック (書き込みロック及び読み込みロック) は Attic と
CVS を含んだリポジトリの単独のディレクトリのみをロックしますが、
バージョン管理下の他のディレクトリは含まないことに注意してください。木
全体をロックするためには、それぞれのディレクトリをロックする必要があり
ます (必要なロックのどれかの取得に失敗したら、デッドロックを避けるため
に再挑戦の前に木全体を解放しなければならないことに注意してください)。
CVS は個々の foo,v ファイルへのアクセス制御のために書き込
みロックを期待するということにも注意してください。RCS には
,foo, ファイルがロックとして働く機構がありますが、CVS はそ
れを実装しておらず、CVS の書き込みロックを取り出すことが推奨され
ています。さらなる議論/合理性は CVS のソースコードの
rcs_internal_lockfile のところのコメントを読んでください。
$CVSROOT/CVSROOT ディレクトリにはいろいろな管理ファイルがありま
す。ある面ではこのディレクトリはリポジトリの他のディレクトリとよく似て
います。そこにはファイル名が ,v で終わる多くの RCS ファイ
ルがあり、多くの CVS コマンドは同じ方法でそれを操作します。しかし、
少しの違いはあります。
それぞれの管理ファイルには、RCS ファイルに加えて、ファイルの取り
出された版のコピーがあります。例えば、RCS ファイル
loginfo,v とそれの最新リビジョンであるファイル loginfo
があります。管理ファイルを格納したときは、CVS は
cvs commit: Rebuilding administrative file database
を印字し、$CVSROOT/CVSROOT の取り出された版のコピーを更新するよ
うになっています。もしそうならなければ、何かがおかしくなっています
(see BUGS)。自分自身のファイルをこのように更新されるファイル群に追
加するために、それらを管理ファイル checkoutlist に追加できます
(see checkoutlist)。
初期設定では modules ファイルは上で説明されているように振舞いま
す。modules ファイルがとても大きくなると、普通のテキスト・ファイルとし
て保存しているとモジュールの探索が遅くなるかもしれません (CVS が
最初にこの機能を追加したときほど関心があるかどうかは定かではありません。
ベンチマークは見ていませんので)。ですから、CVS ソースコードに適切
な修正を加えるとおで、modules ファイルを Berkeley db や GDBM のような
ndbm インターフェースを実装したデータベースで保存することができ
ます。このオプションが使用されると、modules データベースは
module.db, modules と/もしくは modules.dir に保存
されます。
いろいろな管理ファイルの意味に関する情報は Administrative files を参照してください。
しばしば表面に現れてくるかもしれない CVS の内部についての話をして
いる間に、CVS が作業ディレクトリの CVS ディレクトリに何を
入れるかも話した方が良いでしょう。リポジトリと同様に、CVS がこの
情報を扱い、普通は CVS のコマンドを通してだけそれを使用します。で
も、ときにはそれを覗くのも良いでしょうし、グラフィカル・ユーザ・インター
フェース の jCVS や emacs のための VC パッケージなどの他
のプログラムがそれを見る必要があるかもしれません。そのようなプログラム
は、上で書いたプログラムやコマンド行 CVS クライアントの将来のバー
ジョンを含む、そのファイルを使う他のプログラムと協調して動作しようと望
むなら、この節の推奨規格に従う必要があります。
CVS ディレクトリには複数のファイルがあります。このディレクトリ
を読むプログラムは、将来の拡張の余地を残すために、ディレクトリには存在
するけれどここで説明されていないファイルは静かに無視するのが望ましいで
す。
ファイルは使用しているシステムのテキストファイルの習慣に従って保存され ます。これはテキストファイルの補完の習慣が違うシステム間では作業ディレ クトリは可搬性が無いということです。これは意図的になされていて、おそら く CVS で管理されているファイル自体がそのようなシステム間では可搬性が ないであろう、という理由に基づいています。
Root
Repository
cvs -d :local:/usr/local/cvsroot checkout yoyodyne/tc
Root は以下のようになり
:local:/usr/local/cvsroot
Repository は
/usr/local/cvsroot/yoyodyne/tc
か
yoyodyne/tc
のどちらかになります。
特定の作業ディレクトリがリポジトリのディレクトリに対応しなければ、
Repository は CVSROOT/Emptydir になっているはずです。
Entries
最初の文字が / であれば、様式は:
/name/revision/timestamp[+conflict]/options/tagdate
で、[ と ] は登録の一部ではありませんが、その代わりに
+ と衝突の印は省略任意であることを示しています。name はディ
レクトリ中のファイルの名前です。revision は作業中のファイルの元
のリビジョンで、0 の場合は追加されたファイル、- の後にリ
ビジョンは削除されたファイルです。timestamp は CVS がファイ
ルを作成したときのタイムスタンプです。タイムスタンプがファイルの実際の
修正時刻と違えば、ファイルは修正されたということです。それは ISO C
astime() 関数で使われる様式で保存されます (例えば、Sun Apr 7
01:29:26 1996)。ファイルが常に修正されていると見なされるように、例え
ば、Result of merge のようにその様式とは違う文字列を書くかもし
れません。これは特別な場合ではありません。ファイルが修正されたかどうか
を調べるために、プログラムはファイルのタイムスタンプを単純に
timestamp と文字列比較をするべきです。衝突があれば、
conflict は、ファイルが衝突の印とともに書き込まれた後でファイル
の修正時刻に設定することができます (see Conflicts example)。 もし
conflict がその後も実際の修正時刻と同じであるなら、ユーザは明か
に衝突を解消していません。options は貼り付けられたオプションを保
持しています (例えば、バイナリ・ファイルのための -kbd)。
tagdate は T の後にタグ名が続いているか、日付 (date) の
D で、貼り付けられたタグか日付がつづいているかのどちらかを保持
しています。timestamp が単独のタイムスタンプではなく、スペースで
分離されたタイムスタンプの対であるなら、CVS 1.5 より前のバージョ
ンの CVS を扱っているということに注意してください (ここでは説明さ
れていません)。
CVS/Entries のタイムスタンプの標準時 (ローカルもしくは共通時) はオペレー ティングシステムがファイル自身のタイムスタンプとして保存するものと同じ である必要があります。例えば、Unix ではファイルのタイムスタンプは共通 時刻 (UT) ですので、CVS/Entries のタイムスタンプもそうなっているべきで す。VMS ではファイルのタイムスタンプはローカル時刻なので、 VMS 上の CVS はローカル時刻を使うべきです。この規則は、標準 時が変わったためだけでファイルが修正されたようにならないためです (例え ば、サマータイムになったり、それが終わったときなどです)。
Entries の行の最初の文字が D であると、それはサブディレ
クトリを現しています。行が D だけのときは、 Entries ファ
イルを書いたプログラムはサブディレクトリを記録したということを現します
(ですから、そのような行があって、他に D で始まる行がなければ、
サブディレクトリがないことがわかります)。そうでなければ、行は次のよう
になっています:
D/name/filler1/filler2/filler3/filler4
ここで name はサブディレクトリの名前であり、将来の拡張のために、
全ての filler 部分は暗黙の内に無視されるべきです。Entries
を修正するプログラムはこれらの部分を保存するのが望まれています。
ファイル Entries 中の行はどんな順番でも構いません。
Entries.Log
Entries に無いさらなる情報を記録することはありま
せんが、Entries ファイル全体を再書き込みすることなく、情報を更
新するための方法をもたらし、その中には Entries と
Entries.Log を書いているプログラムが不意に異常終了しても情報を
保護する機能もあります。Entries ファイルを読み込むプログラムは
Entries.Log も調べるべきです。後者が存在すれば、Entries
を読み込んで、Entries.Log にある変更を適用すべきです。変更を適
用した後で、Entries を再度書き込んで、Entries を消去する
習慣が推奨されています。Entries.Log の行の様式は、単独文字コマ
ンドがあり、その後にスペースが続き、その後は Entries の行に指定
された様式になります。単独文字コマンドは登録が追加されたことを示す
A と登録が消去されたことを示す R か、Entries の登
録行は暗黙に無視されるべきことを示す他の文字です (将来の拡張のため)。2
番目の文字が Entries.Log の行の2番目の文字がスペースでないと、
それは CVS の古いバージョンで書かれています (ここでは説明されてい
ません)。
読み込みではなく、書き込みをしているプログラムは、もし望むならば
Entries.Log ファイルを安全に無視することもできます。
Entries.Backup
Entries.Backup に書き、それから Entries に改名する (もし
可能なら原子的操作で) ことです。
Entries.Static
update コマンドを -d オプションとともに使っ
てください。そうすれば、追加のファイルを取得して、
Entries.Static を消去します。
Tag
T、枝でないタグは N、日付は D にな
り、他の文字は、将来の拡張のため暗黙に無視されるべきとなっています。こ
の文字の後にタグや日付が続きます。ディレクトリごとの貼り付きタグや日付
は新規に追加されたファイルに適用されること等に使用されることに注意して
ください。貼り付きタグと日付に関する一般的な情報は Sticky tags
を参照してください。
Checkin.prog
Update.prog
-i と -u
オプションで指定されたプログラムを保存します。
Notify
edit や
unedit のため) を保存します。書式はまだここでは説明されていませ
ん。
Notify.tmp
Notify の関係は Entries.Backup と
Entries の関係と同じです。即ち、Notify を書くためにはま
ず新しい内容を Notify.tmp に書き、それから (可能であれば自動的
に) それを Notify に改名します。
Base
edit コマンドはファイルの元のコピーを
Base ディレクトリに保存します。これで、サーバと通信できないとき
でさえ unedit コマンドが実行できるようになります。
Baserev
Base ディレクトリのそれぞれのファイルのリビジョ
ンを一覧にします。書式は:
Bname/rev/expansion
で、expansion は将来の拡張のために、無視されるべきものです。
Baserev.tmp
Baserev の関係は Entries.Backup と
Entries との関係と同じです。即ち、Baserev に書くために、
まず新しい内容を Baserev.tmp に書き、それから (もし可能なら自動
的に) それを Baserev に改名します。
Template
rcsinfo ファイルで指定された雛型が入っています
(see rcsinfo)。それはクライアントだけに使われます。非クライアント/
サーバ型 CVS は直接 rcsinfo ファイルを調べます。
$CVSROOT/CVSROOT には、いくつか 管理用ファイル
(administrative files) があります。完全な説明は
See Administrative files. これらのファイルが無く
ても CVS を使用することができます。しかし、少なくとも
modules というファイルが適切に設定してあれば CVS のコマン
ドはうまく働きます。
管理用ファイルの中で、
最も重要なファイルは modules です。
これはリポジトリの中の全てのモジュールを定義しています。
modules ファイルの例を次に示します。
CVSROOT CVSROOT modules CVSROOT modules cvs gnu/cvs rcs gnu/rcs diff gnu/diff tc yoyodyne/tc
modules ファイルは行ごとに意味を持つファイルです。
modules ファイルの各行はそれぞれ、
モジュール名, 空白, モジュールのあるディレクトリ名
という書式で記述されます。
モジュールのあるディレクトリ名は、
$CVSROOT からの相対パスです。
modules ファイルの各行はそれぞれ、
モジュール名, 空白, モジュールのあるディレクトリ名
という書式で記述されます。
モジュールのあるディレクトリ名は、
$CVSROOT からの相対パスです。
上の例の最後の4行はそのような行の例です。
モジュール modules を定義する行については、
ここでは説明しません。
より詳しい説明は modules 参照。
管理用ファイルは、
他のモジュールと同じ方法で編集します。
cvs checkout CVSROOT を用いて作業コピーを取り出して、
編集し、通常通り変更内容を格納します。
間違いのある管理用ファイルを格納することも可能です。 このような場合には、間違いを正して新たなリビジョンを登録します。 しかし管理用ファイルに深刻な間違いがあれば、 新たなリビジョンの登録さえも不可能になります。
特定の状況では一つ以上のリポジトリを持つことは良い考えです。例えば二つ
のプロジェクトがあり、全くコードが重複しないような場合です。複数のリポ
ジトリ持つためにはしなければならないことは、適切なリポジトリを、環境変
数 $CVSROOT で設定するか、CVS のオプション -d に指
定するか、もしくは、(一度作業ディレクトリを取り出せば) 単純に CVS
に作業ディレクトリ取り出しに使われたリポジトリを使わせる、ということだ
けです。
複数のリポジトリを持つ大きな利点は、各々を別のサーバに置けることです。 CVS バージョン 1.10 では、単独のコマンドは違うリポジトリのディレ クトリを再帰的に辿ることはできません。開発バージョンの CVS では、 複数のサーバから作業ディレクトリに取り出すことがでます。CVS は要 求されたコマンドを実行するために必要であれば、再帰的に動作し、対応する 数のサーバ・マシンに接続するという細い作業全部を扱います。 以下は作業ディレクトリを設定する例です:
cvs -d server1:/cvs co dir1 cd dir1 cvs -d server2:/root co sdir cvs update
cvs co コマンドは作業ディレクトリを設定し、それから cvs
update コマンドは server2 に接続し、dir1/sdir サブディレクトリを更新
し、その他のものを更新するために server1 に接続します。
CVS リポジトリを設定するために、まずソースファイルのリビジョン履 歴を保存したいマシンとディスクを選びます。CPU とメモリの要求は小さなも のですので、たいていのマシンは十分なはずです。詳細は Server requirements を参照してください。
ディスクスペースの必要量を見積もると、別のシステムから RCS ファイルを 移管しているのであれば、リポジトリの最初の大きさは大体そのくらいになり、 バージョンの履歴が全然無い状態で始めるのであれば、大雑把な大きさはリポ ジトリのCVS の管理下に置かれるコードのほぼ3倍をサーバで用意することに なります (最終的にはこれより大きくなるでしょうが、しばらくは大丈夫なは ずです)。開発者が作業するマシンでは各開発者に作業ディレクトリとほぼ同 じディスクスペースを用意すると良いでしょう (各開発者の利用に基づいて、 全体の木かそれの一部分のどちらかになります)。
リポジトリはサーバ経由からか直接 CVS を使う全てのマシンからか、 (直接もしくはネットワーク接続されたファイルシステム経由で) 利用可能に する必要があります。クライアントのマシンは CVS プロトコル経由以外 でそれにアクセス可能である必要はありません。CVS は、リポジトリに ロック・ファイルを作成する必要があるため (see Concurrency)、利用者 が読み込み許可しか持たないリポジトリを、CVS から使うことはできま せん。
リポジトリを作成するときには、cvs init コマンドを実行して下さい。
通常の方法で指定された CVS のルート (see Repository) 以下の、
空のリポジトリを利用できるように整えます。例えば次のようにします。
cvs -d /usr/local/cvsroot init
cvs init は注意深いので、リポジトリに存在するファイルを上書きし
ません。従って既に利用できる状態のリポジトリに対して cvs init
を実行しても、何の不都合もありません。
cvs init は、操作履歴を記録するように設定します。
もしこれを望まないのであれば、cvs init を実行した後に、
history ファイルを削除して下さい。See history file.
リポジトリ中のファイルに関して、特に魔法のような事はありません。ほとん どの場合、他のファイルと同様にバックアップできます。しかし、考慮すべき 点も幾つかあります。
最初の点は偏執的で、バックアップ中には CVS を使用しないか、バック
アップ中はバックアッププログラムに CVS をロックさせる必要がありま
す。CVS を使わないために、リポジトリを操作できるマシンへのログイ
ンを禁止したり、CVS サーバを停止したり、同様な機構を利用するかも
しれません。詳細はあなたのオペレーティングシステムと、CVS を設定
した方法に依存します。CVS をロックするためには、#cvs.rfl
ロックをそれぞれのリポジトリのディレクトリに作成するでしょう。このよう
に言ってきましたが、これらの事前注意をせずにただバックアップを行なって
も、結果が特に悲惨になる可能性はあまりありません。バックアップから復元
すると、リポジトリは不整合状態になるかもしれませんが、手で修正すること
が非常に難しいということは無いでしょう。
リポジトリをバックアップから復元し、リポジトリ中の変更がバックアップ時 から変更されていると仮定すると、失敗に影響を受けあかったディレクトリは 今やリポジトリに存在しなくなってしまったリビジョンを参照しているかもし れません。そのようなディレクトリで CVS を実行しようとすると、普通 はエラーメッセージを出力します。これらの変更をもう一度リポジトリに戻す 方法の一つに以下のようなものがあります:
CVS ディレクトリの内容をコピーしないでください)。
cvs update や cvs diff
のようなコマンドを使って何が変更されたかを見つけ、準備がでいたなら、変
更をリポジトリに格納します。
リポジトリ中のファイルのバックアップが他のファイルのバックアップと良く 似ているように、リポジトリを別の場所に移動する必要があるときも、それは 他のファイルの集合を移動するのと非常に良く似ています。
主に考慮することは、作業ディレクトリがリポジトリを指しているか、という
ことです。移動されたリポジトリを扱う一番簡単な方法は、移動後にただ新し
い作業ディレクトリを取得することです。もちろん、移動前に古い作業ディレ
クトリが格納されたかを確かめたいでしょう。もしくは変更を失わないような
何らかの他の方法を見つけているかもしれません。もし本当に既に存在する作
業ディレクトリを再利用したいなら、CVS/Repository ファイルを手で
手術することで可能です。CVS/Repository と CVS/Root ファ
イルの情報は Working directory storage で参照することができます
が、わずらいたいと本当に思っていないかぎりは、労力に見合わないでしょう。
ソースの作業コピーはリポジトリと別のマシンに存在することができます。 CVS をこの方法で使うことは クライアント/サーバ (client/server) 操作として知られています。クライアント と して、CVS を作業ディレクトリを mount できるマシンで CVS を実 行し、サーバ となる、リポジトリを mount できるマシンと通信するよ うに告げます。一般的に、遠隔リポジトリを使うことは、リポジトリ名の様式 が以下のようになることを除き、ローカルのものを使うのと同じです:
:method:user@hostname:/path/to/repository
どれが本当に設定する必要があるかは、サーバに接続している方法に依って変 わります。
method が指定されず、リポジトリ名に : が含まれる場合には、
使用するオペレーティングシステムに依って ext か server
が既定値とされます。詳しくは Connecting via rsh 参照。
rsh プログラムを利用する
cvs serverを使う
サーバとしてどんな種類のマシンが適切かという質問への手短な答は、要求は こじんまりとしたものであるということです--32M のメモリやそれ以下のサー バでさえ、かなり大きなソース木とかなりの量の活動を扱うことができます。
もちろん、本当の答はもっと複雑です。既知の大量のメモリ消費をする部分の 見積りは、メモリの要求を見積るのに十分でしょう。ここにはそのような部分 が2つ書いてあります。他のメモリ消費は比較的小さいはずです (もしそうで ないものがあれば、この説明文書を更新できるように、BUGS に書かれ ているように、我々に知らせてください)。
大量のメモリ消費をする最初の部分は、CVS サーバを使っているときの 大きな取り出しです。サーバは、扱っているそれぞれのクライアントのための 2つのプロセスからなります。子プロセスのメモリ消費は非常に少く抑えられ ているはずです。親プロセスのメモリ消費は、特にクライアントとのネットワー ク接続が遅ければ、一つのディレクトリのソースの大きさよりも少し大きくな るか、2メガバイトほどかどちらか大きいものになることが予想されています。
それぞれの CVS サーバの大きさを予想上の一度に活動するサーバ数で掛 けたものによって、サーバのメモリの要求の輪郭を得ることができます。たい ていの場合、親プロセスでのメモリ消費は物理メモリではなくてスワップメモ リでしょう。
大量のメモリ消費の2番目の部分は、大きなファイルを格納しているときの
diff です。これはバイナリ・ファイルでさえも必要です。大体の目安
は、格納したい最大のファイルの大きさの10倍を用意することですが、5倍が
適当でしょう。例えば、10メガバイトのファイルを格納したいときは、格納を
するマシン (クライアント/サーバ ならサーバマシン、クライアント/サーバ
でなければ、CVS を実行しているマシン) に100メガバイトのメモリがあ
るのが良いです。これは物理メモリでなく、スワップであるかもしれません。
メモリが必要なのは短時間だけなので、そのような格納が同時に2つ以上なさ
れるときのためのメモリを準備する必要は特にありません。
クライアントの資源消費はさらに少ないです--オペレーティングシステムを 動作させるために十分な能力のあるマシンなら、ほとんど問題はないでしょう。
ディスク容量に対する要求の情報は、Creating a repository を参照し てください。
CVS はこれらの操作を実行するために rsh プロトコルを用いますので、
遠隔側の使用者のホストはローカルの使用者の接続を許可する
.rhosts を持つ必要があります。
例えば、あなたがローカルマシン toe.example.com の利用者
mozart であり、サーバマシンは faun.example.org であると
しましょう。faun では、以下の行を bach のホームディレクトリ
の .rhosts ファイルに書いてください:
toe.example.com mozart
そして、rsh の動作を次の行で確認します。
rsh -l bach faun.example.org 'echo $PATH'
次に rsh が、
サーバを発見できるかどうか確認する必要があります。
上記の例で rsh が表示したパスの中に、
サーバである cvs のあるディレクトリが
含まれているかどうか確認して下さい。
.login や .profile でなく、
.bashrc, .cshrc 等に
パスを設定する必要があります。
代わりに、クライアント側で環境変数 CVS_SERVER に、
/usr/local/bin/cvs-1.6 などと、
使用したいサーバ名を設定できます。
inetd.conf を編集したり、
CVS のサーバ・デーモンを走らせる必要はありません。
rsh 経由で $CVSROOT を利用するときに
指定できる接続経路は二つあります。
: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 の代替物の文書資料を参照して下さい。
例を続けます。仮に faun.example.org の
リポジトリ /usr/local/cvsroot/ 中の
モジュール foo を利用したい場合には、
もう準備はできています:
cvs -d :ext:bach@faun.example.org:/usr/local/cvsroot checkout foo
(クライアント側とサーバ側で、使用者名が同じ場合には、
bach@ を省略することが出来ます。)
CVS のクライアントは、
パスワード・プロトコルを用いて、
サーバと接続することもできます。
この方法は、
rsh の使用が可能でなく
(例えばサーバが防火壁の向こうにある場合)、
またケルベロスも利用できない場合に特に有効です。
この方法を使用するために、 サーバとクライアント双方での調整が必要になります。
まず最初に、$CVSROOT と $CVSROOT/CVSROOT ディレクトリの
使用許可をきつくすることを考えるでしょう。詳細は Password authentication security を参照してください。
サーバ側では /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 --allow-root=/usr/cvsroot pserver
-T オプションで一時ファイルを作成するディレクトリも指定できます。
--allow-root オプションは使用可能な CVSROOT ディレクトリを
指定します。違う CVSROOT ディレクトリの使用を試みるクライアントは
接続できません。許可したい CVSROOT ディレクトリが2つ以上あるなら、
オプションを繰り返してください。(不幸なことに、inetd の多くのバー
ジョンはコマンドと引数の両方、もしくはどちらかの長さ全体に対して非常に
小さくなるように制限を課しています。この問題に対する普通の解決は、
inetd に CVS を必要な引数と共に起動するシェルスクリプトを
実行させることです。)
あなたの使用する inetd が、
素のポート番号ではなく、サービス名を要求するならば、
/etc/services に次の行を追加して下さい:
cvspserver 2401/tcp
そして inetd.conf には、
2401 ではなく cvspserver と記述して下さい。
以上を注意して行なった後、
inetd を再起動するか、
初期設定ファイルを再読させるのに必要な処置を取って下さい。
これの設定に問題があるときは、Connection を参照してください。
クライアントはパスワードを平文のまま保存または伝送します
(ほぼそのように--詳細は Password authentication security)。
従って、リポジトリを利用する時に、
正規のパスワードを危険に曝さないために、
CVS では別のパスワードファイルを使用します。
このファイルは $CVSROOT/CVSROOT/passwd です。
その書式は、使用者名、パスワード、サーバが使用する任意に省略可能な使用
者名という二つか三つの欄しかない事を除けば、
/etc/passwd と同様です。
次に例示します:
bach:ULtgRLXo7NRxs cwang:1sOp854gDF3DY
パスワードは、標準 Unix の関数 crypt() によって暗号化されます。
従って、標準 Unix の passwd から直接コピーすることも可能です。
パスワード認証では、まずサーバが、
CVS の passwd ファイル中の、使用者のエントリを確認します。
使用者のエントリがあれば、入力されたパスワードと比較されます。
使用者のエントリが無いか、
あるいは CVS の passwd ファイルが存在しない場合には、
システムが使用者の調査機構に使用するパスワードと一致するか試されます
(cofig ファイルで SystemAuth=no を設定することで、システムの使
用者調査機構を使用不能にすることができます)。
サーバはエントリの三番目の欄にある使用者の権限で実行されます。
三番目の欄が無い場合には、最初の欄にある使用者の権限が使用されます
(つまり CVS の passwd ファイルに、
システムで有効な使用者を併せて記述すれば、
架空の使用者名を使用できます)。
どちらの場合でも、
(有効な) 使用者が持たない特権は付与されません。
$CVSROOT/CVSROOT/passwd ファイルのパスワードの後にコロンとシス
テムの使用者名を追加することで、CVS 専用の使用者名をシステムの使用者名
に "マップ" することが可能です。(例えば、システムのログイン名に)。例
えば:
cvs:ULtgRLXo7NRxs:kfogel generic:1sOp854gDF3DY:spwang anyone:1sOp854gDF3DY:spwang
こうやって、次のコマンド:
cvs -d :pserver:cvs@faun.example.org:/usr/local/cvsroot checkout foo
で faun.example.org のリポジトリに遠隔接続する人は、認証に成功
すると、システムの kfogel としてサーバを実行することになります。しかし、
遠隔使用者は、 $CVSROOT/CVSROOT/passwd ファイルに CVS のみ
が使用する違ったパスワードがあるかもしれませんので、kfogel のシステム
パスワードが必ず必要なわけではありません。そして、上記の例で示されてい
るように、複数の cvs 利用者名を単一のシステムの利用者名にマップするこ
とができます。
この機能はリポジトリへの接続をシステムへの完全な接続を行うことなく (特 に、Read-only access を参照してください) 可能にするために設計さ れています。しかし、Password authentication security も参照して ください。どんな種類のリポジトリ接続でも、ある程度の総合的なシステム接 続も含んでいる可能性が高いのです。
現在、
CVS の passwd ファイルにパスワードを加えるには、
他のどこかからコピーするしか方法がありません。
いつの日か cvs passwd コマンドができることでしょう。
$CVSROOT/CVSROOT の多くのファイルと違って、passwd ファイ
ルは CVS 経由ではなく、直接編集します。
サーバに接続する前に、
使用者はコマンド cvs login を用いて
ログインする必要があります。
サーバのパスワード確認と同時に、
後のサーバとの処理のためにパスワードを保存します。
コマンド cvs login は、
使用者名, サーバのホスト名, リポジトリへのフルパス等の情報が必要で、
リポジトリの引数もしくは環境変数 CVSROOT から取得します。
cvs login は対話的です--それはパスワード入力を促します:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot login CVS password:
サーバによりパスワードが照合され、
正しければ login が成功しますが、
誤りであれば失敗して、パスワードが正しく無いと文句を言います。
一度ログインに成功すると、CVS に保存されたパスワードを 使って認証し、直接サーバに接続するようにさせられます:
cvs -d :pserver:bach@faun.example.org:/usr/local/cvsroot checkout foo
CVS がサーバに接続する際、
:pserver: が無ければ、
rsh が用いられます (see Connecting via rsh)。
従って、必ず :pserver: を付加して下さい。
(一旦作業コピーを取り出した後、
作業ディレクトリ中で CVS を実行する場合には、
もう明示的にリポジトリの指定をする必要はありません。
CVS は作業コピーのサブディレクトリ CVS に、
引数のリポジトリを記録しているためです。)
パスワードは、既定ではファイル $HOME/.cvspass に保存されます。
ファイルは人が読める書式で書かれていますが、
十分な知識無しに編集してはいけません。
パスワードは平文ではなく、
"悪気無く"見られる事 (つまり、システム管理者が偶然そのファイルを見付け、
不注意に見るといった事) を防ぐために、
簡単な符号化がなされています。
現在選ばれている遠隔リポジトリのパスワードは cvs logout コマン
ドを使用すると CVS_PASSFILE から消去できます。
環境変数 CVS_PASSFILE は、この既定値に優先します。
この変数を使用するのであれば、
cvs login を実行する前に設定しなければいけません。
cvs login を実行した後に設定した場合、
その後の CVS コマンドは、
サーバに送るパスワードを見付けられません。
パスワードは、 平文を簡単に符号化してクライアント側に保存されており、 送信の際も同じ符号化が用いられます。 この符号化は、パスワードが偶然見られること (すなわちシステム管理者が 不注意に見てしまう事) を防ぐためのもので、 素人の攻撃からパスワードの取得を防ぐことさえ出来ません。
CVS 独自のパスワードファイルにより (see Password authentication server)、 リポジトリを利用する時には、 システムにログインする時とは別のパスワードが使用できます。 しかし、一旦リポジトリが読み込み専用でない状態で利用可能になれば、 多様な方法により、サーバ上でプログラムが実行可能になります。 つまりリポジトリの利用は、 かなり広範囲にシステムが利用できる事を暗示しています。 これを防止するように CVS を修正する事は可能でしょうが、 これを書いている時点までには誰もやっていません。
$CVSROOT/CVSROOT ディレクトリには passwd と他のセキュリ
ティを調べるために使われるファイルがあるので、このディレクトリの使用許
可をを /etc と同じくらいきつくしなければならないことに注意して
ください。同じことが $CVSROOT ディレクトリそのものと、木のそれ
より上の部分のすべてのディレクトリにもあてはまります。そのようなディレ
クトリに書き込み許可のある全ての人はシステムの任意の使用者になることが
できます。これらの使用許可は普通は pserver を使っていないときに使用す
るものよりもきついものであることに注意してください。
要約すると、 パスワードを得た人物は誰でもリポジトリを利用できます (これはまたある程度通常のシステム利用も可能になるということを含むかも しれません。) ネットワークのパケットを漁ったり、 保護された (つまり所有者のみ読み込み可能な) ファイルを読むことができる、 全ての人物がパスワードを入手可能です。 あなたが本物の安全を望むのならば、ケルベロスにしましょう。
GSSAPI は ケルベロス5のようなネットワークセキュリティシステムとの一般 的なインターフェースです。動作する GSSAPI ライブラリを持っているなら、 CVS を GSSAPI で認証して、直接 TCP 接続を通して接続すること ができます。
これをするためには、CVS が GSSAPI サポート付きでコンパイルされて
いる必要があります。CVS を configure しているときに、ケルベロス
version 5 を使う GSSAPI ライブラリが存在するかどうかを発見しようとしま
す。構築するために --with-gssapi も使用できます。
接続は GSSAPI を使って認証されますが、メッセージストリームは既定では認
証されません。ストリームの認証を要求するためには、広域オプショ
ン -a を使用する必要があります。
既定状態では、データ転送は暗号化されません。
クライアントとサーバ双方を、
暗号化を有効にしてコンパイルしておく必要があります。
構築時に --enable-encryption オプションを付加して、
暗号化機能を有効にして下さい。
また暗号化を要求するために、
使用時に広域オプション -x を付加する必要があります。
GSSAPI 接続はパスワード認証サーバを扱うのと同じサーバのサーバ側で扱わ
れます。Password authentication server 参照。ケルベロスのような
強い認証を提供する GSSAPI 機構を使用しているなら、平文のパスワードによ
る認証を使用不能にしたいと思うかもしれません。そのためには、空の
CVSROOT/passwd パスワードファイルを作成して、config ファイルで
SystemAuth=no を設定します (see config)。
GSSAPI サーバは cvs/hostname の主な名前を使い、hostname は サーバーホストの正式な名前です。あなたの GSSAPI 機構で要求されているよ うにこれを設定しなければなりません。
GSSAPI を使用して接続するには、:gserver: を使用します。例えば、
以下のようになります。
cvs -d :gserver:faun.example.org:/usr/local/cvsroot checkout foo
ケルベロスを使う一番簡単な方法は Connecting via rsh で説明されて
いるようにケルベロスの rsh を使用することです。
rsh を利用する際の主な欠点は、
全てのデータが他のプログラムを経由する必要があるため、
時間がかかるかもしれない事です。
もしケルベロスが導入されているならば、
ケルベロスの認証により、直接 TCP 接続する事が可能です
この部分はケルベロスネットワークセキュリティシステム、バージョン4 に関 するものです。ケルベロス バージョン5は前節で説明されているように、 GSSAPI 一般ネットワークセキュリティインターフェースを通して使用するよ うになっています。
このためには、
ケルベロスの支援を受けるように CVS をコンパイルする必要があります。
CVS は configre 時に
ケルベロスが利用できるかどうかを検出しようとしますが、
駄目ならフラグ --with-krb4 を用いて強制させることも可能です。
既定状態では、データ転送は暗号化されません。
クライアントとサーバ双方を、
暗号化を有効にしてコンパイルしておく必要があります。
構築時に --enable-encryption オプションを付加して、
暗号化機能を有効にして下さい。
また暗号化を要求するために、
使用時に広域オプション -x を付加する必要があります。
サーバの inetd.conf を編集する必要があります。
クライアントが使用する既定のポート番号は 1999 です。
他のポートを使用したい場合には、
クライアントの環境変数 CVS_CLIENT_PORT で指定して下さい。
CVS を利用する前に、
通常の方法で切符を取得して下さい (一般的には kinit です)。
この切符でサーバへのログインが許可されるはずです。
これで準備ができました:
cvs -d :kserver:faun.example.org:/usr/local/cvsroot checkout foo
ここで接続に失敗した場合、 以前のバージョンの CVS は rsh で再接続を試みましたが、 このバージョンでは再試行されません。
この接続方法で、ローカル・ディスクのリポジトリに遠隔プロトコルを使って
接続することができます。言い換えると、それは :local: とほとんど
同じことをしますが、変な振舞いや、バグやその他のものはローカルの
CVS のものではなく、遠隔 CVS のものです。
毎日の作業では、:local: か :fork: を好むかは個人の好みに
依ります。もちろん :fork: は cvs と遠隔プロトコルをデバッ
グしているときは特に役立ちます。特に、我々は他の遠隔アクセス方法のネッ
トワーク関連の設定、変更、時間切れ設定、認証全てを避けることができ、そ
の上で遠隔プロトコルを使う接続を作成することができるのです。
fork 方法を用いて接続するためには、:fork: とローカルのリ
ポジトリへのパス名を使用します。例えば、:
cvs -d :fork:/usr/local/cvsroot checkout foo
:ext: と同様に、サーバは既定値の cvs と呼ばれるか、
CVS_SERVER 環境変数の値になります。
パスワード認証サーバを使っている人に読み込み専用リポジトリ接続を認める ことができます (see Password authenticated)。 (他の接続方法は全て リポジトリマシンへのログイン接続を仮定していて、ローカルのファイル使用 許可が認めるものは何でもできるので、読み込み使用者のための明示的な援助 はありません。)
読み込み専用接続の使用者は、特定の "管理" ファイル (ロックファイルや 履歴ファイル) を除いて、リポジトリを変更しない CVS の操作のみを実 行できます。この機能を使用者の別名付けと一緒に使うことが望ましいでしょ う (see Password authentication server)。
以前のバージョンの CVS と違って、読み込み専用使用者はリポジトリを 読むことができるだけで、サーバのプログラムを実行できないようになってい るはずです。そうしないと、予期しないレベルの接続を得ることができてしま います。もしくは、より正確に言うと、既知の穴は塞がれました。こ の機能は新しく、包括的なセキュリティ審査がなされていませんので、セキュ リティへの関心に従って、どのような程度の注意も払うべきというのは正当の ようです。
使用者に読み込み専用を指定するためには、2つ方法があります: 包含と排除 です。
"包含" は、使用者を特別に $CVSROOT/CVSROOT/readers ファイルに一
覧表示するということで、それは単純な改行で分離された利用者の一覧です。
これは readers ファイルの例です:
melissa splotnik jrandom
(最後の使用者の後の改行を忘れないでください。)
"排除" は 書き込み 接続のできる人を全て明示的に一覧表示するとい うことです--もしファイル
$CVSROOT/CVSROOT/writers
が存在すると、それに挙げられている使用者だけが書き込み接続ができ、その
他の人は読み込み専用接続になります (もちろん、読み込み専用使用者も、相
変らず CVS passwd ファイルに挙げられている必要があります。)
writers ファイル は readers ファイルと同じ書式です。
注意: CVS passwd ファイルが cvs の使用者をシステムの使用者
にマップしているときは、cvs の使用者名を使って書き込み専用接続
を拒否したり認めたりしていて、システムの使用者名を使っていないことを確
認してください。すなわち、readers と writers ファイルに
cvs の使用者名があるということで、それはシステムの使用者名と同じかもし
れませんし、違うかもしれません。
これは読み込み専用接続か読み込み書き込み接続かを認めるかに関するサーバ の振舞いの完全な説明です。
readers が存在して、この使用者がそこに挙げられていれば、読み込
み専用接続になります。もしくは、writers が存在していて、使用者
がそこに挙げられていなければ読み込み専用接続になります (readers
が存在するけれど、そこには挙げられていないというときにもそのようになり
ます)。その他の場合では、完全な読み込み書き込み接続になります。
もちろん、使用者が両方のファイルに挙げられていれば、衝突が発生します。 これはより保守的な方法で解決されます。リポジトリの保護は少なすぎるより 多すぎるほどの方が良いですので: そのような使用者は読み込み専用接続にな ります。
CVS サーバは実行中に一時ディレクトリを作成します。それは
cvs-servpid
のような名前で、pid はサーバのプロセス番号です。それらは環境変数
TMPDIR (see Environment variables)、-T 広域オプショ
ン (see Global options)、で指定されるディレクトリもしくは、それら
がないと /tmp に置かれます。
ほとんどの場合は、通常終了か異常終了かに関わらず、サーバは終了時に一時 ディレクトリを消去します。しかし、サーバが一時ディレクトリを消去できな い場合がいくつかあります。例えば:
kill -KILL)。
このような場合は、手で cvs-servpid ディレクトリを消去する
必要があります。プロセス番号 pid で動いているサーバが無ければ、
その行為は安全です。
ファイルの改名とディレクトリ間の移動はうまくできないので、 新しいプロジェクトを始めるときには、 最初にファイルの構成をよく考えておく必要があります。 ファイルの改名や移動は、 不可能ではありませんが非常にやっかいです。 特にディレクトリの改名に関して、 CVS は癖のある動作をします (see Moving files)。
次に何をするかは、始める状況に依ります。
始めの一歩は、リポジトリ中にファイルを生成することです。 これには幾つか異なる方法があります。
CVS を使い始める場合に、
おそらく CVS を使用できるプロジェクトが
既に幾つかあるでしょう。
この場合 import コマンドを使用するのが最も簡単です。
例を挙げて説明します。
CVS に組み込みたいファイルが wdir にあり、
それを $CVSROOT/yoyodyne/rdir に置きたい時、
次のようにします。
$ cd wdir $ cvs import -m "Imported sources" yoyodyne/rdir yoyo start
-m フラグでログ・メッセージを与えなかった場合、CVS により
エディタが開かれ、メッセージの入力が促されます。文字列 yoyo は
ベンダー・タグと呼ばれるものであり、
start はリリース・タグと呼ばれるもの
です。この文脈では意味をなさないかもしれませんが、CVS はそれらの
存在を要求します。詳しくは See Tracking sources.
では実際に動作したことを確かめた後、元のソースディレクトリを削除します。
$ cd .. $ mv dir dir.orig $ cvs checkout yoyodyne/dir # 下で説明 $ diff -r dir.orig yoyodyne/dir $ rm -r dir.orig
誤って CVS を通さないで編集してしまわないように、下のソースを削除 すると良いでしょう。もちろん削除する前に、ソースのバックアップを取るの が賢明です。
checkout コマンドはモジュールの名前 (以前の全ての例のように)、
または $CVSROOT からの相対パス (上の例のように) を引数に取りま
す。
CVS が $CVSROOT 中のディレクトリに設定した
使用許可とグループ属性が、
適切かどうか調べると良いでしょう。See File permissions.
取り込みたいファイルの中にバイナリ・ファイルが含まれる場合、 wrapper 機能を用いて、どのファイルがバイナリなのか 明示するとよいでしょう。See Wrappers.
RCS 等の、 他のバージョン管理システムで保守されてきたプロジェクトがあり、 そのプロジェクトのファイルを CVS に移管する場合、 各ファイルの修正履歴の維持を望むでしょう。
foo.c という名前のファイルには、
RCS/foo.c,v という RCS ファイルが対応します
(他の場所にあるかもしれませんので、
詳細は RCS の文書を調べて下さい)。
次に、CVS リポジトリに適当なディレクトリを作成して下さい。
そして CVS リポジトリの当該ディレクトリに、
ファイルをコピーして下さい
(リポジトリ中のファイル名は、
ソース・ファイルに ,v が付加されたものでなくてはならず、
またファイルは RCS サブディレクトリではなく、
当該ディレクトリに直接置いて下さい)。
この例のように、CVS コマンドを利用せず、
CVS リポジトリを直接利用するほうが適当な場合が稀にあります。
以上で作業コピーを新たに取り出す準備ができました。
RCS ファイルを CVS に移動するときに、
ロックされていてはいけません。
ロックされている場合には、CVS での操作に支障を来します。
それが駄目なら、おそらく一番良いのは他のシステムのコマンド行のインター
フェースを使って一回に一つのリビジョンを取り出し、それを CVS に格
納するスクリプトを書くことでしょう。下の sccs2rs スクリプトはそ
のために役に立つ例でしょう。
contrib ディレクトリの中に、
sccs2rcs という名前のスクリプトがあります。
これを用いて SCCS ファイルを RCS ファイルに変換できます。
注意: SCCS と RCS の両方を持つマシンで実行する必要があり、
また contrib 内の他の全てと同様に動作保証はされません
(使用者によって評価は異なるでしょう)。
contrib ディレクトリの中に、
pvcs_to_rcs という名前のスクリプトがあります。
これを用いて PVCS アーカイブを RCS ファイルに変換できます。
PVCS と RCS のあるマシンで実行する必要があり、
また contrib 内の他の全てと同様に動作保証はされません
(使用者によって評価は異なるでしょう)。
詳細はスクリプト中のコメントを読んでください。
新しいプロジェクトを始める場合、 まず次のように空のディレクトリを作ります。
$ mkdir tc $ mkdir tc/man $ mkdir tc/testing
その後 import コマンドを使って、
リポジトリに各々の (空の) ディレクトリを登録(作成)します:
$ cd tc $ cvs import -m "Created directory structure" yoyodyne/dir yoyo start
そして add コマンドで、
ファイル (と新しいディレクトリ) を加えていきます。
その時、 $CVSROOT の中のファイルの使用許可が、
正しいものかどうかを確認すると良いでしょう。
二歩目は modules ファイルにモジュールの定義をする事です。
必ずしも必要ではありませんが、
関連するファイルやディレクトリをグループ化するのに便利です。
モジュールを定義する簡単な手順を示します。
$ cvs checkout CVSROOT/modules $ cd CVSROOT
tc を定義するには次の行を加えます:
tc yoyodyne/tc
$ cvs commit -m "Added the tc module." modules
$ cd .. $ cvs release -d CVSROOT
CVS の多くの利用ではあまりリビジョン番号について心配する必要はあ
りません。CVS は 1.1, 1.2 などのような番号を割当て、
それだけが皆が知る必要のあることです。しかし、CVS がリビジョン番
号を割当てる方法に関してより知識を持ち、より制御したい人もいます。
どのリビジョンが特定のリリースになったか、などの 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 !
+-----+ +-----+ +-----+ +-----+ +-----+
2 つ以上のピリオドを含む番号になることもあります。例えば、
1.3.2.2 です。そのようなリビジョンは枝のリビジョンを表します
(see Branching and merging)。そのようなリビジョン番号は
Branching and merging で詳しく説明されています。
上の説明のように、ファイルは複数のバージョンがあります。同様に、ソフト
ウェア製品も複数のバージョンを持つことができます。ソフトウェア製品はよ
く 4.1.1 のようなバージョン番号を付けられます。
バージョンには二つの意味があり、 最初のものはこの文書でリビジョンと呼ばれるものです。 二番目はリリースと呼ばれるものです。 混乱を避けるために、 この文書ではなるべくバージョンという単語は使わないようにします。
初期設定では、CVS は最初の番号を同じにして 2番目の番号を増加させ
ることにより数字リビジョンを割当てます。例えば、1.1,
1.2, 1.3 のように。
新しいファイルを加えるときは、2番目の番号は常に 1 で、最初の番号はその
ディレクトリの中のファイルの最初の番号の一番大きいものと等しくなります。
例えば、現在のディレクトリの一番大きい番号が 1.7, 3.1,
4.12 であると、追加されたファイルの数字リビジョンは 4.1
になります。
普通はリビジョン番号を気にかける必要はありません--それを CVS が
維持している内部番号のように扱う方が簡単で、タグは製品リリース 1 とリ
リース 2 のような間を区別するより良い手段です (see Tags)。 しかし、
数字リビジョンを設定したいのであれば、cvs commit の -r
オプションですることができます。-r オプションは -f オプ
ションを暗黙に仮定しますので、ファイルが修正されていなくても格納される
ということになります。
例えば、全てのファイルをリビジョン 3.0 にするためには (変更されていな いものも含めて)、次のように実行するかもしれません:
$ cvs commit -r 3.0
-r で指定する番号は存在するリビジョン番号より大きくなければなら
ないことに注意してください。すなわち、リビジョン 3.0 が存在していると、
cvs commit -r 1.3 とはできないということです。複数のリリースを
並行して維持したいときは、枝を使う必要があります (see Branching and merging).
リビジョン番号は開発に従って徐々に増えていきますが、 ソフトウェア製品のリリース番号とは全く何の関係もありません。 CVS の使い方にもよりますが、 異なる二つのリリースにおけるリビジョン番号は異なっているでしょう。 例えば RCS 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 の二つのタグ名は、
CVS が使用するために予約されています。
将来使われる CVS にとって特別な名前は、実際のタグ名との衝突を避け
るために BASE や HEAD などのような名前ではなく、例えば
. で始まるような特別な方法で命名されることが望まれています。
タグの命名にプログラムの名前とリリースのバージョン番号のような情報に基
いた何らかの習慣を選びたいでしょう。例えば、CVS 1.9 が cvs1-9
という名前でタグ付けされるように、まずプログラムの名前を使い、その直後
にバージョン番号の . を - に変更したものを続けるかもしれ
ません。同じ習慣を続ければ、常にタグが cvs-1-9 や cvs1_9
や他のものであったかを推測する必要はなくなります。taginfo ファイルでそ
の習慣を強制することさえ考えるかもしれません (see user-defined logging).
次の例は、ファイルにタグを付ける方法を示したものです。
コマンドはあなたの作業ディレクトリで実行して下さい。
すなわち、backend.c があるディレクトリでコマンドを実行すべきで
ある、ということです。
$ cvs tag rel-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 /u/cvsroot/yoyodyne/tc/backend.c,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
rel-0-4 (revision: 1.4)
cvs tag の構文の完全なまとめと、いろいろなオプションの説明は
Invoking CVS を参照してください。
単独のファイルにタグを付けるべき理由はほとんどありません。 タグの主な使い途は、 モジュールを構成する全てのファイルに同じタグを付け、 開発の流れの重要点 (リリース時等) を示すことです。
$ cvs tag rel-1-0 . cvs tag: Tagging . T Makefile T backend.c T driver.c T frontend.c T parser.c
(CVS に対する引数にディレクトリを指定した場合は、 そのディレクトリに含まれる全てのファイルにタグが付けられます。 そのディレクトリ以下の全てのサブディレクトリに対しても (再帰的に) 動作します。See Recursive behavior.)
checkout コマンドの -r フラグに、
モジュールから取り出すリビジョンを指定します。
このフラグを用いて、
モジュール tc のリリース 1.0 を作るソースを、
将来のいつでも簡単に復元することができます:
$ cvs checkout -r rel-1-0 tc
リリース時にタグを付けるようにしておけば、 過去のリリースにバグが発見されたが最新版には無い、 という場合などに非常に便利です。
任意の時間を指定してモジュールを復元することもできます。
See checkout options. -r をこれらのコマンドのどれかに指定す
るときは、貼り付きタグに注意する必要があります。Sticky tags 参照。
複数のファイルに同じタグを付けるという事を、 「ファイル名とリビジョン番号の行列の中に線を引く」 と考えると良いでしょう。 以下のリビジョンの五つのファイルがあるとしましょう:
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
過去の何らかの時点で、
* の付けられたバージョンにタグが付けられています。
上図では * の付いたリビジョンにタグが付けられています。
仮にタグ名を「タグ付きリビジョンを結んだ紐」と考えると、
checkout の -r は
「紐を引くとタグ付きリビジョン全てが釣れる」などと解釈できるでしょう。
あるいはタグ付きリビジョンを水平に並べた方が、分り易いかも知れません:
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 (--- <--- ここを見る
1.3 1.6 1.3 \_
1.4 1.4
1.5
前の節の例は、どのリビジョンにタグを付けるかを選ぶ一番普通の方法を表し
ています。つまり、引数無しの cvs tag コマンドでは、CVS は
現在の作業ディレクトリに取り出されたリビジョンを選択します。例えば、作
業ディレクトリの backend.c がリビジョン1.4から取り出されたので
あれば、CVS はリビジョン1.4にタグを付けます。タグはリポジトリのリ
ビジョン1.4にすぐに適用されることに注意してくさい。タグ付けはファイル
の修正とは違いますし、まず作業ディレクトリを修正してそれから cvs
commit を実行して修正をリポジトリに送信するような他の操作とも違います。
cvs tag がリポジトリに作用するという事実による、もしかすると驚
くかもしれない側面に、格納されたリビジョンにタグを付けていて、それは作
業ディレクトリにあるローカルで修正されているファイルと違うかもしれない、
というものがあります。間違ってそうしてしまわないようにするには、
cvs tag に -c オプションを指定します。もしローカルで修正
されたファイルがあれば、CVS はファイルをタグ付けする前にエラーを
出し、異常終了します:
$ cvs tag -c rel-0-4 cvs tag: backend.c is locally modified cvs [tag aborted]: correct the above errors first!
cvs rtag コマンドは特定の日付や時間のリポジトリにタグを付けます
(もしくは最新のリビジョンにタグを付けることに使うことができます)。
rtag はリポジトリの内容に直接作用します (コマンドの前に取り出す
ことを要求しませんし、作業ディレクトリを見に行きません)。
以下のオプションはタグを付ける日付やリビジョンを指定します。完全な説明 は Common options 参照。
-D date
-f
-D date や -r tag と一緒のときにだけ役に立ち
ます。合致するリビジョンが見つからなければ、(ファイルを無視する代わり
に) 一番新しいリビジョンを使います。
-r tag
cvs tag コマンドは同じ -r, -D, -f オプショ
ンを使って、ファイルをリビジョンや日付により指定することもできるように
なっています。しかし、この機能はおそらくあなたが望むものではないでしょ
う。その理由は、cvs tag は与えられたタグ/日付ではなく、存在する
作業ディレクトリに基づいてタグを付けるファイルを選ぶからです。ですから、
普通は cvs rtag を使う方がうまくいくでしょう。例外はこのような
場合です:
cvs tag -r 1.4 backend.c
普通はタグを修正しません。それはリポジトリの履歴を記録するために存在し ており、削除したり意味を変えたりすることは、普通は望むことではないでしょ う。
しかし、一時的にタグを使用したり、偶然に間違った場所に付けてしまったり する場合もあるでしょう。ですから、タグを削除、移動、改名するかもしれま せん。警告: この節のコマンドは危険です。それは履歴情報を永遠に捨て去り、 エラーからの復帰が難しくなるか、不可能になります。あなたが CVS の 管理者なら、これらのコマンドを taginfo で制限することを考えるかもしれ ません (see user-defined logging)。
タグを削除するには、-d オプションを cvs tag か
rtag に指定します。例えば:
cvs rtag -d rel-0-4 tc
はモジュール tc からタグ rel-0-4 を削除します。
移動 とは、同じ名前を違うリビジョンを指すようにすることです。例
えば、stable タグは現時点で backend.c のリビジョン1.4を
指しており、おそらくそれをリビジョン1.6を指すようにしたいと思っている
かもしれません。タグを移動するには、-F オプションを cvs
tag かcvs rtag に指定します。例えば、今書いた作業は以下のもの
で達成できます:
cvs tag -r 1.6 -F stable backend.c
タグの 改名 とは、違った名前を古いタグと同じリビジョンを指すよう
にすることです。例えば、タグ名の綴りを間違えて、修正したいと思っている
かもしれません (できれば他の人が古い綴りに頼る前に)。タグを改名するた
めには、まず -r オプションを cvs rtag に与えて新しいタグ
を作り、それから古い名前を削除します。これは新しいタグを古いタグと全く
同じファイルにつけることになります。例えば:
cvs rtag -r old-name-0-4 rel-0-4 tc cvs rtag -d old-name-0-4 tc
タグ付けがどのようにファイルの追加と削除と関連して動作するかの正確な議 題は少し複雑です。たいていの場合、CVS はファイルが存在したかどう かをたいして苦労することなく追い掛けることができます。既定では、タグは タグ付けされたリビジョンに対応するファイルだけに適用されます。ファイル がまだ存在していないか、既に削除されていると、単にタグを省略し、 CVS はタグが無いものは、そのタグではファイルが存在しないという意 味に扱うことを知っています。
ところが、これは少し情報を失います。例えば、ファイルが追加されて、それ
から削除されたとしましょう。そして、タグがそのファイルになければ、その
タグがファイルの追加前のときか、削除の後かどちらを参照するかを知る方法
はありません。-r オプションを cvs rtag に指定すれば、
CVS は削除されたファイルにタグを付け、この問題を回避することがで
きます。例えば、先頭のリビジョンにタグを付けるために -r HEAD を
指定するかもしれません。
ファイルの追加と削除という題に関して、cvs rtag コマンドには他の
方法ではタグ付けされない、削除されたファイルのタグを消去する -a
オプションがあります。例えば、タグを移動しているときに -F と共
に指定するでしょう。-a 無しでタグを移動すれば、削除されたファイ
ルはファイルが削除されたという事実を反映せずに、まだ古いリビジョンを参
照しているでしょう。私は上に書いてあるように -r が指定されてい
るときはこれは必要ではないと思います。
作業コピーのリビジョンには関連した追加のデータがあることがあります。例
えば、枝であったり (see Branching and merging)、checkout -D
か update -D によって特定の日時より前のバージョンに制限されてい
るかもしれません。このデータは永続しますので - すなわち、作業コピーの
残りのコマンドに適用されます - 我々はそれを 貼り付けられた と表
現しました。
たいていの場合、貼り付きは考える必要のない CVS の隠れた側面です。 しかし、この機能を使いたくないとしても、貼り付けられたタグに関して 何か 知る必要があるかもしれません (例えば、それを避ける方法!).
貼り付いたタグ (sticky tag) や日付を調べるには、
status コマンドを使用します:
$ cvs status 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 /u/cvsroot/yoyodyne/tc/driver.c,v
Sticky Tag: rel-1-0-patches (branch: 1.7.2)
Sticky Date: (none)
Sticky Options: (none)
作業ファイルに貼り付いたタグは、
cvs update -A を使って削除するまで残ります。
オプション -A は、ファイルを幹の先頭のバージョンに戻し、
貼り付いたタグ, 日付, オプションを全て剥します。
貼り付けられたタグの一番普通の使用法は、Accessing branches で説
明されているようにどの枝で作業しているかを確認することです。しかし、枝
でない貼り付きタグにも利用法はあります。
ここでは、他人の変更が安定しているかどうか分らないので、
作業ディレクトリを更新したくない場合を例に挙げて考えます。
もちろんこの場合、cvs update の実行を控えれば済みます。
しかし、更新したくないのが大きなツリー構造の一部分だけならば、
そこにリビジョンを貼り付ければ良いのです。
ソースを取り出す際に (1.4 などと) リビジョンを指定すれば、
そのリビジョンを貼り付けることができます。
以後、cvs update -A によってタグを剥がすまで、
cvs update を実行しても
最新リビジョンに更新されることはありません。
同様にオプション -D を update や checkout に使うと、
貼り付いた日付 (sticky date) が設定され、
これ以降のコマンドにその日付が与えられます。
古いバージョンのファイルを取り出す際に、
タグを貼り付けたくない場合も多いと思います。
checkout や update にオプション -p を付けると、
ファイルの内容が標準出力に送られるので、これを利用します。
例えば:
$ cvs update -p -r 1.1 file1 >file1 =================================================================== Checking out file1 RCS: /tmp/cvs-sanity/cvsroot/first-dir/Attic/file1,v VERS: 1.1 *************** $
しかし、あなたの尋ねていることが前の格納に戻す (この例では、
file1 をリビジョン1.1であったときに戻す) 方法なら、これが一番簡
単な方法ではありません。その場合は update -j オプションを
update に付けるのが良いでしょう。さらなる議論は、Merging two revisions 参照。
CVS では変更を 枝 (branch) として知られる別の開発ラインに 分けることができます。枝のファイルを変更しても、その変更は幹や他の枝に は現れません。
後程、マージ (merging) によって変更をある枝から別の枝 (も
しくは幹) に移動することができます。マージはまず cvs update -j
を実行して、変更を作業ディレクトリに混ぜることから始まります。それから
そのリビジョンを格納することができ、こうして効果的に変更を別の枝にコピー
することができます。
tc のリリース 1.0 ができたとしましょう。tc の開発を継続していて、数ヶ 月の間にリリース 1.1 を作成する計画を立てています。しばらくして、顧客 が致命的なバグについて文句を言ってくるようになりました。リリース 1.0を 取り出し (see Tags)、バグを見つけました (結局些細な修正に終わりま した)。しかし、ソースの現在のリビジョンは流動的で、少くとも1ヶ月は安定 しない状態です。最新のソースに基づくバグ修正リリースはとても作成できま せん。
この様な状況でするべきことは tc のリリース 1.0 の全てのファイルのリビ ジョンツリーに基づく 枝 (branch) を作成することです。そう すれば幹の邪魔をすることなく枝に修正を加えることができます。修正が終わっ たときに、幹に取り込むか、枝に残しておくかを選択することができます。
tag -b で枝を作成することができます。例えば、作業コピーのところ
にいるとしましょう:
$ cvs tag -b rel-1-0-patches
これは作業コピーの現在のリビジョンに基づいた枝を別に作成し、その枝に名
前 rel-1-0-patches を割当てます。
枝はリポジトリに作成されているのであって、作業コピーに作成されているの ではないということを理解することは重要です。上記の例の様に、現在のリビ ジョンに基づいた枝を作成することは、自動的に作業コピーを新しい枝に切り 換えることは しません。それをする方法に関する情報は Accessing branches を参照してください。
rtag を使って、作業コピーへの参照無しに枝を作ることもできます:
$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc
-r rel-1-0 はこの枝がタグ rel-1-0 に対応するリビジョンを
根とするということを指定します。最新のリビジョンである必要はありません
- 古いリビジョンから枝を生やすことが役に立つことがしばしばあります
(例えば、他の部分は安定していることが知られている過去のリリースのバグ
を修正するとき)。
tag と同様に -b フラグは rtag に枝を作成するよう
に指示します (単なるリビジョン名ではなく)。rel-1-0 に対応する数
字リビジョン番号はファイル毎に違うことを注意してください。
ですから、命令の完全な効果は新しい枝を作成することです - モジュール
tc で、rel-1-0 でタグ付けされたリビジョンツリーを根元と
する - rel-1-0-patches という名前のものを。
2 つの方法のどちらかで枝を取得することができます: リポジトリから新しく 取り出すか、存在する作業コピーをその枝に切り換える方法です。
リポジトリから枝を取り出すには checkout をフラグ -r と、
その後に枝のタグ名を続けて起動します (see Creating a branch)。
$ cvs checkout -r rel-1-0-patches tc
もしくは、既に作業コピーを持っていれば、update -r で任意の枝に
切り換えることができます:
$ cvs update -r rel-1-0-patches tc
もしくは、それと等価な:
$ cd tc $ cvs update -r rel-1-0-patches
作業コピーが元々幹にあったか他の枝にあったかは関係ありません - 上のコ
マンドはそれを指定された名前の枝に切り換えます。普通の update
コマンドと同様に、update -r は全ての変更をマージし、衝突がどこ
で起こったかを知らせます。
一度特定の枝に結び付けられた作業コピーを手に入れると、指示しない限りそ こに残り続けます。これは、作業コピーから格納された変更はその枝に新しい リビジョンを加えますが、幹と他の枝には影響を及ぼさないということです。
作業コピーがどの枝であるかを知るために、コマンド status を使う
ことができます。その出力で、Sticky tag という名前の場所を探して
ください (see Sticky tags) - それは現在の作業ファイルに、もし枝が
あれば、それを教える CVS の方法です:
$ 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 /u/cvsroot/yoyodyne/tc/driver.c,v
Sticky Tag: rel-1-0-patches (branch: 1.7.2)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
rel-1-0-patches (branch: 1.7.2)
rel-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 /u/cvsroot/yoyodyne/tc/backend.c,v
Sticky Tag: rel-1-0-patches (branch: 1.4.2)
Sticky Date: (none)
Sticky Options: (none)
Existing Tags:
rel-1-0-patches (branch: 1.4.2)
rel-1-0 (revision: 1.4)
rel-0-4 (revision: 1.4)
それぞれのファイルの枝番号が違うという事実に混乱しないでください
(それぞれ 1.7.1 と 1.4.2 です)。枝タグは同じ
rel-1-0-patches で、ファイルは実際に同じ枝にあります。番号は単
に枝が作られたときのそれぞれのファイルのリビジョン履歴を反映しています。
上の例では、この枝が作成される前に、driver.c が
backend.c よりも多くの変更が成されたということを導き出すことが
できます。
枝番号が作成される方法の詳細は Branches and revisions を参照して ください。
普通はファイルのリビジョン履歴は線形増加です (see Revision numbers):
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !
+-----+ +-----+ +-----+ +-----+ +-----+
しかし、CVS は線形の開発に限られているわけではありません。リ ビジョン・ツリー は 枝 に分割することができ、それぞれの枝は別に 維持された開発ラインです。枝になされた変更は簡単に幹に戻すことができま す。
それぞれの枝には 枝番号 があり、ピリオドで分けられた奇数個の10進 整数から成ります。枝番号は枝が分岐した元の枝に対応するリビジョン番号に 整数を追加することによって作成されます。枝番号により、特定のリビジョン から 1 つ以上の枝を枝分かれすることができます。
枝の全てのリビジョンは枝番号に普通の数字を追加することで形成されます。 下図に、前述の例から枝が発展した例を示します。
+-------------+
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.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 という番号になるでしょう。零で終わる全ての枝番号 (6.4.0 のように) は CVS の内部で使用されます (see Magic branch numbers)。枝 1.1.1 は特別な意味を持ちます。See Tracking sources.
この部分は 魔法の枝 (magic brandh) と呼ばれる CVS の 機能を説明します。たいていの目的のためには魔法の枝を心配する必要はあり ません。CVS が代わりに扱ってくれます。しかし、特定の状況ではそれ が見えていることもありますので、いくらか動作の仕方を知っていると役に立 つかもしれません。
表面的には、枝番号はドットで分けられた奇数個の10進の整数です。 See Revision numbers. しかし、これは真実の姿ではありません。 CVS は能率のために、余分な 0 を右から2番目の位置に挿入することが あります(1.2.3 は 1.2.0.3 となり、8.9.10.11.12 は 8.9.10.11.0.12 にな ります)。
この魔法の枝と呼ばれるものを、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つ以上のリビジョンが、 既に枝に格納されている必要があります。 タグに間違った番号を設定しないように、注意しなくてはいけません。 (実行以前にタグがどう設定されていたかを調べる方法はありません)。
update コマンドに -j branch フラグを付けると、
枝に加えられた変更を作業コピーに反映することができます。
-j branch オプションが1つだけだと、
枝の分岐点と枝の最新リビジョン間の違いを
(あなたの作業コピーに) マージします。
-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 Conflicts example.
もしソースファイルにキーワードがあれば (see Keyword substitution), 本当に必要なものよりも余分に衝突を得るかもしれません。これを回避する方 法は Merging and keywords を参照してください。
checkout コマンドでもフラグ -j branch を使用できます。
以下の様にして上記と同じ効果を得ることができます:
$ cvs checkout -j R1fix mod $ cvs commit -m "Included R1fix"
前節の例を続けると、 現在のリビジョン・ツリーは次の様になっています:
+-----+ +-----+ +-----+ +-----+ +-----+
! 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 オプションで二つのリビジョンを指定します。
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
update (と checkout) コマンドに -j revision
フラグを二つ付けることで、任意の二つのリビジョン間の違いをあなたの作業
コピーに加えることができます。
$ cvs update -j 1.5 -j 1.3 backend.c
このようにするとリビジョン 1.3 と 1.5 間の変更を 全て元に戻すことになります。 リビジョンを指定する順序に十分注意して下さい!
複数のファイルに対してこのオプションを指定する場合は、 ファイルごとにリビジョン番号が全く異なるであろうことを思い出して下さい。 複数のファイルを操作する場合には、 リビジョン番号ではなく、 必ずタグ名を用いるようにして下さい。
2つ -j オプションを指定すると、追加や削除を元に戻すこともできま
す。例えば、リビジョン1.1として存在していた file1 という名前の
ファイルがあり、それを消去した (つまり、死んだリビジョン1.2を追加しま
した) としましょう。今、またそれを以前と同じ内容で追加したいと思ったと
しましょう。これがそれをする方法です:
$ cvs update -j 1.2 -j 1.1 file1 U file1 $ 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 $
マージする変更点に、ファイルの削除や追加が伴なう場合でも、
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
これらのコマンドが実行され、cvs commit がなされた後、幹ではファ
イル a は削除され、ファイルd は追加されます
キーワードを含むファイルをマージすると (see Keyword substitution、 通常マージの間に数多くの衝突が起こります。なぜなら、キーワードはマージ 中のリビジョンで違う様に展開されているからです。
ですから、しばしばマージのコマンド行で -kk (see Substitution modes) スイッチを指定したいと思うでしょう。キーワードの展開された値を
展開するのでは無く、キーワードの名前だけを置換することによって、このオ
プションはマージしているリビジョンがそれぞれ同じことを確実にして、見せ
かけの衝突を回避します。
例えば、このようなファイルがあるとしましょう:
+---------+
_! 1.1.2.1 ! <- br1
/ +---------+
/
/
+-----+ +-----+
! 1.1 !----! 1.2 !
+-----+ +-----+
そして、作業ディレクトリは現在幹 (revision 1.2) にあります。そうすると、 以下の結果をマージから得るでしょう:
$ cat file1 key $Revision: 1.2 $ . . . $ cvs update -j br1 U file1 RCS file: /cvsroot/first-dir/file1,v retrieving revision 1.1 retrieving revision 1.1.2.1 Merging differences between 1.1 and 1.1.2.1 into file1 rcsmerge: warning: conflicts during merge $ cat file1 <<<<<<< file1 key $Revision: 1.2 $ ======= key $Revision: 1.1.2.1 $ >>>>>>> 1.1.2.1 . . .
これで起こったことは、merge が 1.1 と 1.1.2.1 間の差分を作業ディレクト
リにマージしようとした、ということです。キーワードはRevision:
1.1 から Revision: 1.1.2.1 へと変わっているので、CVS はそ
の変更を作業ディレクトリにマージしようとして、それは作業ディレクトリが
Revision: 1.2 を含んでいた、という事実と衝突をしました。
これは -kk を使用したときにに起こることです:
$ cat file1 key $Revision: 1.2 $ . . . $ cvs update -kk -j br1 U file1 RCS file: /cvsroot/first-dir/file1,v retrieving revision 1.1 retrieving revision 1.1.2.1 Merging differences between 1.1 and 1.1.2.1 into file1 $ cat file1 key $Revision$ . . .
ここでは、リビジョン 1.1 とリビジョン 1.1.2.1 の両方ともが
Revision に展開され、それらの変更を作業コピーにマージすることは
何も変更しません。ですから、衝突は起こりません。
しかしながら、マージで -kk を使うことには一つ大きな注意がありま
す。つまり、それは普通は CVS が使っていたであろうキーワード展開の
様式を上書きします。特に、これは、バイナリファイルのために様式が
-kb であったときに問題になります。ですので、リポジトリにバイナ
リファイルがあるときは、-kk を使用するよりは、衝突に対処する必
要があるでしょう。
ほとんど全ての CVS のコマンドは、 ディレクトリを引数に取ったときに再帰的に動作します。 例えば、次のディレクトリ構造を考えます。
$HOME
|
+--tc
| |
+--CVS
| (内部 CVS ファイル)
+--Makefile
+--backend.c
+--driver.c
+--frontend.c
+--parser.c
+--man
| |
| +--CVS
| | (内部 CVS ファイル)
| +--tc.1
|
+--testing
|
+--CVS
| (内部 CVS ファイル)
+--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
の既定引数です。これは update コマンドだけではなく、たいていの
CVS のコマンドにも当てはまります。
-l オプションを付けることによって、
CVS の再帰的な動作を抑止することができます。
逆に、-R オプションは ~/.cvsrc で -l が指定されて
いるときに再帰的動作を強制するために使うことができます
(see ~/.cvsrc)。
$ cvs update -l # サブディレクトリのファイルは更新しない。
プロジェクトの最中では、よく新しいファイルを追加します。削除や改名、も しくはディレクトリも同様です。心に留めておく総合的な概念は、元に戻せな い変更をする代わりに、存在するファイルの修正のように、CVS に変更 が発生したという事実を記録させたい、ということです。CVS でこれを する厳密な機構は状況に依り異ります。
ディレクトリにファイルを加える手順を説明します。
cvs add filename を用いて、
バージョン管理に加えたいファイルを CVS に伝えます。
ファイルがバイナリ・データを含んでいる場合には、
-kb を指定して下さい (see Binary files)。
cvs commit filename を用いて、
実際にリポジトリにファイルを格納します。
この手順を行なうまでは、他の開発者はファイルを見ることができません。
add コマンドは、
新しいディレクトリを加える場合にも使用します。
他のほとんどのコマンドと異なり、
add コマンドは再帰的に動作しません。
cvs add foo/bar とタイプすることさえできません。
代りに、
次のようにする必要があります。
$ cd foo $ cvs add bar
cvs add [-k kflag] [-m message] files ...
|
コマンド |
|
files が加えられた事をリポジトリに伝えます。
内容を オプション
|
例えば、以下のコマンドでファイル backend.c が
リポジトリに加えられます:
$ cvs add backend.c $ cvs commit -m "Early version. Not yet compilable." backend.c
加えたファイルは、作業中の枝だけに加えられます (see Branching and merging)。 他の枝にも加えたい場合は、後でマージすることができます (see Merging adds and removals)。
ディレクトリは変わります。 新しいファイルが加えられ、古いファイルが削除されます。 しかし、モジュールの古いバージョンの、 正確なコピーを復元できるようにしておきたいと思うでしょう。
ここでは、モジュールからファイルを削除した後も、 古いバージョンの復元を可能にする手順を説明します:
status や update といった
コマンドを使用しても確認できます。
修正を格納せずにファイルを消した場合、
当然ですが以前の状態に復元することはできません。
rm などを使っても良いでしょう。
cvs remove filename を使います。
cvs commit filename を使います。
ファイルの削除を格納する場合、CVS は、
ファイルがもう無いという事実を記録します。
ファイルが他の枝に存在していても良いし、
後で別のファイルを同じ名前で加えても構いません。
checkout や update に指定する
オプション -r や -D に応じて、
CVS が正しくファイルを作成したり、しなかったりします。
| cvs remove [options] files ... | コマンド |
|
ファイルが削除された事実をリポジトリに伝えます (作業ディレクトリから未削除のファイルは処理されません)。 このコマンドを実行しても、リポジトリのファイルは、 削除が格納されるまで実際には削除されません。 オプションの完全な一覧は Invoking CVS を参照してください。 |
以下に、幾つかファイルを削除する例を挙げます:
$ 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 .
利便性のために、-f オプションを指定することでファイルの削除と
cvs remove を一度に行うことができます。例えば、上の例はこのよう
にすることもできます:
$ cd test $ cvs remove -f *.c 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 .
ファイルに remove を実行したけれど、
格納前に気が変わったのなら、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 Branching and merging)。 他の枝からも削除したい場合は、後でマージすることができます (see Merging adds and removals)。
概念上では、ディレクトリの削除はファイルの削除と似ています--現在の作 業ディレクトリからそのディレクトリを消したいけれど、ディレクトリが存在 した古いリリースも取得できるようにしたい、と思うでしょう。
ディレクトリを削除する方法は、その中の全てのファイルを削除することです。
ディレクトリ自身は削除しません。そうする方法はありません。代わりに、
cvs update, cvs checkout, cvs export に -P
オプションを指定して、作業ディレクトリから空のディレクトリを削除するよ
うにします。おそらく最良の方法は常に -P を指定することです。空
のディレクトリが欲しければ、削除されないように、ダミーファイルを作って
ください (例えば、 .keepme)。
checkout と export の -r と -D のオプショ
ンでは -P が暗黙に含まれていることに注意してください。この方法
により CVS は正しくディレクトリを作ることができ、又、取り出した特
定のバージョンのそのディレクトリにファイルがあるかどうかに左右されなく
なります。
ファイルを他のディレクトリに移動したり、改名したりするのは、 難しくはありません。 しかし、難解な方法でこれを実現するものがあります。 (ディレクトリの移動と改名は、 より困難です。See Moving directories.)。
以降の例では、 old というファイルを new に改名します。
ファイルを移動する通常の方法は、 old を new にコピーして、 普通の CVS コマンドで old をリポジトリから削除し、 new を加えることです。
$ mv old new $ cvs remove old $ cvs add new $ cvs commit -m "Renamed old to new" old new
これがファイルを移動する最も単純な方法であり、
間違いがなく、この操作の履歴も記録されます。
このファイルの履歴を利用する際、
古い名前か、新しい名前のどちらかを指定して、
履歴のどの部分が欲しいのか知らせなくてはいけません。
例えば、cvs log old を実行しても、
改名が行なわれた時までのログ情報しか得られません。
new が格納される場合には、
リビジョン番号は普通は 1.1 から再び始まります。
それが嫌ならば、格納時にオプション -r rev
を用いると良いでしょう。詳しい情報は Assigning revisions を参照
してください。
この方法は、リポジトリ中のファイルの移動を含むため、 さらに危険です。 この節を全部読んでから実行して下さい。
$ cd $CVSROOT/dir $ mv old,v new,v
利点:
欠点:
この方法も、リポジトリ中のファイルの移動を含みます。 欠点が無い訳ではありませんが、安全です。
# リポジトリ中の RCS ファイルをコピーする $ cd $CVSROOT/dir $ cp old,v new,v # 以前のファイルを削除する $ cd ~/dir $ 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 ...
タグを削除することで、 以前のリビジョンを復元することができます。
利点:
-Ddate を使わないで、
-rtag を使う限り、以前のリビジョンのファイルを正しく復元
できる。
欠点:
ディレクトリの改名と移動の普通の方法は Outside で説明されている
ようにその中のそれぞれのファイルを改名もしくは移動することです。それか
ら Removing directories に説明されているように -P オプショ
ンを付けて取り出します。
本当にリポジトリの中身を変更してディレクトリを改名したり削除したければ、 次のようにしてください:
$ cd $CVSROOT/parent-dir $ mv old-dir new-dir
誰かが作業コピーを消さずに持っていた場合、 彼がリポジトリから消されたディレクトリを削除するまで、 彼の発行する CVS コマンドは無視されます。
ディレクトリを移動させるよりは、 ディレクトリ中のファイルを移動させる方を推奨します。 ディレクトリを移動させれば、 ディレクトリ名に依存している古いリリースを正確に復元する事は、 ほとんど不可能になります。
何時、誰が、どのように、どのファイルを変更したか、 といったバージョン管理の履歴を CVS を使って保存してきたならば、 様々な機構を用いてこの履歴を調べることができます。
ファイルを格納する時には、必ずログ・メッセージを記述します。
各リビジョンの格納時に記述されたログ・メッセージを調べる場合、
cvs log コマンドを使用します (see log)。
様々な CVS の実行履歴を記録するために、
ファイル history が使用できます (see history file)。
ファイル history の情報を検索するには、
cvs history コマンドを使用して下さい (see history)。
CVS を用いた様々な作業の履歴は、
利用者自身が選択する方法で記録されます。
CVS は、様々な場面でスクリプトを実行し、
この機構を実現します。
これらのスクリプトには、
ログ・ファイルに情報を追記したり、
開発者グループにメールを送ったり、
特定のニュース・グループに記事を投稿したりするものがあります。
格納時のログ方法は loginfo で設定します(see loginfo)。
commit, checkout, export, tag
等を実行した時のログ方法は、
各々オプション -i, -o, -e, -t を用いて、
modules ファイルに設定できます。
これらのスクリプトほどのものは必要としない使用者にも、
cvs watch add コマンドを使用して、
様々な告知をする弾力的な方法を提供します(see Getting Notified)。
この方法は cvs watch on を使用していない場合でも利用できます。
誰かが tag か rtag コマンドを実行した時に
実行されるプログラムを、taginfo ファイルに設定します。
管理用ファイルの標準書式に従い(see Administrative files)、
taginfo の各行には、
正規表現に続いて実行されるコマンドが記述されます。
コマンドに渡される引数を順に挙げると、
タグ名, 操作(tag なら add,
tag -F なら mov, tag -d なら del),
リポジトリ, 残りは全て ファイル名 と リビジョン の組
です。
フィルタ・プログラムが非零で終了した場合は、
タグ処理が中止されます。
これは taginfo を使って tag と rtag コマンドのログを取る例です。 taginfo ファイルには以下のものを入れます:
ALL /usr/local/cvsroot/CVSROOT/loggit
/usr/local/cvsroot/CVSROOT/loggit は以下のスクリプトになってい
ます:
#!/bin/sh echo "$@" >>/home/kingdon/cvsroot/CVSROOT/taglog
cvs annotate [-flR] [-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 ファイル |
cvs annotate へのオプションは Invoking CVS で一覧にされて
ていて、annotate するファイルとリビジョンを選択するために使うことがで
きます。オプションは Common options でより詳しく説明されています。
最も普通の CVS の使用はテキスト・ファイルの保管です。テキスト・ファ イルでは、CVS はリビジョンをマージしたり、リビジョン間の違いを人 間が読める形式で表示したり、他の似たような操作をすることができます。し かし、これらの中のいくつかの機能を諦めることで、CVS はバイナリ・ ファイルも保管することができます。例えば、テキスト・ファイルとバイナリ 画像の両方からなるウェブサイトを CVS で保管するかもしれません。
普段作業するファイルがバイナリであれば、バイナリ・ファイルを管理する必 要は明らかですが、それをバージョン管理に入れることは追加の問題を発生さ せます。
バージョン管理の基本機能の一つは2つのリビジョンの違いを示すことです。
例えば、別の誰かが新しいバージョンのファイルを格納すれば、何を変更して
いて、変更が良いかどうかを決定したいと思うかもしれません。テキスト・ファ
イルには、CVS は cvs diff コマンドでこの機能を提供します。
バイナリ・ファイルには、2つのリビジョンを取り出して、CVS の外部に
あるプログラムで比較することができるでしょう (例えば、ワープロにはよく
そのような機能があります)。もしそのようなツールがなければ、人に良いロ
グメッセージを書くことを強制するなどの他の機構を通じて変更を追跡し、実
際にした変更が本当にそうしたいと思っている変更そのものであることを期待
しなければなりません。
バージョン管理システムの他の機能は2つのリビジョンをマージする機能です。
CVS ではこれは2つの文脈で発生します。1つめは使用者が分離された作
業ディレクトリで変更をしたときです (see Multiple developers)。2つ
目は update -j コマンドで明示的にマージしたときです
(see Branching and merging)。
テキスト・ファイルの場合は、CVS は独立になされた変更をマージでき、 変更が衝突した場合は衝突を報せることができます。バイナリ・ファイルでは、 CVS にできることは、せいぜい2つの違ったファイルのコピーを出して、 使用者に衝突を解消するようにすることくらいです。使用者はどちらかのコピー を選ぶかもしれませんし、特定のファイル形式を知っている外部マージツール があればそれを実行するかもしれません。使用者にマージをさせることは、主 に使用者が偶然いくつかの変更を省略してしまわない、ということに依存して おり、エラーが発生する可能性が高いということに注意してください。
この過程が望ましくないなら、最良の選択はマージを避けることでしょう。別 の作業ディレクトリによるマージを避けるためには、Multiple developers の独占取得 (ファイル占有) の議論を参照してください。枝によ るマージを避けるためには、枝の使用を制限してください。
CVS でバイナリ・ファイルを保管する際の問題点が二つあります。 一つ目は、CVS がファイルを取り出す際に、 リポジトリで標準的に使用する行末形式 (ラインフィードのみ) を、 クライアント側のオペレーティングシステムに適した形式に変換する事です (例えば Windows NT だと、キャリッジリターンの後にラインフィードとなり ます)。
二つ目の問題点は、キーワードと同じデータが 偶然バイナリ・ファイルに含まれる可能性がある事です (see Keyword substitution)。 そのためキーワード展開を無効にする必要があります。
幾つかの CVS コマンドで -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 # For non-unix systems: # Copy in a good copy of the file from outside CVS $ cvs commit -m "make it binary" kotest
ファイル kotest を格納した時はファイルはバイナリ・ファイルとし
ては保存されません。というのは、バイナリ・ファイルとしては格納しなかっ
たからです。
cvs admin -kb コマンドでファイルの置換モードを設定しますが、
既にある作業コピーは変更してくれません。
行末を適切に処理する必要がある場合 (CVS のクライアントとして
unix 以外のシステムを使用している場合) は、
上記の例に示した cvs commit コマンドのように、
新たにファイルのコピーを格納する必要があります。
Unix では、cvs update -A で十分です。
ここで、cvs admin -k を用いて置換モードを変更しても、
この置換モードはバージョン管理されないことを認識しておいて下さい。
これは例えば古いリリースにテキスト・ファイルがあり、
新しいリリースに同じ名前のバイナリ・ファイルがあった場合、
バージョンによってテキストとバイナリを区別して取り出す方法を、
CVS が備えていないことを意味しています。
この問題を解決する方法は今のところありません。
cvs add や cvs import を実行する際、
既定でバイナリとして扱うかどうかを、
ファイルの名前によって判断するように設定もできます。
例えば、ファイル名が .exe で終わるファイルを
バイナリと判断するように設定できます。See Wrappers.
現時点では内容に応じてファイルがバイナリかどうかを調べる方法はありませ
ん。そのような機能を設計する主な困難は、バイナリとそうでないファイルの
区別をする方法が明らかでなく、適用する規則がオペレーティングシステムに
応じてかなり異なるであろうということです。
複数の人間でソフトウェア開発を行なうと、色々面倒が起こります。
例えば二人の人物が、
同じファイルを同時に編集しようとすることがよくあります。
解決策の一つは、
ファイル占有 (file locking) または 独占取得
(reserved checkouts) と呼ばれるもので、
同時にファイルを編集できる人数を一人に制限するものです。
RCS や SCCS 等の履歴管理システムでは、
これが唯一の方法です。
現時点では CVS で独占取得をする普通の方法は cvs admin -l
コマンドです (see admin options)。これは後述する監視機能のように
CVS によく実装されてはいませんが、独占取得を必要なほとんどの人は
十分だと思うでしょう。
また後述する監視機構を適切な手順を踏んで用いることでも (ソフトウェアか
らは強制されません)、同時編集を避けることが可能でしょう。
CVS の既定モデルは無条件取得 (unreserved checkouts) と呼ばれるものです。 このモデルでは、 開発者がそれぞれ自分の 作業コピー (working copy) のファイルを同時に編集できます。 最初に変更を格納した人物は、 他の人物が編集を始めたことが自動的には分りません。 二番目の人物が格納する時にはエラー表示を受けますから、 CVS コマンドを用いて、 自分の作業コピーをリポジトリのリビジョンの最新のものにする 必要があります。 この手順はほぼ自動化されています。
CVS は、独占取得がするような規則を強制することなく、 種々の意志疎通を容易にする仕組みを用意しています。
この章の残りでは、色々なモデルの動作方法と、 各モデルの選択に伴なう問題点について述べます。
取り出した後にあなたが加えた操作や、
他の人物がリポジトリに加えた操作によって、
ファイルを幾つかの状態に分類します。
status コマンドによって報告される状態を以下に挙げます:
add コマンドによりファイルを加えたが、
まだその内容を格納してないことを示します。
remove コマンドによりファイルを削除したが、
まだその変更を格納してないことを示します。
checkout ではなく、
update を使用するのが普通です。
update コマンドの結果、
変更点の衝突が発見されたことを示します。
衝突を解消する方法は Conflicts example 参照。
add を実行していない場合などです。
status は、ファイル状態を分類する際の補助として、
作業中のファイルの由来となるリビジョン
を示す Working revision と、
使用中の枝のリポジトリにおける最新リビジョン
を示す Repository revision とも報告します。
status コマンドのオプションについての情報は、Invoking CVS
参照。
Sticky tag と Sticky date についての
情報は、Sticky tags 参照。
Sticky options の情報は、update options
の -k オプションを参照して下さい。
status と update コマンドは補完するようなものとして考え
ることができます。ファイルを最新にするためには update を使い、
status で update が何をするかをある程度知ることができま
す (もちろん、リポジトリの状態は実際に update を実行するまでに
変化するかもしれません)。実際は、status コマンドで表示されるよ
り短い形式でコマンドに表示させたければ、次を実行することができます
$ cvs -n -q update
-n オプションは実際に update をしないが、状態を表示するだけであ
る、ということです。-q オプションはそれぞれのディレクトリ名の印
字を避けます。update コマンドとこれらのオプションの情報は、
Invoking CVS を参照してください。
ファイルを更新もしくはマージしたい場合には、
update コマンドを使用します。
これは最新でないファイルに対しては checkout コマンドとほとんど
等価です。
つまり、ファイルの最新リビジョンをリポジトリから取り出して、
作業ディレクトリに置きます。
update コマンドを使用しても、
あなたの修正が失なわれることはありません。
より新しいバージョンが無い場合には、update は何もしません。
新しいバージョンが存在し、かつ作業ファイルが修正されている場合、
CVS は全ての変更を作業コピーにマージします。
例えばリビジョン 1.4 を取り出して、編集を始めたとします。
その合間に他の人物がバージョン 1.5 を格納し、
またすぐに 1.6 になったとします。
ここで update コマンドを使用した場合、
CVS は 1.4 と 1.6 間の変更を、あなたのファイルに組み入れます。
1.4 と 1.6 間の変更が、あなたの変更と似たようなものであれば、
重複 (overlap) が起きます。
そして警告が表示され、ファイルには重複した行が両方並記されて、
特別なマークで囲まれます。
update コマンドの詳細は See update.
リビジョン 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 を元にしたあなたの driver.c の作業コピーは、
cvs update の前に次ようになっています:
#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 は警告を印字してファイルの格納を実行します。
もしあなたが pcl-cvs (GNU Emacs 用 CVS フロントエンド) の、 1.04 よりも新しいリリースを使用しているならば、衝突を解決するのに emerge という Emacs パッケージが利用できます。 pcl-cvs の文書を見て下さい。
新しいリビジョンが格納されたときに、
それを開発者全員に通知するようにしておくと便利でしょう。
moduels か loginfo ファイルの
-i オプションにより、この手順を自動化することができます
See modules. See loginfo.
この機構により、例えば全ての開発者にメールを出したり、
ニュースに記事を投稿したりすることができます。
複数の開発者が同時に 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 Multiple developers)。
任意のリポジトリから何人でも、 同時に読み出すことが可能です。 誰かが書き込み中の場合にだけ、 他の人の読み出しや書き込みが禁止されます。
次に示すような動作を望む人がいるでしょう
ある人物が一つの cvs コマンドで複数のファイルに対する変更点を 格納した時、他の誰かが同時に update を実行すると、全てのファイルが 更新されるか、全く更新されないかのどちらかである。
が、CVS はこのように動作しません。 例えば以下のファイルがあるとして、
a/one.c a/two.c b/three.c b/four.c
ある人物が次のコマンドを実行した時、
cvs ci a/two.c b/three.c
同時に他の誰かが cvs update を実行した場合、
update を実行している人は b/three.c の変更点のみが更新さ
れ、
a/two.c の変更点は更新されないでしょう。
多くのグループが CVS を既定状態で使用していますが、 ほぼ完全に満足しているようです。 しかし時には、自分と他人の修正点が重複する事があり、 この重複を処理して再び格納しなくてはいけません。 あるグループでは、 誰がどのファイルを編集中か分るようにしています。 従って、二人で同じファイルを編集する場合、 誰が何時何をするのか相談できるため、 格納時に驚かされずに済みます。 この節では、 このような調整作業を行なう機能について説明しますが、 二人の開発者が同時に同じファイルを編集する能力は維持されます。
開発者は、
編集するファイルを読み書き可能にする時に、
(chmod でなく) cvs edit を使用し、
もう使用しない作業ディレクトリを処分する時に、
(rm でなく) cvs release を使用することが推奨されます。
しかし、CVS はこれらの手順を強制する事は出来ません。
監視機能を有効にするには、 まずそのファイルを監視するように指示する必要があります。
cvs watch on [-lR] files ...
|
コマンド |
|
この指定以降、files を編集しようとする開発者は
files がディレクトリを含む場合、
リポジトリの対応するディレクトリ内の全てのファイルに加えて、
将来ディレクトリに追加されるファイル全てが
CVS の監視対象になります。
この動作を利用して、ディレクトリ毎に通知方針を設定することができます。
またオプション files を省略した場合、 現在のディレクトリが指定されたと解釈します。 |
cvs watch off [-lR] files ...
|
コマンド |
|
files が編集された時の通知を行ないません。 CVS は files の作業コピーを読み書き可能にします。 files や引数指定時の振舞いは、
|
あるファイルに対して種々の操作が行われた時に通知を受けたい場合には、
その旨を CVS に知らせます。
そのファイルに対して cvs watch on を用いなくても、
通知の要求は可能です。
しかし、開発者がコマンド cvs edit を用いるとは限らないため、
通常は cvs watch on を用いた方が良いでしょう。
cvs watch add [-a action] [-lR] files ...
|
コマンド |
|
現在の使用者を、 files に対して操作が行なわれた時に 通知を受けとる人の一覧に追加します。 オプション
オプション files や引数指定時の振舞いは、
|
cvs watch remove [-a action] [-lR] files ...
|
コマンド |
|
|
通知すべき状態が発生した時、
CVS は管理用ファイル notify を見ます。
notify は他の管理用ファイルと同じように編集して下さい。
(see Intro administrative files)。
管理用ファイルの慣例に従って (see syntax)、このファイルの各行には、
正規表現に続けて実行したいコマンドを記述します。
コマンドの引数には、(通知すべき使用者に置換される)
%s という文字列を一つだけ指定する必要があり、
通知内容はコマンドの標準入力に与えられます。
ファイル notify に書く標準のものは次の一行です:
ALL mail %s -s \"CVS notification\"
この記述により、使用者に電子メールで通知が行なわれます。
上記の行をそのまま記述した場合、
使用者はサーバ上で通知を受ける事に注意して下さい。
他の場所に通知したい場合には、
もちろん notify に記述しても良いのですが、
CVS ではもっと簡単に各使用者の通知先を設定できます。
CVSROOT に users というファイルを作成し、
user:value という書式で、
各使用者について一行ずつ記述して下さい。
CVS は、notify に記述された user の代りに、
value (通常は別のマシンのメールアドレス) に通知します。
CVS はあなた自身の変更は通知しません。現時点では、この照合は通知 を発生させる動作をしている人の使用者名が通知を受ける人の使用者名と合う かどうかに基づいてなされています。実際のところ、一般的に、監視機構はそ れぞれの使用者の一つの編集だけを追跡します。おそらく、監視がそれぞれの 作業ディレクトリを別に追跡するとより便利なので、この振舞いは変更する 価値があるでしょう。
監視下にあるファイルを取り出した場合、
読み込みだけが許可されるため、単純に編集はできません。
読み書きを可能にし、そのファイルを編集する意図を他の人に伝えるために、
cvs edit コマンドを使用して下さい。
上記の作業を checkout と呼ぶシステムもありますが、
CVS ではこの用語をソースのコピーを得る (取り出す)
という意味で用います (see Getting the source)。
他のシステムでは、この操作は get とか fetch と呼ばれます。
| cvs edit [options] files ... | コマンド |
|
作業ファイル files を編集する準備をします。
CVS は files の読み書きを許可し、
files に対する
files や引数指定時の振舞いは、
注意: |
変更を全て終了したら、通常は cvs commit を用いて、
監視下にあるファイルの変更点を格納し、
読み込みだけが許可された状態に戻します。
しかし、途中で変更を止めたり、何も変更しないと決めた場合には、
cvs unedit コマンドを使用します。
cvs unedit [-lR] files ...
|
コマンド |
|
作業ファイル files に加えた変更を捨て、
変更前のリポジトリのバージョンに戻します。
files に対して、 files や引数指定時の振舞いは、
ファイルが監視されてないときにはおそらく
|
CVS のクライアント/サーバを使用していて、
サーバとうまく接続できなかった場合でも、
cvs edit や cvs unedit コマンドが使用できます。
次に CVS コマンドが成功した時に、
一緒に通知が行なわれます。
cvs watchers [-lR] files ...
|
コマンド |
|
現在、files の変更を監視している人物の一覧を表示します。 監視されているファイルと、各監視者のメールアドレスを報告します。 files や引数指定時の振舞いは、
|
cvs editors [-lR] files ...
|
コマンド |
|
現在、files を編集している人物の一覧を表示します。 各編集者のメールアドレス、編集作業を開始した時間、 ファイルが置かれた作業ディレクトリのパス名とホスト名を報告します。 files や引数指定時の振舞いは、
|
監視機能を使用している場合、
リポジトリに 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 が利用できる状態に再構築できます。
独占取得、無条件取得それぞれに一長一短があります。 ここでは、この問題を簡単に説明しますが、 残りの多くは個人的な見解の相違や、 各グループの作業スタイルの相違だと思います。 開発者チームを構成するには様々な方法があります。 CVS は特定の構成を強制せず、 各々を実現する機能を提供するだけです。
独占取得には、非常に非生産的な部分があります。 二人が同じファイルを編集する場合でも、編集部分が異なる場合には、 どちらか一方の編集を禁止する必要は全くありません。 また、ファイルを編集するためにロックした後、 ロック解除を忘れてしまうことが、普通に起こり得ます。
独占取得に特別な安心感を持つ人々は、 無条件取得を用いた場合の衝突の多さや、 それを解決する困難さをよく訴えます。 しかし多くのグループの経験から言うと、 衝突は稀であり、解決も普通は比較的簡単なものです。
衝突は2人の開発者がコードの与えられた部分の適切な設計について 意見が食い違っているときにのみ起こることを理解するまで、 深刻な衝突の発生の少なさは驚きでしょう。 このような衝突は、そもそもチーム内での意思疎通が上手く行っていないこと を示しています。 どのようなソース管理方法を採るにしても、 開発者が共同で作業する際には、 システム全体の設計方針に従わなければいけません。 きちんと従っていれば、簡単にマージできる重複ばかりになるでしょう。
無条件取得が、全く不適当な場合があります。 管理下にあるファイルの形式をマージする道具が無く (例えばワード・プロセッサによるファイルや、 CAD プログラムで編集されたファイル等)、 マージ可能なデータ書式を使用するようにプログラムを変更できない場合、 悪夢のような衝突解決をするよりは、 普通は独占取得を用いて簡単に衝突を避けたほうが賢明でしょう。
上の Watches で記述された監視機構は、 独占取得と無条件取得の中間的なものと考えられます。 ファイルを編集する前に、 他の誰がファイルを編集中なのか調べることができます。 これは単純に双方の同時編集を禁止するのではなく、 現況を報告し、それが問題かどうかは自分で判断してもらいます。 これを適切に使用すれば、 独占取得と無条件取得の中でも最善の選択となるでしょう。
ここまで読んだあなたは、 CVS を使って何ができるかを、もう随分理解しているでしょう。 ここでは、あなたが決めるべき事柄について少し説明します。
あなたが一人で CVS を使用して開発しているならば、 ここは読み飛ばして結構です。 複数の人物が同じリポジトリを使って作業する場合に、 ここで説明する問題が重要になってきます。
あなたのグループは、格納の時期に関して、 どのような方針を採るか決めておく必要があります。 幾つかの方針が可能であり、CVS での経験を重ねることによって、 独自の方法を見付けることができるでしょう。
とにかく早く格納することにして、 コンパイルもせずに格納してしまったとします。 あなたの同僚が、作業ソースを更新して あなたのバギーなファイルを取り込んだ場合、 彼はコンパイルができません。 逆にめったに格納しない場合、 同僚はあなたがコードに加えた改良の利益を得ることができず、 衝突がより多くなるでしょう。
コンパイルできるかどうか確認したファイルだけを
格納する方法がよく採られます。
あるサイトでは、ファイルが検査に合格することを要求します。
commitinfo ファイルを使用して (see commitinfo)、
このような方針を強制できますが、その前によく考えなくてはいけません。
十分過ぎる程管理された開発環境を作ると、
厳格になり過ぎて、非生産的になり、
ソフトウェアを書くという目的が果たせなくなります。
作業ファイルを編集している間は、
いつでも cvs status や cvs log を使って
そのファイルの状態を調べることができます。
しかし開発環境から取り出した場合は、
各ファイルのリビジョンを識別するのが難しくなります。
CVSは、キーワード置換 (keyword substitution)
(もしくはキーワード展開 (keyword expansion))
と呼ばれる機構により、ファイルの識別を補助します。
ファイル中に $keyword$,
$keyword:...$ といった書式で
埋め込まれた文字列を、ファイルを取り出すときに
$keyword:value$ といった書式の文字列に置き換えます。
これはキーワードの利用の一覧です:
$Author$
$Date$
$Header$
$Id$
$Header$ と同じです。
$Name$
cvs co -r
first を実行すると、キーワードを Name: first に展開します。
$Locker$
cvs admin -l が使われていなければ
それが普通です。)
$Log$
$Log:...$ の次の行に挿入します。
それぞれの新しい行には $Log キーワードの前にあるものと
同じ文字列が付きます。例えば、ファイルが以下のようになっているとします。
/* Here is what people have been up to: * * $Log: frob.c,v $ * Revision 1.1 1997/01/03 14:23:51 joe * Add the superfrobnicate option * */
そうすると、$Log を展開するときに追加される行はその前に
* が付きます。以前のバージョンの CVS、RCS と違って、
RCS ファイル の 註釈符 (comment leader) は使用されま
せん。
$Log キーワードは、
ソース・ファイルに全てのログを残したい場合には便利ですが、
問題点も幾つかあります (see Log keyword)。
$RCSfile$
$Revision$
$Source$
$State$
cvs admin -s で割り当てることができます--
admin options 参照。
キーワードを使いたい場合は、$Id$ などの適当な文字列を
ファイルに記述してから格納するだけです。
CVS は格納操作の一環として自動的に文字列を展開します。
$Id$ 文字列をソースファイルに入れて、生成されるファイル
にそれが渡されるようにするのはよくあることです。例えば、コンピュータプ
ログラムのソースコードを管理していれば、その文字列を含むように初期化さ
れている変数を入れるでしょう。またバイナリ中に直接文章を埋め込むために
#pragma ident 命令が使用できるコンパイラもあります。もしくは、
文書管理システムが生成されたファイルに文字列を渡す方法を提供するかもし
れません。
ident コマンド (RCS パッケージの一部) を使用して、
ファイルからキーワードとその値を抜き出すことができます。
もちろんテキスト・ファイルにも使えますが、
バイナリ・ファイルからキーワードを抜き出したいときに非常に便利です。
$ ident samp.c
samp.c:
$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
$ gcc samp.c
$ ident a.out
a.out:
$Id: samp.c,v 1.5 1993/10/19 14:57:32 ceder Exp $
別のリビジョン管理システムとして有名なものに SCCS があります。
SCCS には、ident と非常によく似た
同じ用途のコマンド what が含まれます。
RCS を持たないサイトの多くは SCCS を使っています。
what コマンドは @(#) という文字列を探すため、
両方のコマンドに対応するキーワードを含めるのは簡単です。
キーワードの前に、
簡単な SCCS の魔法の呪文を唱えるだけで良いのです:
static char *id="@(#) $Id: ab.c,v 1.5 1993/10/19 14:57:32 ceder Exp $";
キーワード置換にも欠点があります。
ファイル中に表われる文字列 $Author$ は、
RCS によってキーワードと見倣されます。
この文字列を $Author: ceder $ などと解釈させずに、
そのまま使いたい事があるでしょう。
不幸なことに、選択的にキーワード置換を止めることはできません。
-ko によって完全にキーワード置換を止めることができます
(see Substitution modes)。
RCS キーワードが最終製品に現われるとしても、
ソース・ファイル中には使いたくない場合が多くあります。
例えばこのマニュアルのソースには $Author$ ではなく、
$@asis{}Author$ と記述しています。
nroff や troff であれば、
ヌル文字である \& をキーワード中に埋め込めば
同様の効果を発揮します。
各ファイルには既定の置換モードが設定されており、
作業ディレクトリの各ファイルの置換モードも別々に設定できます。
前者は cvs add や cvs admin に
オプション -k を付けて設定します。
後者は cvs checkout や cvs update に
オプション -k や -A を付けて設定します。
cvs diff にも -k オプションがあります。
例が幾つかありますので、Binary files と Merging and keywords 参照。
利用できるモードを以下に示します:
-kkv
Revision に対して
$Revision: 5.7 $ が生成されます。
-kkvl
-kkv とほぼ同様ですが、
指定されたリビジョンがロックされていれば、
ロックしている人物の名前を挿入します。
ロックしている人物名は cvs admin -l が使用されているときだけ関
係があります。
-kk
Revision に対して、
$Revision: 5.7 $ ではなく、
$Revision$ が生成されます。
このオプションは、リビジョン間の違いを比較する時、
キーワードによる違いを無視するのに便利です (see Merging and keywords)。
-ko
Revision に対して、
$Revision: 5.7 $ ではなく、
ファイルが格納された時の文字列である
$Revision: 1.1 $ が生成されます。
-kb
-ko と同様ですが、
リポジトリに格納される標準的な行末形式 (ラインフィードのみ) を、
クライアント側のオペレーティングシステムに適した形式へ変換しません。
行端にラインフィードのみが使用されるシステム (unix 等) では、
このオプションは -ko と同じです。
バイナリ・ファイルの詳細情報は Binary files 参照。
-kv
Revision に対して、
$Revision: 5.7 $ ではなく、
5.7 が生成されます。
これは、$Revision: $ といった、
キーワード識別子を除くのが困難な
プログラミング言語のファイルを生成する時に便利です。
しかし、キーワード名が削除されてしまうために、
これ以後はキーワード置換を行うことができません。
従って使用には注意が必要です。
オプション -kv は、cvs export で使用される事が
多くあります--see export。
しかしモジュールがバイナリ・ファイルを含む場合は、
うまく処理できないので使用しない方が賢明です。
キーワード $Log$ にはちょっと問題があります。
開発環境で作業をしているならば、
キーワード $Log$ を使用しなくても、
cvs log を使えば同じ情報が簡単に手に入ります。
いずれにしても出荷用のファイルに履歴情報は必要ないでしょう。
さらに重要な問題は、枝を幹にマージするときに、
RCS が $Log$ の項目をうまく扱えないことです。
このマージ操作の結果、衝突が起きることがよくあります。
またファイル中のログ・メッセージは、修復される傾向にあります。
(綴の間違いやほんとの間違い等)。
しかしこの結果、
cvs log の情報とファイルの中身が一致しないことになります。
これも問題といえば問題でしょう。
どうしてもキーワード $Log$ を使うのならば、
ファイルの先頭ではなく、
ファイルの 最後 に挿入することを推奨します。
この方法ならば、
長い変更メッセージを毎日眺めなくて済みます。
あなたのサイトに合わせてプログラムを修正した場合、 そのプログラムの次のリリースにも同じ修正を加えたいでしょう。 CVS を用いてこの作業を自動化することができます。
CVS の用語では、プログラムの開発元をベンダー (vendor) と呼びます。 ベンダーの配布物は、 修正を加えずに ベンダー枝 (vendor branch) という枝に格納します。 CVS はこの為に 1.1.1 という番号を予約しています。
あなたがソースを修正して格納した場合、 そのリビジョンは幹に入ります。 ベンダーから新しいリリースが届いたら、 それをベンダー枝に加えて、修正を幹にコピーします。
ベンダー枝を作り、更新するには、
import コマンドを使用します。
新しいファイルを import すると、
ベンダー枝に `最初' のリビジョンが作られ、
checkout する人は誰でもそのリビジョンを取得します。
格納されたローカルな修正は幹に置かれ、
`最初' のリビジョンが作られます。
まず最初に、import コマンドを使ってソースを登録します。
import コマンドでサード・パーティーの追っかけをする場合には、
ベンダー・タグ (vendor tag) と
リリース・タグ (release tag) を用いると良いでしょう。
ベンダー・タグは枝のタグ名です
(-b branch フラグを使用しなければ、
枝のリビジョンは常に 1.1.1 です--See Multiple vendor branches.)。
リリース・タグは特定のリリースを指すタグ名で、
ここでは FSF_0_04 とします。
import は起動されたディレクトリを変更 しない ことに注意
してください。特に、そのディレクトリが CVS の作業ディレクトリとし
て設定されることはありません。ソースに作業をしたいなら、まずそれを持ち
込んで、それから違うディレクトリに取り出してください (see Getting the source)。
ディレクトリ wdiff-0.04 に wdiff というプログラムのソー
スがあるとします。将来に新しいリリースがなされたときでも適用したい個人
的な修正を加えようとしています。まず、リポジトリに wdiff のソー
スを加えることから始めましょう:
$ 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 としています。
新しいリリースのソースが届いたら、
それを最初と同じく 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 Conflicts example)。
その後、変更したファイルを格納します。
上記の実行例のように日時を使用する場合、
一日に一つ以上のリリースを import しないと仮定しています。
この仮定に反するならば、次のようにして下さい:
$ cvs checkout -jWDIFF_0_04 -jWDIFF_0_05 wdiff
今の例では、上の二つのコマンドは等価です。
全てのファイルで `先頭' のリビジョンを変更してベンダー枝に戻すことで
ローカルの変更を完全に復旧し、最新のベンダーリリースに戻ることができま
す。例えば、ソースの取り出したコピーを ~/work.d/wdiff に置いて
いて、そのディレクトリの全てのファイルをベンダーのバージョンに戻したい
のなら、次のように入力します:
$ cd ~/work.d/wdiff $ cvs admin -bWDIFF .
-bWDIFF は -b の後空白を入れないで指定しなければなりませ
ん。See admin options.
-k wrapper 機能オプションを使って、どのファイルがバイナリである
かを教えます。See Wrappers.
持ち込んでいるソースにキーワードがある場合があります (see Keyword substitution)。例えば、ベンダーは CVS や他の似たキーワード展開構 文を使うシステムを使っているかもしれません。既定の方法でファイルを持ち 込んだだけでは、ベンダーのキーワード展開があなた自身の CVS コピー でも行われます。この情報はベンダーから持ち込んだソースの情報であること がありますから、ベンダーの展開を維持した方がより便利でしょう。
ベンダーのキーワード展開を維持するためには、最初にファイルを持ち込むと
きに cvs import に -ko オプションを付けます。こうすると、
そのファイルのキーワード展開を完全に止めます。もっと選択的な方法を望む
場合は、cvs update や cvs admin に適切に -k オプ
ションを使用します。
今までの例はソースを取得しているベンダーは一つだけだと仮定しています。 いろいろな場所からソースを得るような場合もあります。例えば、多くの違っ た人やチームがソフトウェアを修正しているプロジェクトに関係しているとし ます。これを扱う方法はいろいろありますが、たくさんのソースツリーが散ら ばっていて、とりあえずやりたいことはそれら全てを CVS に放り込んで少な くとも一箇所にまとめることだ、ということがあります。
複数のベンダーがある状況を扱うために、cvs import に -b
オプションを指定できます。その引数は持ち込むベンダー枝です。既定値は
-b 1.1.1 です。
例えば、赤チームと青チームの2つのチームがあり、あなたにソースを送って くるとします。赤チームが努力したものを枝 1.1.1 に持ち込んで、ベンダー タグ RED を使いたいと思っています。青チームが努力したものは枝 1.1.3 に 持ち込んで、ベンダータグ BLUE を使おうとしています。使用するコマンドは 以下のようになります。
$ cvs import dir RED RED_1-0 $ cvs import -b 1.1.3 dir BLUE BLUE_1-5
ベンダータグ が -b オプションと合わなくても、CVS は発見しないこ
とに注意してください。例えば、
$ cvs import -b 1.1.3 dir RED RED_1-0
慎重に; この種類の不適当な組合せは混乱や、よりひどいことへの種になりま す。不釣合いを指定することでの便利な使用をここでは考え付きません。もし そのような使用を発見しても、使わないでください。CVS は将来のリリースで はそれをエラーにするでしょう。
紹介で書かれているように、CVS にはソースコードからソフトウェアを 構築するためのソフトウェアはありません。この部分は構築システムが CVS と協調するかもしれない種々の側面を説明します。
RCS に慣れている人からの特に多い、よくある質問は、どうすれば構築
機構が最新のソースのコピーを手に入れることができるか、ということです。
CVS では2重になります。まず最初に、CVS はディレクトリを再帰
的に辿ることができますので、各ファイルが最新であることを確認するために
Makefile (もしくは、構築ツールが使う設定ファイルの名前) を修正
する必要はありません。その代わりに、まず cvs -q update として、
それから make や構築ツールを起動するコマンドを実行するという2つ
のコマンドだけを使います。2番目に、あなた自身の作業が終わるまで、誰か
の変更したコピーを取得したい と思わないかもしれません。1つの方
法はまずソースを更新して、それから実装、構築し、考えていた変更を試して
からソースを格納する (必要ならまず更新します) というものです。定期的に
(変更の合間に、さっき書いた方法で) 木全体を更新することで、ソースが十
分に新しいことを保証できます。
よくある要求は、どのソースファイルのどのリビジョンが特定の構築に相当す
るかを記録することです。このような種類の機能は bill of materials
などと呼ばれることがあります。CVS で実現する最良の方法は
tagコマンドがどのバージョンが与えられた構築に相当するかを記録す
ることです (see Tags)。
CVS を一番素直な方法で使うと、それぞれの開発者は特定の構築に使わ れるソースツリー全体のコピーを持っています。ソースツリーが小さかったり、 開発者が地理的に離れたところにいるのなら、これが好ましい解決方法です。 実のところ、大きなプロジェクトを遂行する手段の一つはプロジェクトを小さ な分割してコンパイルされるサブシステムに分け、開発者に必要なことは主に 作業しているサブシステムだけを取り出すだけにするように、内部でリリース する方法を作ることです。
別の手段は、開発者にいくつかのファイルのコピーだけの所有をして、他のファ
イルには中央管理下のソースファイルを見に行くことができるようにする機構
を設定することです。多くの人は、大部分のオペレーティング・システムにあ
るシンボリックリンクや、make の多くのバージョンにある
VPATH 機能を使う様な解決法に到達しました。
このような種類のものを助けるために設計された構築ツールに Odin というも
のがあります (ftp://ftp.cs.colorado.edu/pub/distribs/odin 参照)。
普通の環境では、CVS は普通のファイルでのみ動作します。プロジェクトの全 てのファイルは永続すると仮定されています。開き、読み込み、閉じるという 操作などが可能でなければなりません。また、CVS はファイルの使用許可と所 有権を無視します。そのような問題はインストール時に開発者によって解決さ れる必要があります。言い換えれば、デバイスを "格納" することは不可能で す。デバイスファイルを開けなければ、CVS はそれを扱うことを拒否します。 ファイルはリポジトリの取り扱い中にも所有権や使用許可を失います。
リポジトリで設定変数 PreservePermissions (see config) が設
定されていると、CVS は以下のファイルの特性をリポジトリに記録します:
PreservePermissions オプションを使うと CVS の振舞いにいくつか影
響します。まず、CVS で使用可能になった新しい操作の中に、全ての使用者に
は使用可能でないものができます。特に、ファイルの所有権と特別なファイル
の特性とはスーパーユーザにだけ変更できるものでしょう。ですから、
PreservePermissions 設定変数が設定されていると、使用者は CVS の
操作をうるために `root' になる必要があるでしょう。
PreservePermissions が使用されていると、CVS の操作の中には
(cvs status のように) ファイルのハードリンク構造を認識せず、合っ
ていないハードリンクに関して見せかけの警告を出力します。これは CVS の
内部構造がハードリンクに必要なデータ全てを集めるのを難しくしており、そ
のために不正確なデータでファイルの衝突を調べるからです。
CVS はファイルの内容が変更されたときのみ、それが変更されたと考えること
による、より微妙な違いがあります (特に、作業ファイルの修正時刻がリポジ
トリのそのファイルと合わないとき)。ですから、使用許可、所有権、ハード
リンクが変わったり、デバイスの主、副番号が変わったとしても、CVS は報告
しません。そのような変更をリポジトリに格納するためには、cvs
commit -f で格納を強制する必要があります。これは、ファイルの使用許可
が変わっていて、リポジトリのファイルが作業コピーより新しいと、
cvs update の実行は、知らない間に作業コピーの使用許可を変更して
いるということでもあります。
CVS リポジトリでのハードリンクの変更は特に慎重な扱いが必要です。
foo がファイル old にリンクされていたけれど、後でファイ
ル new にリンクされ直したとしましょう。foo, old,
new は全て中のリンクパターンは変更されているけれど、foo
と new だけが修正されていて、そのために old は格納の候補
としてみなされない、という変な状況になることがあります。このような方法
により整合しない結果は非常に簡単に作られます。ですから、ハードリンクを
リポジトリに保存するのが重要なときは、賢明な動作方法は最後の格納からリ
ンクや状態が変わったファイル全てに touch することです。実際、複
雑なハードリンク構造のディレクトリを格納する前には touch * をす
るのが賢いかもしれません。
おそらく明らかである理由により、普通のファイルだけがマージできるという
ことを書いておくのも意味のあることでしょう。もし cvs update や
cvs checkout -j がシンボリックリンクを普通のファイルとマージし
ようとしたり、2つのデバイスファイルが違った種類のデバイスのためのもの
であったりすると、CVS は衝突を報告して、マージの実行を拒否します。また、
テキストがないファイル上でのテキスト比較は無意味なので、cvs
diff はこれらのファイル間の相違を報告しません。
PreservePermissions 機能はクライアント/サーバの CVS では動
作しません。別の制限に、ハードリンクは同じディレクトリの他のファイルへ
のリンクでなければならない、というものがあります。ディレクトリをまたい
だハードリンクは使用できません。
この付録は CVS コマンドの全体構造の説明をし、いくつかのコマンドは 詳しく説明します (他のものは別のところで説明されています。CVS コ マンドの簡単な便覧は、see Invoking CVS)。
CVS のコマンド全体の書式を示します:
cvs [ cvs_options ] cvs_command [ command_options ] [ command_args ]
cvs
cvs_options
cvs_command
cvs_command を省略できます。
つまり cvs -H として利用可能なコマンドのリストを得る場合か、
cvs -v として CVS 自身のバージョン情報を得る場合です。
command_options
command_args
不幸な事に、
cvs_options と command_options の間で幾つか混乱があります。
-l は cvs_option として使われたときいくつかのコマンドに
影響します。command_option として使されたときは、より多くのコマ
ンドで意味を持ちます。つまり、上の分類をあまり深刻に受けとめないでくだ
さい。代わりに文書を見るようにしましょう。
CVS はそれ呼んだ環境に 終了状態 (exit status) を設定するこ
とで、成功したか失敗したかを示すことができます。
終了状態を調べる正確な方法はオペレーティング・システムごとに異なります。
例えば、unix のシェルスクリプトでは、最後のコマンドが成功終了状態を返
せば変数 $? は0で、終了状態が失敗を示していれば、0より大きくな
ります。
CVS が成功した場合は、成功状態を返します。エラーがあれば、エラーメッセー
ジを印字して、失敗状態を返します。cvs diff コマンドはこの例外で
す。違いが見つからなければ成功状態を返し、違いが見つかるか、エラーが発
生したときに失敗状態を返します。この振舞いはエラーの検知には良くないの
で、将来では cvs diff が他の CVS コマンドと同じように振舞
うように変更される可能性があります。
よく使用する command_option が幾つかあり、
そのオプションを必ず指定するように設定したいことがあります。
例えば (実際に .cvsrc を実装した要因の一つですが)
多くの人には diff の既定出力は大変読みにくく、
context 形式か unidiff 形式のほうが遥かに分かりやすいでしょう。
シェル・スクリプトやエイリアスに頼らなくても、
~/.cvsrc ファイルを用いて cvs_commands 各々に
既定のオプションを加えることができます。
~/.cvsrc の書式は簡単です。
実行された cvs_command と同じ名前で始まる行が検索されます。
一致した行を発見したら、行の残りの部分をオプションに分割し (空白のとこ
ろで)、
コマンド行からのオプションを与える前に、
得られたオプションをコマンドの引数として与えます。
コマンドが別名を持つ場合 (例えば、checkout と co)、
コマンド行で使われるものとは限りませんが、公的な名前がファイルとの
合致時に使用されます。
例えば ~/.cvsrc の内容が次の様であった場合:
log -N diff -u update -P checkout -P
cvs co foo も、コマンド cvs checkout foo と同様に
-P が引数として与えられます。
上記の例では cvs diff foobar の出力は unidiff 形式になります。
cvs diff -c foobar だと指定通り context 形式になります。
diff には "古い" 形式で出力するためのオプションが無いため、
"古い" 形式を使いたい場合には少し面倒ですが
cvs -f diff foobar とする必要があります。
コマンド名の部分に cvs と記述すれば、
広域オプションを指定することができます (see Global options)。
例えば .cvsrc 中の以下の行は、
cvs -z6
CVS が圧縮レベル 6 を用いるように指定しています。
cvs_options (cvs_command の左側に与えられる)
として利用できるものを以下に示します:
--allow-root=rootdir
-a
-b bindir
-T tempdir
$TMPDIR の設定や、
コンパイル時のディレクトリ設定よりも優先されます。
この値は絶対パス名で指定して下さい。
-d cvs_root_directory
$CVSROOT よりも優先します。See Repository.
-e editor
$CVSEDITOR や $EDITOR よりも優先します。
詳しい情報は Committing your changes 参照。
-f
~/.cvsrc を読みません。
このオプションが最も良く使われるのは、
CVS のオプション設定に直交性がない時です。
例えば cvs log のオプション -N (タグの表示を抑制します)
に対応する表示を行なうオプションはありません。
従って、~/.cvsrc の log エントリに -N があったとき、
タグを表示するには -f を使用する他ありません。
-H
--help
cvs_command の使用法を表示します
(コマンドが実際に実行されることはありません)。
コマンド名を指定しない場合には、
cvs -H は他のヘルプオプションの一覧などを含む、CVS の全体
のヘルプを表示します。
-l
cvs_command をコマンド履歴に記録しません
(しかしコマンドは実行されます)。
コマンド履歴の情報は See history.
-n
cvs_command を実行した場合の表示だけが行なわれます。
既存のファイルを削除, 更新, マージしたり、
新しいファイルを作成することはありません。
CVS は必ずしも -n を付けなかったときと全く同じ出力をするわ
けではないことに注意してください。ときどき、出力が同じ場合がありますが、
他の場合では、CVS は正確に同じ出力をするために必要な実行を飛ばし
ます。
-Q
-q
-r
$CVSREAD を設定するのと同じ効果があります
(see Environment variables)。
既定では、そのファイルが監視されてない限り作業ファイルへの書き込みが許
可されます (see Watches)。
-s variable=value
-t
-n オプションと共に使用し、
不慣れなコマンドの潜在的な影響を調べるのに便利です。
-v
--version
-w
$CVSREAD の設定を無効にします。
$CVSREAD が設定されておらず、
-r オプションも無い場合には、
作成されるファイルは読み書き可能とされます。
-x
--enable-encryption を指定
して CVS を構築する必要があります。
-z gzip-level
ここでは、複数の CVS コマンドで共通に使用できる
command_options について説明します。
これらのオプションは、
必ず cvs_command の右側に付けられます。
以下に示すオプションは、全てのコマンドで使えるわけではありません。
各オプションは、それが意味をなすコマンドにおいてのみ使用可能です。
しかし以下のオプションを持つコマンドがあるならば、
そのオプションは他のコマンドのものと同じ動作であると考えて良いでしょう。
(各コマンドの固有オプションのほとんどは、
他の CVS コマンドのものとは異なる意味を持っています。)
警告: history コマンドは例外です。このコマンドには、
ここに示す標準オプションと重複する固有オプションが多くあります。
-D date_spec
このオプションを用いて作業ファイルを取り出すと、
指定した日付が貼り付けられます。
つまり -D オプションの引数が記録され、
これ以後の update の際に同じ日付が用いられます
(貼り付いたタグ/日付についての詳細は see Sticky tags)。
-D は以下のコマンドで利用できます:
checkout, diff, export, history,
rdiff, rtag, update.
(history コマンドはこのオプションを少し違った方法で使用します。
see history options).
CVS では、様々な形式で日付を指定できます。 最も標準的なものは (International Standards Organization による) ISO8601 と (RFC 822 で規定され、RFC1123 で修正された) Internet e-mail の標準です。
ISO8601 はいろんな異種があります。すこし例を挙げます:
1972-09-24 1972-09-24 20:05
ISO8601 の日付様式にはいろいろなものがあり、CVS はそれらの多くを受け付 けますが、おそらくながーい話し全部を聞きたいとは思わないでしょ う :-)。
Internet e-mail で使用が認められている日付に加えて、 CVS では、いくつかのフィールドが省略されたものも使えます。 例えば、以下のようなものです:
24 Sep 1972 20:05 24 Sep
特定の標準時が指定されていない場合は、日付はローカルの標準時として解釈 されます。
この2つの書式の使用が好まれます。しかし、CVS は今は他の日付の書式 を幅広く受け付けます。それらはここでは故意に詳しくは説明されておらず、 CVS の将来のバージョンはそれら全ては受け付けないかもしれません。
そのような書式の中に
月/日/年. というものがあります。
これは月と日が逆の順番になっているものに慣れている人を混乱させます。
1/4/96 は1月4日であり、4月1日ではありません。
シェルは空白を引数の区切りにするので、
-D の引数を引用符で囲むのを忘れてはいけません。
-D オプションを付けたコマンド行は、次の様になるでしょう:
$ cvs diff -D "1 hour ago" cvs.texinfo
-f
-f オプションを使用します
(そのファイルの最新のリビジョンが取り出されます)。
-f のときでさえ、指定したタグは存在していなければならないことに
注意してください (すなわち、必ずしも全てのファイルというわけではなく、
いくつかのファイルにおいて)。 これは CVS が、名前の入力を間違えた
ときにエラーを出すことを続けられるようにするためです。
-f は以下のコマンドで利用できます:
annotate, checkout,
export, rdiff, rtag, update.
警告: commit と remove コマンドにも -f
オプションがありますが、異なる動作をします。See commit options,
Removing files 参照。
-k kflag
このオプションを用いて作業ファイルを取り出すと、
kflag が貼り付けられます。
つまり、このオプションを checkout や update コマンドに
用いた場合、CVS は指定した kflag をそのファイルに結合します。
これ以後、同ファイルに対する update コマンドには
kflag が使用され続けます。
この効果は別の指定を行なうまで止みません。
-k オプションは以下のコマンドで利用できます: add,
checkout, diff, import, update.
-l
警告: cvs_command の左側に指定する
cvs -l と混同しないようにして下さい。
以下のコマンドで利用できます: annotate, checkout,
commit, diff, edit, editors,
export, log, rdiff, remove, rtag,
status, tag, unedit, update, watch,
and watchers.
-m message
-m message
以下のコマンドで利用できます: add,
commit, import.
-n
checkout/commit/rtag コマンド実行時に、
常には実行されるプログラムを実行しません。
各コマンド実行時のプログラムは、
管理用ファイル modules に記述されます
(see modules)。
つまり、このオプションは modules の記述を無効にします。
警告: cvs_command の左側に指定する
cvs -n と混同しないようにして下さい。
以下のコマンドで利用できます:
checkout, commit, export,
rtag.
-P
-p
以下のコマンドで利用できます: checkout, update.
-R
以下のコマンドで使用可能です: annotate, checkout,
commit, diff, edit, editors,
export, rdiff, remove, rtag,
status, tag, unedit, update, watch,
watchers.
-r tag
tag か rtag コマンドで任意に定義されたタグの他に、
二つの特別なタグ HEAD と BASE が常に利用できます。
HEAD は、リポジトリにある最新のリビジョンを参照します。
BASE は、作業コピーの由来となるリビジョンを参照します。
タグを指定して checkout や update コマンドを実行し、
自分の作業ファイルを作った場合、そのタグは貼り付けられます。
つまりこのタグが記録され、以後他のものを指定するまで
update に同じタグが使われ続けます
(貼り付いたタグ/日付についての詳細は see Sticky tags)。
tag には、Tags で説明されているような文字列や、 Branching and merging で説明されているような枝の名前のどちらであ ることもできます。
コマンド・オプション -r と一緒に
広域オプション -q を指定すると、
RCS ファイルが指定したタグを含まない場合に、
警告出力が抑止されるので便利です。
警告: cvs_command の左側に指定する
cvs -r と混同しないようにして下さい!
-r は以下のコマンドで利用できます :checkout,
commit, diff, history, export,
rdiff, rtag, update.
-W
.cvswrappers での指定方法と同じ形式で指定します。
以下のコマンドで利用できます: import, update.
これは雑多な管理機構への CVS のインターフェースです。CVS で は役に立つか疑わしいようなものもありますが、歴史的な互換性の目的のため に存在しています。このコマンドは必ず再帰的に動作するため、使用 の際には細心の注意を払って下さい。
Unix ではグループ名 cvsadmin が存在する場合、
そのグループの一員だけが cvs admin を利用できます
(誰にで実行できる cvs admin -k コマンドを除きます)。
このグループはサーバ側か、非クライアント/サーバの CVS を実行してい
る全てのシステムで存在している必要があります。
その名前で無人のグループを作成すれば、
cvs admin の使用を全面的に禁止できます。
NT では、cvsadmin 機能は存在せず、全ての使用者が cvs
admin を実行できます。
これらのオプションの中には CVS での有用性に疑問符が付くものもあり ますが、歴史的な互換性のために存在しています。中には、効果を解除するま で、CVS を使えなくなるものもあります!
-Aoldfile
-alogins
-b[rev]
cvs admin -b を実行する理由は一つ
だけあります: ベンダー枝を使用しているときに、ベンダーのバージョンに戻
すため、です (see Reverting local changes)。-b と引数の間に
空白があってはいけません。
-cstring
-e[logins]
-e と引数の間に空白があってはいけません。
-I
-i
cvs
add コマンドでファイルを加えてください (see Adding files)。
-ksubst
cvs update, cvs export, cvs checkout
での -k オプションが優先されます。
-l[rev]
-l の間にスペースがあってはいけません。
CVS のソース配布物の中の contrib ディレクトリの中に、
rcslock.pl という名前のスクリプトがあります。
これを用いて上記のロック状態を、
CVS における独占取得 (一時に一人だけがファイル編集可能な状態)
に置き換えることができます。
詳細はスクリプトの註釈を参照して下さい
(寄贈物の支援と権利の放棄声明文が書かれたファイル README
も一読して下さい)。
その註釈によれば、厳格ロックモード (既定) に設定しておく必要があります。
-L
-l オプションの説明も参照して下さい。
-mrev:msg
-Nname[:[rev]]
-n と同じように働きます。
魔法の枝での使用法は Magic branch numbers を参照してください。
-nname[:[rev]]
cvs tag か cvs rtag を代わりに用いると良いでしょう。
: と rev の両方を省略すると、タグ名が削除されます。
また name が既に使用されていた場合は、
エラー・メッセージが出力されます。
rev がタグ名のときは、相当する番号に置換されます。
枝番号の後に . を付けて rev に指定した場合、
その枝の現時点での最新リビジョンになります。
: だけで rev を指定しなかった場合、
既定の枝 (通常は幹) の現時点での最新リビジョンになります。
例えば cvs admin -nname: RCS/* は、
指定された全ての RCS ファイルの、
現時点での最新リビジョンに name というタグ名を付けます。
一方 cvs admin -nname:$ RCS/* では、
各作業ファイルのキーワード文字列に含まれる
リビジョンに name というタグ名を付けます。
-orange
このコマンドは何をしているかを 正確に 知っていないと非常に危険 であることに注意してください (例えば、以下の rev1:rev2 と いう構文がいかに間違いやすいかという警告を読んでください)。
ディスクの容量が少ないなら、このオプションは役に立つかもしれません。し かし、使う前によく考えてください--このコマンドを取り消すためには最後 のバックアップで復元するしかありません! 不注意や、(天が禁止している) CVS のバグによって、計画していたものと違うリビジョンを消してしまったら、 リビジョンが消去される前のエラーを修正する機会はありません。おそらく、 まずリポジトリのコピーで試すというのは良い考えでしょう。
以下のどれかで range を指定します:
rev1::rev2
-o 1.3::1.5 の後では、リビジョン 1.3, リビジョン 1.5, 1.3 から
1.5 の差分を取得することができますが、リビジョン 1.4 や 1.3 と 1.4 の
差分を取得することはできません。他の例です: -o 1.3::1.4 と
-o 1.3::1.3 は間に消去するリビジョンが無いので、何の効果もあり
ません。
::rev
-o ::1.3.2.6 はリビ
ジョン 1.3.2.1, リビジョン 1.3.2.5, とその間の全てのものを消去しますが、
1.3 と 1.3.2.6 はそのまま残します。
rev::
rev
-o 1.3 は -o
1.2::1.4 と等価です。
rev1:rev2
cvs admin -oR_1_01:R_1_02
. はほとんど役に立ちません。それは、タグ R_1_02 までのリビジョンを、
それを含めて消去するということです。でも注意してください! R_1_02 と
R_1_03 で変更されていないファイルがあれば、そのファイルはタグ R_1_02
と R_1_03 で同じ数値リビジョン番号になっています。ですから、
R_1_02 を取得できなるだけではありません。R_1_03 もテープから復元しなけ
ればならなくなります! たいていの場合、代わりに rev::rev2
と指定しようと思うでしょう。
:rev
rev:
消去されるべきリビジョンは全て枝やロックを持っていてはいけません。
消去されるべきリビジョンにタグ名があり、:: 構文のどれかを指定
すると、CVS はエラーを出して、どのリビジョンも消去されません。タ
グ名とリビジョンの両方を消去したいなら、まず cvs tag -d でタグ
名を消去し、それから cvs admin -o を実行します。:: でな
い構文をいてい すると、CVS はリビジョンを消去しますが、タグ名を存
在しないリビジョン指すタグ名として残します。この振舞いは CVS の以
前のバージョンとの互換性のために残されています。しかし、これは便利では
ありませんので、将来は :: の場合と同様の振舞いに変更されるかも
しれません。
CVS が枝を扱う方法のために、rev は、もし枝であれば名前で指 定することはできません。説明は、See Magic branch numbers.
だれも壊したリビジョンのコピーを取り出していないことを確認してください。
誰かがそれを編集して、格納し直そうとすると、変なことが起こります。この
ため、このオプションは無駄な格納を戻すためには良い方法ではありません。
代わりにその変更を元に戻すための新しいリビジョンを格納してください
(see Merging two revisions)。
-q
-sstate[:rev]
Exp (実験段階), Stab (安定動作),
Rel (出荷済) といった組み合わせです。
既定では、新しく作成されたリビジョンの状態は Exp にされます。
各リビジョンの状態は、cvs log (see log) の出力や、
キーワード $Log$, $State$
(see Keyword substitution) の内容で確認できます。
ここで、CVS が dead という状態を
独自の目的で用いることに注意して下さい。
dead 状態を扱う際には、cvs remove
や cvs add といったコマンドを使用し、
cvs admin -s を使用してはいけません。
-t[file]
- で始まってはいけません。
各ファイルの説明文は cvs log (see log) の出力で確認できます。
-t と引数の間に空白があってはいけません。
file が省略された場合、標準入力が用いられ、
ファイル終端 (EOF) もしくは . のみの行で終了します。
対話的動作が可能なら入力促進も可能です。-I を参照してださい。
クライアント/サーバの CVS では標準入力からの読み込みは動作せず、
将来の CVS のリリースでは変更されるかもしれません。
-t-string
-tfile と同様です。
RCS ファイルの説明文を string に書き換えます。
-t と引数の間に空白があってはいけません。
-U
-l オプションの説明も参照して下さい。
-u[rev]
-l オプションを参照して下さい。
リビジョン rev のロックを解除します。
枝を指定した場合、その枝の最新リビジョンのロックを解除します。
rev を省略すると、その人物が行なった最後のロックを解除します。
通常は、ロックを掛けた人物だけがロックを解除できます。
誰か他の人物がロックを解除した場合には、
ロックを掛けた人物にメールが送信されます。
このメールにはロックを解除した理由等が書き添えられます。
連絡文はロックを解除した人物が入力し、
ファイル終端 (EOF) もしくは . のみの行で終了します。
-u とその引数の間に空白があってはいけません。
-Vn
-xsuffixes
,v で終わることを要求してきま
したので、このオプションは今まで役に立ったことはありません。
modules で指定されたモジュールの作業ディレクトリを作成、
もしくは更新し、
その中にソース・ファイルをコピーします。
CVS のほとんどのコマンドは作業ディレクトリを扱うものなので、
まず checkout を実行しておく必要があります。
modules は、
リポジトリ中のディレクトリやファイルへの相対パスだけでなく、
ディレクトリやファイルの集合に対する別名でも構いません。
別名は管理用ファイル modules で定義します
See modules.
指定したモジュールにもよりますが、
checkout は再帰的にディレクトリを作成し、
そこに適切なソース・ファイルを入れていきます。
そして (他の開発者が各自のコピーを編集しているかどうかに関わらず)、
好きなときに自分のソース・ファイルを編集し、
他人の変更を取り入れるために更新したり、
自分の変更をリポジトリに反映するために格納したりします。
checkout で作成されるディレクトリに注意して下さい。
最上位のディレクトリは、
必ず checkout を実行したディレクトリに追加され、
通常は指定したモジュールと同じ名前になります。
モジュールに別名が定義されている場合、
サブディレクトリは違う名前になりますが心配は要りません。
checkout の処理中、各ファイルを作業領域に展開したと同時に
その相対パスが表示されますから、
この表示でサブディレクトリを確認して下さい
(広域オプション -Q を付けた場合は表示がありません)。
CVS にオプション -r が付けられた場合
(see Global options)、
環境変数 CVSREAD が設定されていた場合
(see Environment variables)、
ファイルが監視されていた場合
(see Watches) を除いて、
checkout が作成するファイルは読み書き可能な状態になります。
checkout で作成したディレクトリの上で、
再度 checkout を実行しても構わないということに注意してください。
これはリポジトリに作成された新しいディレクトリが作業領域に現れるという
点で、update コマンドに -d オプションを付けるのと同様の
効果があります。しかし、update は引数にディレクトリ名を取ります
が、checkout は引数にモジュール名を取ります。checkout を
この様に使うためには、最上位のディレクトリから実行しなければなりません
ので (普段 checkout を実行する場所です)、存在するディレクトリを
更新するために checkout を実行する前に、ディレクトリを最上位の
ディレクトリに変更することを忘れないでください。
checkout コマンドの出力は update output を参照して下さい。
checkout では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-D date
-P オプションも実行されます。
貼り付いたタグ/日付についての詳細は See Sticky tags.
-f
-D date や -r tag と一緒に指定します。
指定したリビジョンが見付からなかった場合、
(そのファイルを無視せずに) 最も新しいリビションを取り出します。
-k kflag
status コマンドを用いて
貼り付いたオプションを見ることができます。
status コマンドの情報は Invoking CVS を参照してください。
-l
-n
modules の
オプション -o で指定されます (see modules)。
-P
-p
-R
-r tag
-P オプションも勝手に実行されます。
貼り付いたタグ/日付についての詳細は See Sticky tags.
さらに checkout では次の固有オプションも使用可能です:
-A
-k オプションの指定を剥がします。
貼り付いたタグ/日付についての詳細は Sticky tags を参照してくだ
さい。
-c
modules の内容を、
アルファベット順に並べて標準出力に出します。
作業ディレクトリは全く変更されません。
-d dir
mkdir dir; cd dir の後に
-d フラグ無しで checkout コマンドを実行することと同じです。
しかし、重要な例外があります。単独の項目を取り出しているときには、出力 に間に空のディレクトリが無いディレクトリが現れた方がとても便利です。こ の場合のみ、CVS は空のディレクトリを避けるためにパス名を "短く" します。
例えば、ファイル bar.c がある foo というモジュールがある
とすると、コマンド cvs co -d dir foo はディレクトリ dir
を作成し、中に bar.c を置きます。同様に、サブディレクトリ
baz があり、その中に quux.c のあるモジュール bar
があるとすると、コマンド cvs -d dir co bar/baz はディレクトリ
dir 作成し、その中に quux.c を置きます。
-N フラグを使うと、この振舞いは抑制されます。上と同じモジュール
の定義で、cvs co -N -d dir foo はディレクトリ dir/foo を
作成してその中に bar.c を置き、cvs co -N -d dir bar/baz
はディクトリ dir/bar/baz を作成してその中に quux.c を置
きます。
-j tag
-j オプションを二つ指定した場合、
最初に指定したリビションから次に指定したリビジョンへの変更を、
作業ディレクトリにマージします。
-j オプションが一つの場合、
その分岐リビジョンから指定したリビジョンへの変更を、
作業ディレクトリにマージします。
分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
-j で指定したリビジョンとの共通の祖先です。
-j オプションに枝を指定する場合、
日付の指定を付加することができます。
このとき選択されるリビジョンは、指定日以前のものに制限されます。
日付の指定は、タグ名の後のコロン (:) に続けて記述します:
-jSymbolic_Tag:Date_Specifier。
-N
-d dir と併用した場合にのみ有効です。
このオプションを指定した場合、
単独モジュールを取り出したときに、
作業ディレクトリのモジュールパスを "短く" しません。例と説明は
-d フラグを参照してください。
-s
-c と同様ですが、全てのモジュールの状態を
アルファベット順に並べて標準出力に出します。
モジュールの状態を設定するために管理用ファイル modules の中で使
われるオプション -s の情報は、See modules.
モジュール tc のコピーを取り出します:
$ cvs checkout tc
モジュール tc を昨日の状態で取り出します:
$ cvs checkout -D yesterday tc
commit は、作業ファイルに対する変更を
リポジトリに組み入れる際に使用します。
格納するファイルを特に指定しなければ、
現在の作業ディレクトリの全ファイルが調査され、
変更が加えられたファイルだけがリポジトリに格納されます。
既定 (もしくは明示的にオプション -R が指定された場合) では、
サブディレクトリのファイルも調査され、変更されていれば格納されます。
オプション -l を指定して、
commit の動作を現在のディレクトリだけに留めることも可能です。
commit は、選択されたファイルが
リポジトリの最新リビジョンであるかどうか確認します。
指定されたファイルの中に update (see update)
が必要なものが一つでもあれば、その旨が表示され、
格納せずに終了します。
commit はあえて update コマンドを呼び出さず、
開発者自身に適切な時期を判断してもらいます。
全てが正常ならば、ログ・メッセージを記すためにエディタが起動されます。
ログ・メッセージは幾つかの処理プログラムに送られると同時に
(modules と loginfo を参照)、
リポジトリ中の RCS ファイルにも記録されます。
このログ・メッセージを参照するには log コマンドを
用いて下さい。log 参照。
オプション -m message で
コマンド行にログ・メッセージを記述したり、
オプション -F file で
ログ・メッセージを記述したファイルを指定すれば、
エディタを起動しなくて済みます。
commit では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-l
-n
-R
-r revision
さらに commit では以下のオプションも使用可能です:
-F file
-f
-f に記述される
標準的な動作とは異なることに注意して下さい。
作業ファイルに何も変更を加えていない場合でも、 無理矢理新しいリビジョンとして格納します。 現在の file のリビジョンを 1.7 と仮定したとき、 次の二つのコマンドの実行結果は同じになります:
$ cvs commit -f file $ cvs commit -r 1.8 file
-f オプションは再帰を使いません (すなわち、-l を含んでい
ます)。全てのサブディレクトリの全てのファイルの新しいリビジョンの格納
を CVS 強制するには、-f -R を使用する必要があります。
-m message
オプション -r を用いて、枝リビジョン (リビジョン番号が
偶数個のドットを含むもの) に格納することができます。
枝リビジョンは rtag か tag コマンドに
オプション -b を指定して作成します
(see Branching and merging)。
そして checkout か update で、
新しく作成した枝からソースを取り出します。
その結果、この作業ソースに対する変更を commit すると、
全て自動的に枝リビジョンの方に追加され、
幹の開発系統は全く影響を受けません。
例えば、バージョン 1.2 の製品に対するパッチを作成する必要があるけれど、
既にバージョン 2.0 の開発が始まっているような場合、
以下のようにします:
$ 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
オプション -r は作業ディレクトリに貼り付けられるため、
これを指定する必要はありません。
例えば、先週取り出したリビジョンを元にして、 極めて実験的な変更をソフトウェアに加えてきたとします。 ここで実験に他の開発者を加えたいけれど、 幹の開発系統を妨げたくない場合は、 その変更点を新しい枝に格納すれば良いでしょう。 すると他の開発者も実験中のコードを取り出して、 CVS の衝突解決の恩恵を全て受けることができます。 このシナリオは次のようになるでしょう:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit
update コマンドで、全てのファイルに
オプション -r EXPR1 が貼り付けられます。
このとき、update コマンドでは
ファイルに対する変更が削除されないことに注意して下さい。
-r が貼り付けられているため、
commit すれば自動的に正しい枝に変更が格納されます。
これは次の手順もあります:
[[ hacked sources are present ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1
しかしこの場合、
変更されていたファイルだけに -r EXPR1 が貼り付けられます。
従って別のファイルを変更して、フラグ -r EXPR1 を付けずに
格納した場合、誤って幹に格納されてしまいます。
他の開発者が実験に参加する際には、 単純に以下のようにして下さい:
$ cvs checkout -r EXPR1 whatever_module
diff コマンドは、
別々のリビジョン間の差異を比較するのに使用します。
特にオプションを指定しない場合、
作業ファイルをその由来となったリビジョンと比較し、
検出された全ての差異を報告します。
ファイル名を指定した場合、そのファイルについてのみ比較します。 ディレクトリを指定した場合、その下の全てのファイルを比較します。
diff の終了状態は他の CVS コマンドと違います。詳細は Exit status を参照してください。
diff では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-D date
-r を参照して下さい。
-k kflag
-l
-R
-r tag
-r は最大二つまで使用できます。
オプション -r を指定しない場合、
作業ファイルをその由来となったリビジョンと比較します。
オプション -r を一つ指定した場合、
指定したリビジョンと作業ファイルとを比較します。
オプション -r を二つ指定した場合、
指定した二つのリビジョンを比較します
(作業ファイルが結果に影響を与えることはありません)。
一つもしくは両方のオプション -r を、前述の
オプション -D date と交換することができます。
以下のオプションは出力の書式を指定します。 意味は GNU diff と同じです。
-0 -1 -2 -3 -4 -5 -6 -7 -8 -9 --binary --brief --changed-group-format=arg -c -C nlines --context[=lines] -e --ed -t --expand-tabs -f --forward-ed --horizon-lines=arg --ifdef=arg -w --ignore-all-space -B --ignore-blank-lines -i --ignore-case -I regexp --ignore-matching-lines=regexp -h -b --ignore-space-change -T --initial-tab -L label --label=label --left-column -d --minimal -N --new-file --new-line-format=arg --old-line-format=arg --paginate -n --rcs -s --report-identical-files -p --show-c-function -y --side-by-side -F regexp --show-function-line=regexp -H --speed-large-files --suppress-common-lines -a --text --unchanged-group-format=arg -u -U nlines --unified[=lines] -V arg -W columns --width=columns
次の実行例は、backend.c のリビジョン 1.14 と 1.19 間の差分を、
unidiff 形式 (フラグ -u) で出力します。
またキーワード置換を止めるために -kk を指定し、
キーワード置換による差分を無視します。
$ cvs diff -kk -u -r 1.14 -r 1.19 backend.c
タグ RELEASE_1_0 が付けられたファイルの集合から、 実験用の枝 EXPR1 が派生していると仮定します。 この枝に加えられた変更を見るには、次のようにします:
$ cvs diff -r RELEASE_1_0 -r EXPR1
次の実行例では、二つのリリース間の差分を context 形式で出力します:
$ cvs diff -c -r RELEASE_1_0 -r RELEASE_1_1 > diffs
ChangeLogs を運用している場合、 変更を格納する前に次の行のようなコマンドを実行すると、 ChangeLogs の記載事項を入力するのに役立つでしょう。 作業ファイルに加えた変更点のうち、格納していないもの全てを表示します。
$ cvs diff -u | less
このコマンドは checkout の変形で、
module のソースのコピーを、
CVS の管理用ディレクトリを除いた状態で取り出します。
例えば出荷用のソースを準備するときなどに export を使います。
出荷したソースを後で再現できることを確認するため、使用の際には
(-D か -r による) 日付かタグの指定が要求されます。
cvs export に -kv を指定すると便利です。
この指定で全てのキーワードが展開されるため、
出荷先で import されても
キーワードによるリビジョン情報が失われません。
しかしモジュールがバイナリ・ファイルを含む場合は、
正しく処理されない可能性があるので注意が必要です。
また -kv を使用した後では、ident コマンド (RCS を
構成するコマンドの一つです--ident(1) を参照) を使用して、
キーワード文字列を抜き出すことができません。
従って ident を使用するつもりなら、
-kv を指定してはいけません。
export では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-D date
-f
-l
-n
-R
-r tag
さらに (checkout と export で共通な)
以下のオプションも使用可能です:
-d dir
-k subst
-N
-d dir と併用した場合にのみ有効です。
CVS がこのフラグを扱う方法の完全な詳細は See checkout options.
$CVSROOT/CVSROOT/history
CVS は、checkout, commit, rtag,
update, release コマンドの実行履歴を、
ファイル history に記録しています。
history を使って、様々な形式で
この情報を表示することができます。
ログを記録したい場合は、ファイル $CVSROOT/CVSROOT/history を
作成する必要があります。
警告: history は、-f, -l, -n,
-p を通常の CVS コマンドで用いられるものとは
異なる意味で使用しています (see Common options)。
次のオプション (コマンド書式で -report の部分) によって、
生成する報告の種類を決定します:
-c
commit (つまりリポジトリの変更)
について報告します。
-e
-x を指定する
ことと等価です。もちろん、-e は将来のバージョンの CVS に加
えられた記録種別も含みます。特定の記録種別だけを扱うことのできるスクリ
プトを書いているなら、-x を指定する方が良いでしょう。
-m module
-m をコマンド行に並べても構いません)。
-o
-T
-x type
以下のコマンドには、各々一つの記録種別を割り当てています:
F
O
E
T
更新の結果は、以下の四つの記録種別のうちのどれかになります:
C
G
U
W
格納の結果は、以下の三つの記録種別のうちのどれかになります:
A
M
R
次のオプション (コマンド書式で -flags の部分) によって、
報告の範囲を限定もしくは拡大します。引数はありません:
-a
history を実行した人物の情報のみを表示します)。
-l
-w
history を実行したのと同じ作業ディレクトリから行われた
変更に関する記録のみを表示します。
次のオプション (コマンド書式で -options args の部分) は、
引数に基づいて報告の範囲を限定します:
-b str
-D date
-D date は date 以前の
最新リビジョンを選択しますから、少し意味が違います。
-p repository
-p をコマンド行に並べても構いません。)
-r rev
-t tag
-r の場合よりもかなり高速です。
-u name
import を用いて、外部の供給元 (例えばソース・ベンダー)
からのソース配布物全体を、自分のリポジトリに取り入れることができます。
リポジトリを最初に作成する場合と、外部の供給元がモジュールを
大幅に更新した場合の両方でこのコマンドを用います。
この件については See Tracking sources.
repository には、リポジトリにするディレクトリの名前 (もしくは、ディレクトリへのパス) を、 CVS のルート・ディレクトリからの相対パス名で指定します。 指定したディレクトリが存在しなくても自動的に作成されます。
(前回の import から) ずっと変更を加えてきたリポジトリに対し、
ソースを更新するために import を用いると、
互いの開発系統間で衝突が発生したファイル全てが報告されます。
この時 import から具体的な指示がありますので、
それを参考にしながら checkout -j を使って変更点を取り入れて下さい。
CVS は無視するように設定されたファイルは (see cvsignore)、
取り込まず、無視したことを示すため
I に続けてファイル名を表示します
(出力に関する完全な説明は see import output)。
$CVSROOT/CVSROOT/cvswrappers が存在する場合、
このファイルの記述に合致するファイルやディレクトリは
各々一括して扱われ、リポジトリに取り込まれる前に、
適切なフィルタが適用されます。See Wrappers.
外部からのソースは第一層の枝、既定だと 1.1.1 に保存されます。 以降の更新は全てこの枝の葉となります。 例えば最初に取り込んだソース集合のファイルは リビジョン 1.1.1.1 になり、次の取り込みで そのファイルが更新された場合には 1.1.1.2 となり、以下同様に続きます。
少なくとも次の三つの引数を指定する必要があります。
まずソース集合を識別するために repository が必要です。
次の vendortag は枝全体 (例えば 1.1.1) を示すタグ名です。
そして import を実行する度に作成される葉のうち、
どの葉のファイルかを識別するため、
最低一つの releasetag を指定しなくてはいけません。
import はそれを起動したディレクトリを変更 しない という
ことに注意してください。特に、ディレクトリを CVS の作業ディレクト
リとして設定しないことに注意してください。もし作業をしたいなら、まずソー
スを取り込んで、それから違うディレクトリに取り出してください
(see Getting the source)。
import では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-m message
以下のような追加の特別なオプションがあります。
-b branch
-k subst
-k に使用できる設定の一覧は Substitution modes 参照。
-I name
name には、ファイル .cvsignore と同じ
ファイル名形式が使用できます。See cvsignore.
-W spec
spec には、ファイル .cvswrappers と同じ
ファイル名形式が使用できます。See Wrappers.
import の進行状況を知らせるために、
処理中のファイル名が一行ずつ表示され、
行頭にはファイルの状態を示す文字が付加されます:
U file
N file
C file
I file
L file
cvs import はシンボリック・リンクを無視します。いろんな人が定期
的にこの振舞いは変更されるべきだと提案しますが、どれに変更されるべきか
についての同意があるとすれば、それは明らかでないように思われます。
(管理用ファイル modules の各種オプションを checkout や update
等でシンボリック・リンクを再生成するために使うことができます。
see modules。)
ファイルのログ情報を表示します。以前の log は
RCS のコマンド rlog を呼び出していましたが、
現在はそうではありません。しかしこのような経緯から、
このコマンドの出力やオプションは、
他の CVS コマンドとは異なったものになっています。
このコマンドの出力には、RCS ファイルの所在、 先頭リビジョン (幹の最新リビジョン)、 全てのタグ名などが含まれます。 各リビジョンに対しては、リビジョン番号、格納者、 追加/削除された行数、ログ・メッセージが表示されます。 また時間は全て協定世界時 (UTC) で表示されます。 (CVS の他の部分では地方時間帯による時刻を表示します。)
警告: log は -R を CVS 普通の使用と衝突す
る方法で使います (see Common options)。
オプションを指定しなければ、log は利用できる全ての
情報を表示します。つまりオプションは全て出力を制限するものです。
-b
-d dates
-D オプションと同じです (see Common options)。
それを次のように組み合わせて、格納日時の範囲を表現します:
d1<d2
d2>d1
<d
d>
d<
>d
d
> や < の後に = を付ければ、端を含まない
範囲指定ではなく、端を含むような範囲指定が可能です。
要素の区切りがセミコロン ; であることに注意して下さい。
-h
-l
-N
-R
-rrevisions
rev1:rev2
:rev
rev:
branch
branch1:branch2
branch.
リビジョンを指定せず -r だけを指定した場合、
既定の枝、通常は幹の最新リビジョンを選択します。
従って -r と引数との間に空白を入れないようにして下さい。
-s states
-t
-h の情報に、ファイルの説明文を追加して表示します。
-wlogins
-w と引数との間に空白を入れないようにして下さい。
log は、オプション -d, -s, -w の
全てに適合し、かつ -b, -r のいずれかに適合した
リビジョンに関する情報を表示します。
使用例を募集しています。
二つのリリース間の差分を、
Larry Wall の patch(1) ファイル形式で生成します。
この出力を直接 patch プログラムに食わせて、
古いリリースを新しいリリースに更新できます。
(これは作業ディレクトリを必要とせず、直接リポジトリを操作する
数少ない CVS コマンドの一つです。)
このコマンドの実行結果は標準出力に送られます。
一つないし二つのリビジョンか日付の組み合わせを
(標準オプション -r や -D を用いて)
指定することができます。
リビジョンか日付を一つだけ指定した場合、
指定したものと RCS ファイルの先頭リビジョンとの差分が
パッチ・ファイルとして出力されます。
ソフトウェア配布物が複数のディレクトリから構成される場合、
別のディレクトリに置かれた古いソースを参照するために、
patch コマンドにオプション -p を
指定する必要があるかも知れません。
rdiff では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-D date
-f
-l
-R
-r tag
さらに以下のオプションも使用可能です:
-c
-s
-t
-u
patch プログラムは unidiff 形式を扱えないので、
パッチをネットに投稿するつもりならば、
-u を使用しない方が賢明でしょう。
-V vn
foo@example.net から、
コンパイラ tc をリリース 1.2 から 1.4 へ更新したい、
というメールを受け取ったと仮定します。
手元にそんなパッチがない場合でも、
CVS なら次のようなコマンドを使って簡単に対応できます:
$ cvs rdiff -c -r FOO1_2 -r FOO1_4 tc | \ $$ Mail -s 'The patches you asked for' foo@example.net
リリース 1.3 のバグ修正用に枝 R_1_3fix を作成し、
修正後のリリース 1.3.1 にタグ R_1_3_1 を付けたと仮定します。
この枝に対して、修正版以降に加えられた開発の概略を知りたい場合は、
次のようなコマンドを使います:
$ 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
このコマンドは cvs checkout の効果を安全に消し去ります。
CVS はファイルをロックしないため、
このコマンドが絶対に必要なわけではありません。
作業ディレクトリを単に削除したいなら、それでも構いません。
ただしこの場合、うっかりすると変更内容を失う恐れがあります。
またファイル history (see history file) にも、
作業ディレクトリを放棄したという情報が残りません。
これらの問題を避けるためにも cvs release を使用して下さい。
このコマンドは、未格納の変更点が残ってないかどうか調べます。
次に CVS の作業ディレクトリのすぐ上で実行しているかどうか調べます。
さらに作業ディレクトリに記録されたリポジトリが、
モジュールに定義されているリポジトリと等しいかどうか調べます。
上記全ての条件が満たされた場合にだけ、
(作業ディレクトリを故意に放棄した証拠として)
CVS の履歴ログ に cvs release の実行記録が残されます。
release ではオプションが一つだけ利用できます:
-d
警告: release コマンドは
全てのディレクトリとファイルを再帰的に削除していきます。
これには重篤な副作用があり、作業ディレクトリに作成したけれど、
リポジトリには追加してないディレクトリ全てが、
(add コマンド使って。see Adding files)
何の表示も無く削除されます--その中身が空でなくても!
release によって作業ディレクトリを放棄する前に、
最新でないファイルそれぞれについて一行ずつ状態を表示します。
警告: 作成はしたけれど、add コマンドを用いて
(see Adding files) CVS のディレクトリ階層に
加えてないディレクトリは、全て中身があっても完全に無視され
(-d が指定されていれば削除され) ます。
U file
P file
U と P は同じです。)
A file
R file
M file
? file
-I オプションの説明の参照と、see cvsignore)。
作業ディレクトリを削除すれば、このファイルは失なわれます。
ディレクトリ tc の放棄判定をしてから作業ディレクトリを削除しま
す。
$ cd .. # cvs release は作業ディレクトリの
# すぐ上で実行しなくてはいけません。
$ cvs release -d tc
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory `tc': y
$
共有するリポジトリから作業コピーを取り出した後でも、
他の開発者はリポジトリのソースを変更し続けるでしょう。
開発工程の然るべき時に update コマンドを使えば、
最後の checkout や update 以降の、
どのリビジョンでも取り入れることができます。
update では、以下の標準オプションが利用できます
(完全な記述は see Common options):
-D date
-P オプションも実行されます。
貼り付いたタグ/日付についての詳細は Sticky tags.
-f
-D date や -r tag と一緒に指定します。
指定したリビジョンが見付からなかった場合、
(そのファイルを無視せずに) 最も新しいリビションを取り出します。
-k kflag
status コマンドを用いて
貼り付いたオプションを見ることができます。
status コマンドの情報は Invoking CVS を参照してください。
-l
-P
-p
-R
-r rev
-P オプションも勝手に実行されます。
貼り付いたタグ/日付についての詳細は see Sticky tags.
さらに update では次の固有オプションも使用可能です。
-A
-k オプションの指定を剥がします。
貼り付いたタグ/日付についての詳細は Sticky tags.
-d
update の対象となります。
最初に checkout した後にリポジトリに作成された、
新たなディレクトリを取り出すときに使用します。
しかし残念なことに副作用があります。
作業ディレクトリを作成するときに、
(モジュール名を利用したり、
コマンド行で望みのファイルやディレクトリを明示したりして)
特定のディレクトリを故意に避けていた場合、
-d を使用すると余計なディレクトリまで作成されてしまいます。
-I name
update の際に、
name と一致するファイル名が無視されます。
無視したいファイルが複数あるときは、
コマンド行に -I を必要なだけ並べても構いません。
全てのファイルを無視したくない場合は、
-I ! と指定して下さい。
CVS にファイルを無視させる他の方法は See cvsignore.
-Wspec
update の際に、
フィルタを掛けるべきファイル名を指定します。
このオプションは繰り返し利用することができます。
.cvswrappers と同じ形式を用いて、
spec にファイル名を指定します。See Wrappers.
-jrevision
-j オプションを二つ指定した場合、
最初に指定したリビションから次に指定したリビジョンへの変更を、
作業ディレクトリにマージします。
-j オプションが一つの場合、
その分岐リビジョンから指定したリビジョンへの変更を、
作業ディレクトリにマージします。
分岐リビジョンとは、作業ディレクトリの元になったリビジョンと、
-j で指定したリビジョンとの共通の祖先です。
-j オプションに枝を指定する場合、
日付の指定を付加することができます。
このとき選択されるリビジョンは、指定日以前のものに制限されます。
日付の指定は、タグ名の後のコロン (:) に続けて記述します:
-jSymbolic_Tag:Date_Specifier。
update や checkout の進行状況を知らせるために、
処理中のファイル名が一行ずつ表示され、
行頭にはファイルの状態を示す文字が付加されます:
U file
P file
U と同様ですが、CVS サーバはファイル全体ではなく、パッチを
送ります。2つ共結果は同じです。
A file
commit の実行が必要な状態を示します。
つまりファイルの格納を忘れないように注意を促しています。
R file
commit の実行が必要な状態を示します。
つまりファイルの格納を忘れないように注意を促しています。
M file
M は、ファイルに対する次の二つの修正状態のうちの一方を示します。
一つ目は、リポジトリの当該ファイルが修正されていないため、
このファイルはあなたが最後に見たときと同じ状態にある場合です。
二つ目は、作業コピーと同様に、
リポジトリの当該ファイルも修正されていたため、
これらを作業ディレクトリでマージした結果、
衝突することなく正常に処理された場合です。
ファイルのマージが行われるとその旨が表示され、
(update が実行される前と同じ内容の)
作業ファイルのバックアップ・コピーが生成されます。
update の実行中にそのファイルの名前もちゃんと表示されます。
C file
.#file.revision という名前で、
作業ディレクトリに保存されます。ここで revision は、
ファイルの修正を開始した時点での RCS
リビジョンです。Conflicts example の説明を参考にして
衝突を解決して下さい。
(.# で始まるファイルを数日間利用しなかった場合、
自動的に削除するシステムがあることに注意して下さい。
元のファイルを保存したい場合は名前を変更すると良いでしょう。)
VMS ではファイル名の先頭に、
.# ではなく __ を使用します。
? file
-I オプションの説明及び see cvsignore を参照)。
この付録は、それぞれのコマンドや機能が詳しく説明されているところへの参
照とともに、CVS の実行のしかたを説明します。他の参照は、cvs
--help コマンドを実行するか、Index を参照してください。
CVS コマンドは以下の様になります:
cvs [ global_options ] command [ command_options ] [ command_args ]
標準オプション:
--allow-root=rootdir
-a
-b
-d root
-e editor
-f
~/.cvsrc ファイルを読み込みません。Global options 参照。
-H
--help
-l
-n
-Q
-q
-r
-s variable=value
-T tempdir
-t
-v
--version
-w
-x
-z gzip-level
キーワード展開モード (see Substitution modes):
-kkv $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp $ -kkvl $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ -kk $Id$ -kv file1,v 1.1 1993/12/09 03:21:13 joe Exp -ko 非展開 -kb 非展開、ファイルはバイナリ
キーワード (see Keyword list):
$Author: joe $ $Date: 1993/12/09 03:21:13 $ $Header: /home/files/file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ $Id: file1,v 1.1 1993/12/09 03:21:13 joe Exp harry $ $Locker: harry $ $Name: snapshot_1_14 $ $RCSfile: file1,v $ $Revision: 1.1 $ $Source: /home/files/file1,v $ $State: Exp $ $Log: file1,v $ Revision 1.1 1993/12/09 03:30:17 joe Initial revision
コマンド、コマンドのオプション、コマンドの引数:
add [options] [files...]
-k kflag
-m msg
admin [options] [files...]
-b[rev]
-cstring
-ksubst
-l[rev]
-mrev:msg
-orange
-q
-sstate[:rev]
-t
-tfile
-t-string
-u[rev]
annotate [options] [files...]
-D date
-f
-l
-R
-r tag
checkout [options] modules...
-A
-c
-D date
-d dir
-f
-j rev
-k kflag
-l
-N
-n
-P
-p
-R
-r tag
-s
commit [options] [files...]
-F file
-f
-l
-m msg
-n
-R
-r rev
diff [options] [files...]
-c です。
-D date1
-D date2
-l
-N
-R
-r rev1
-r rev2
edit [options] [files...]
-a actions
actions, edit,
unedit, commit, all, none のどれかです。
Editing files 参照。
-l
-R
editors [options] [files...]
-l
-R
export [options] modules...
-D date
-d dir
-f
-k kflag
-l
-N
-n
-P
-R
-r tag
history [options] [files...]
-a
-b str
-c
-D date
-e
-l
-m module
-n module
-o
-r rev
-T
-t tag
-u user
-w
-x types
TOEFWUCGMAR から1つ以上指定しま
す。history options 参照。
-z zone
import [options] repository vendor-tag release-tags...
-b bra
-d
-k kflag
-m msg
-I ign
-W spec
init
log [options] [files...]
-b
-d dates
-h
-l
-N
-R
-rrevs
-s states
-t
-wlogins
login
logout
rdiff [options] modules...
-c
-D date
-f
-l
-R
-r rev
-s
-t
-u
-V vers
release [options] directory
-d
remove [options] [files...]
-f
-l
-R
rtag [options] tag modules...
-a
-b
-D date
-d
-F
-f
-l
-n
-R
-r rev
status [options] files...
-l
-R
-v
tag [options] tag [files...]
-b
-c
-D date
-d
-F
-f
-l
-R
-r rev
unedit [options] [files...]
-a actions
edit, unedit, commit,
all, none のどれかです。Editing files 参照。
-l
-R
update [options] [files...]
-A
-D date
-d
-f
-I ign
-j rev
-k kflag
-l
-P
-p
-R
-r tag
-W spec
watch [on|off|add|remove] [options] [files...]
add/remove: 動作の通知を追加削除します。Getting Notified 参照。
-a actions
edit, unedit,
commit, all, none のどれかです。
Editing files 参照。
-l
-R
watchers [options] [files...]
-l
-R
リポジトリ中のディレクトリ $CVSROOT/CVSROOT に、
CVS を支援する多くのファイルが置かれます。
これらのファイルが無いと CVS の能力が制限されてしまいますが、
適切に設定すれば種々の操作を簡略化することができます。
これらを編集する方法は Intro administrative files 参照。
これらの内で最も重要なファイルは modules で、
リポジトリ内のモジュールを定義します。
管理用ファイル modules には、
ソース・コードの集合体の名前の定義を記述します。
新たな定義を CVS に理解させるには、
CVS を用いてファイル modules を修正して下さい
(add, commit など普通のコマンドを使用します)。
ファイル modules には、モジュールの定義だけでなく、
空白行や註釈行 (# で始まる行) も記述できます。
またバックスラッシュ (\) を行の最後に加えて、
長い行を次の行にまで続けることができます。
モジュールには3つの種類があります: 別名モジュール、一般モジュール、ア
ンドモジュールです。それらの違いはリポジトリのファイルの作業ディレクト
リへの割り付け方法です。以下の全ての例では、最上位のリポジトリには
first-dir というディレクトリがあり、そこには file1 と
file2 というファイルがあり、sdir というディレクトリがあ
ります。first-dir/sdir には sfile というファイルがありま
す。
別名モジュールが一番簡単な種類のモジュールです:
mname -a aliases...
-a フラグは単純に別名の定義を行います:
CVS に (コマンドの引数として) mname が与えられると、
aliases に記述された名前の一覧を代りに使用します。
aliases は他のモジュール名もしくはパス名から構成します。
aliases にパス名を使用した場合、
CVS の引数にパス名を明示した場合と同じく、
checkout したとき途中の全てのディレクトリが
作業ディレクトリに作成されます。
例えば、モジュールファイルの内容が以下のようであると:
amodule -a first-dir
次の2つのコマンドは等価です:
$ cvs co amodule $ cvs co first-dir
そして、それらは以下のような出力を出します:
cvs checkout: Updating first-dir U first-dir/file1 U first-dir/file2 cvs checkout: Updating first-dir/sdir U first-dir/sdir/sfile
mname [ options ] dir [ files... ]
mname dir となります。
これはディレクトリ dir の全てのファイルを、
モジュール mname と定義します。
dir は ($CVSROOT から)
ソースのあるディレクトリへの相対パス名です。
この場合にソースを取り出すと、
mname というディレクトリだけが作業ディレクトリに作成されます。
つまり dir が複数のディレクトリ階層から成るパス名であっても、
既定では途中のディレクトリ階層は使用されません。
例えば、モジュールが以下で定義されていると:
regmodule first-dir
regmodule は first-dir のファイルを含みます:
$ cvs co regmodule cvs checkout: Updating regmodule U regmodule/file1 U regmodule/file2 cvs checkout: Updating regmodule/sdir U regmodule/sdir/sfile $
dir の後で明示的にモジュールを指定することで、特定のファイルをディ レクトリ dir から選択することができます。例:
regfiles first-dir/sdir sfile
この定義により、regfiles モジュールを取得すると、一覧に挙げられたファ
イルがある単独のディレクトリ regfiles を作成し、それは CVS
のソースリポジトリのより深いディレクトリから来ています。
$ cvs co regfiles U regfiles/sfile $
モジュール定義は定義に &module を含めることで他のモジュー
ルを参照することができます。
mname [ options ] &module...
そうすると、モジュールを取得したときに、モジュールのあるディレクトリで、 それぞれのモジュールのためのサブディレクトリを作成します。
ampermod &first-dir
そうすると、checkout は ampermod ディレクトリを作成し、それには
first-dir というディレクトリがあり、それは今度は自分の全てのファ
イルとディレクトリを持っています。例えば、コマンド
$ cvs co ampermod
は以下のファイルを作成します:
ampermod/first-dir/file1 ampermod/first-dir/file2 ampermod/first-dir/sdir/sfile
ここには、一つ癖/バグがあります: CVS が印字するメッセージは
ampermod を省略するので、ファイルが取り出された位置を正確に表示
しません。
$ cvs co ampermod cvs checkout: Updating first-dir U first-dir/file1 U first-dir/file2 cvs checkout: Updating first-dir/sdir U first-dir/sdir/sfile $
このバグっぽい動作に頼らないでください。CVS の将来のリリースでは 修正されているかもしれません。
別名モジュールは、除外されるべき各ディレクトリ名の前に驚嘆符
(!) を付けることで、特定のディレクトリを除外することができます。
例えば、モジュールファイルが以下のようになっていると:
exmodule -a !first-dir/sdir first-dir
モジュール exmodule を取り出すと、サブディレクトリ
first-dir/sdir にあるファイル以外の全てを取り出します。
標準モジュールとアンドモジュールのどちらもオプションを含むことができ、 それはモジュールの追加情報を提供します。
-d name
-e prog
-i prog
commitinfo, loginfo, veryfymsg ファイルは格納時に
プログラムを呼ぶ他の方法を提供します。
-o prog
-s status
cvs checkout
-s で印字されると、モジュールが主モジュール状態に従って並び換えられ、
それからモジュール名に従って並び換えられます。このオプションは他に意味
はありません。状態以外のいくつかのことにこのオプションを使うことができ
ます: 例えば、このモジュールに責任のある人の一覧などです。
-t prog
rtag でタグ付けされたとに常に実行される
プログラム prog を指定します。prog は2つの引数と共に実行さ
れます: モジュール名と rtag に指定されたタグ名です。tag
が行われたときは実行されません。一般的に、taginfo の方が良い解決法です
(see user-defined logging)。
-u prog
cvs が行なわれた
ときに常に実行されるプログラム protg を指定します。prog は
単独の引数、このモジュールのソースリポジトリのフルパスとともに実行され
ます。
Wrapper とは操作中のファイル名に基づいて設定を制御することを可能にする
CVS の機能のことです。設定は、バイナリ・ファイルには -k で、
マージできないテキスト・ファイルには -m です。
また、非バイナリ・ファイルを更新するときの
マージ方針について記述するオプション -m があります。
MERGE は CVS が通常用いる方法です:
ファイルをマージしようとすることを意味します。COPY は cvs
update はファイルのマージを拒否するという意味で、-kb でバイナ
リとして指定されたファイルにもそうなります (ただし、バイナリとして指定
されていれば、-m 'COPY' を指定する必要はありません。
CVS は使用者に2つのバージョンのファイルを提供し、必要な変更を挿入する
ために使用者が CVS の外の機構を使用することを要求します。
警告: CVS 1.9 以前では COPY を使わないでくださ
い--それらのバージョンの CVS はあるバージョンを別の物の上にコピー
し、以前の内容を消し去ってしまいます。
Wrapper オプション -m は更新時のマージ方針にのみ影響し、
ファイルの格納方法には影響しません。
バイナリ・ファイルの詳細は Binary files 参照。
管理用ファイル cvswrappers の基本的な書式:
ワイルドカード [オプション 値][オプション 値]... 利用できるオプションを以下に挙げます。 -m マージ方針 値: MERGE か COPY -k キーワード展開 値: 置換モード 値は以下のように単引用符で囲みます。
例えば、.exe で終わるファイルをバイナリとして扱いながら、
ディレクトリを取り入れます:
cvs import -I ! -W "*.exe -k 'b'" first-dir vendortag reltag
ファイル modules 中の -i フラグは、
ファイルが格納された時に特定のプログラムを実行するのに用いられます
(see modules)。
この節で説明するファイルは、
ファイルの格納時にプログラムを実行するための、
より柔軟な方法を提供します。
格納時に実行できるプログラムは三種類に分けられます。 これらのプログラムはリポジトリ中のファイルに記述されます。 次に示すのは、 ファイル名と、対応するプログラムに必要な機能を示したものです。
commitinfo
verifymsg
rcsinfo ファイルと組合せて使うと
とても役に立ちます (see rcsinfo)。
editinfo
rcsinfo ファイルと
組み合せることで、より便利になります (see rcsinfo)。(旧式)
loginfo
commitinfo, loginfo, rcsinfo, editinfo,
verifymsg, などのような管理ファイルには共通の書式があります。
各ファイルの目的は後述します。
ここでは共通の構文について説明します。
各行は次の要素から構成されます:
空白行は無視されます。
また # という文字で始まる行は註釈行として扱われます。
残念ながら、長い行を複数行に分割することはできません。
リポジトリの中のディレクトリに合致した最初の正規表現が使用されます。 行の残りの部分は、ファイル名もしくはコマンド行として適切に使用されます。
cvs commit を実行する直前に必ず実行したいプログラムを、
ファイル commitinfo に記述します。
修正、追加、削除されたファイルを格納しても良いかどうか、
このプログラムを用いて格納前に判断します。
例えば、変更されたファイルがあなたのサイトの
コーディング・スタイルの標準に従っているか確かめることもできます。
前に書いたように、commitinfo の各行は、第一項の正規表現、
残りの部分のコマンド行形式から構成されます。
コマンド行の部分には、
プログラム名と適切な数の引数とを記述することができます。
また実行の際には、リポジトリのフルパスと
格納しようとするファイル名 (追加, 削除, 修正されたファイル名)
がコマンド行の最後に与えられます。
リポジトリ中のディレクトリと正規表現とが合致する最初の行が実行されます。 そしてコマンドが非零で終了した場合は、格納が中止されます。
第一項が DEFAULT である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。
第一項が ALL である行全てが、
最初に合致した正規表現または DEFAULT に加えて適用されます。
注意: CVS が別のマシンのリポジトリを利用している場合、
commitinfo に記述された行は、
クライアント側ではなく別のマシン (サーバ) 側で実行されます
(see Remote repositories)。
一旦ログメッセージを入力すると、bug ID などの特定の内容を調べるために
そのメッセージを評価することができます。ログメッセージを検証するための
プログラムを指定するために verifymsg ファイルを使用することがで
きます。このプログラムは入力されたメッセージに必要なフィールドがあるか
どうかを調べる簡単なスプリプトでも良いでしょう。
verifymsg ファイルは、ログメッセージの雛型を指定するために使う
ことのできる rcsinfo ファイルと一緒に使用されたときにとても役に
立つことが多いです。
verifymsg ファイルは正規表現とコマンド行の雛型から成ります。雛
型はプログラム名を含んでいなければならず、任意の数の引数を取ることがで
きます。現在のログメッセージ雛型ファイルへのフルパスが雛型の最後に追加
されます。
一つ注意しなければならないのは、ALL キーワードは使えないという
ことです。一行以上合致した場合、最初のものが使われます。これはディレク
トリで既定の検証スクリプトを指定して、サブディレクトリで上書きするとき
に役に立ちます。
リポジトリ名がこのファイルのどの正規表現にも合致しなければ、
DEFAULT が指定されていると、それが使用されます。
検証スクリプトが非零の値で終了すれば、格納は中止されます。
検証スクリプトはログメセージを変更できないことに注意してください。単に 受け入れるか拒否するかのどちらかです。
以下は、verifymsg ファイルのちょっとしたばかげた例と、それに対
応する rcsinfo ファイル、ログメッセージの雛型と検証スクリプトで
す。まず、ログメッセージの雛型です。常に bug-id 番号をログメッセージの
最初の行に記録します。ログメッセージの残りのテキストは自由に書いたもの
です。以下の雛型ファイルは /usr/cvssupport/tc.template にありま
す。
BugId:
スクリプト /usr/cvssupoort/bugid.verify はログメッセージの評価
に使われます。
#!/bin/sh
#
# bugid.verify filename
#
# Verify that the log message contains a valid bugid
# on the first line.
#
if head -1 < $1 | grep '^BugId:[ ]*[0-9][0-9]*$' > /dev/null; then
exit 0
else
echo "No BugId found."
exit 1
fi
verifymsg ファイルには以下の行があります:
^tc /usr/cvssupport/bugid.verify
rcsinfo ファイルには以下の行があります:
^tc /usr/cvssupport/tc.template
注意: editinfo 機能は旧式になっています。ログメッセージ
の既定のエディタを設定するためには、EDITOR 環境変数
(see Environment variables) か -e 広域オプション
(see Global options) を使用してください。ログメッセージを評価する
ための verifymsg 機能を使うための情報は verifymsg を参照
してください。
いつも同じ形式でログ・メッセージを記録したい場合に、
ログ・メッセージを編集するプログラムを editinfo に
指定することができます。
指定するプログラムは、
ログ・メッセージを必ず一定のスタイルに保つ特別製エディタや、
エディタを呼び出して、入力されたメッセージが必要項目を
満たすかどうか確認する簡単なシェル・スクリプトでも良いでしょう。
合致する行が editinfo になかった場合、
環境変数 $CVSEDITOR に指定されたエディタを使用します。
この環境変数が設定されていない場合には、
環境変数 $EDITOR に指定されたエディタを代わりにします。
そしてこの環境変数も設定されていない場合は、
既定のものが使われます。Committing your changes 参照。
rcsinfo にログ・メッセージの雛型を指定すると、
より効果的に editinfo を利用できるでしょう。
editinfo の各行は、第一項の正規表現、
残りの部分のコマンド行形式から構成されます。
コマンド行の部分には、
プログラム名と適切な数の引数とを記述することができます。
また実行の際には、ログ・メッセージの雛型へのフルパス
がコマンド行の最後に与えられます。
ALL が利用できないことに注意して下さい。
合致する行が複数あった場合は、最初の行が実行されます。
これは、モジュールの編集スクリプトが設定されていて、
サブディレクトリでは別のものを使用したい場合を考慮しています。
第一項が DEFAULT である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。
編集スクリプトが非零で終了した場合は、格納が中止されます。
注意: CVS が別のマシンのリポジトリを利用している場合や、
cvs commit の -m または -F オプションを
使用した場合、editinfo は参照されません。
この問題を解決する良い方法は今のところありません。
代わりに verifymsg を使ってください。
次に、ちょっとアホくさい editinfo の使用例を、
対応する rcsinfo、ログ・メッセージの雛型、
エディタ・スクリプトと併わせて紹介します。
まずログ・メッセージの雛型ですが、
最初の行に必ずバグ番号を記録するように促し、
残りは自由に記述してもらいます。
この雛型は /usr/cvssupport/tc.template に置くことにします。
BugId:
ログ・メッセージを編集するため、
次のスクリプト /usr/cvssupport/bugid.edit を使用します。
#!/bin/sh
#
# bugid.edit filename
#
# Call $EDITOR on FILENAME, and verify that the
# resulting file contains a valid bugid on the first
# line.
if [ "x$EDITOR" = "x" ]; then EDITOR=vi; fi
if [ "x$CVSEDITOR" = "x" ]; then CVSEDITOR=$EDITOR; fi
$CVSEDITOR $1
until head -1|grep '^BugId:[ ]*[0-9][0-9]*$' < $1
do echo -n "No BugId found. Edit again? ([y]/n)"
read ans
case ${ans} in
n*) exit 1;;
esac
$CVSEDITOR $1
done
ファイル editinfo には次の行を記述します:
^tc /usr/cvssupport/bugid.edit
ファイル rcsinfo には次の行を記述します:
^tc /usr/cvssupport/tc.template
loginfo を用いて、
cvs commit によるログ情報の送り先を管理します。
各行の第一項には正規表現が記述され、
行の残りの部分はフィルタでなくてはいけません。
変更を加えたディレクトリを
$CVSROOT からの相対パスで表わしたものと、
各行の正規表現が合致するかどうか試されます。
合致した場合は、
その行の残りの部分であるフィルタ・プログラムの標準入力に、
ログ情報を与えます。
第一項が DEFAULT である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。
第一項が ALL である行全てが、
最初に合致した正規表現または DEFAULT に加えて適用されます。
正規表現が合致する最初の行が実行されます。
ファイル loginfo の構文についての記述は See commit files.
使用者はフィルタの一部としてフォーマット文字列を指定できます。文字列は
% の後に空白か、単独のフォーマット文字、もしくは分離器
{ と } に囲まれたいくつかのフォーマット文字が続いた物
です。フォーマット文字は:
フォーマット文字列に現れた他の全ての文字は空のフィールドに展開されます (フィールドを分離するコンマはまだ提供されされています。)
例えば、有効なフォーマット文字列は %, %s, %{s},
%{sVv} などです。
出力は空白で区切られた語からなる文字列になります。下位互換のために、最
初の語はリポジトリ名になります。残りの語はフォーマット文字列で要求され
た情報をコンマで分けたリストです。例えば、/u/src/master がリポ
ジトリで %{sVv} がフォーマット文字列、3つのファイル
(ChangeLog, Makefile, foo.c) が修正されていると、出力は:
/u/src/master ChangeLog,1.1,1.2 Makefile,1.3,1.4 foo.c,1.12,1.13
別の例として、%{} ではリポジトリ名のみが作成されます。
注意: CVS が別のマシンのリポジトリを利用している場合、
loginfo はクライアント側ではなく、別のマシン
(サーバ) 側で実行されます
(see Remote repositories)。
ここで示す loginfo ファイルと付属のシェル・スクリプトは、
格納時に次のような動作をします。
まず全てのログ・メッセージを
$CVSROOT/CVSROOT/commitlog に追記します。
次に全ての管理用ファイル (CVSROOT 内) の
格納時のログを /usr/adm/cvsroot-log に追記します。
prog1 ディクトリへの格納は ceder にメールで送られます。
ALL /usr/local/bin/cvs-log $CVSROOT/CVSROOT/commitlog $USER ^CVSROOT /usr/local/bin/cvs-log /usr/adm/cvsroot-log ^prog1 Mail -s %s ceder
シェル・スクリプト /usr/local/bin/cvs-log の内容:
#!/bin/sh (echo "------------------------------------------------------"; echo -n $2" "; date; echo; cat) >> $1
あるディレクトリがリポジトリで管理されている場合、 そのディレクトリを常に最新にしておきたい事があるでしょう。 例えば、他の開発者が最新ソースを改めて取得せずに参照したい場合や、 CVS で保守されたウェブ・サイトのファイルを 格納毎に更新したい場合などです。
これを実現するため、
cvs update を実行するように loginfo を設定します。
しかし単純に設定するとロックの問題が発生するので、
cvs update をバックグラウンドで実行する必要があります。
Unix での例を以下に示します (実際は一行です):
^cyclic-pages (date; cat; (sleep 2; cd /u/www/local-docs; cvs -q update -d) &) >> $CVSROOT/CVSROOT/updatelog 2>&1
リポジトリ中の cyclic-pages で始まるディレクトリに
ファイルが格納された時、
取得済みのディレクトリ /u/www/local-docs を更新します。
rcsinfo には、格納時にログ・メッセージを
書き込むための書式を指定します。rcsinfo の
構文は verifymsg, commitinfo, loginfo
とほぼ同じです。See syntax.
しかし他のファイルと異なり、
第二項はコマンド行形式ではありません。
正規表現の次の部分は、ログ・メッセージの雛型を記した
ファイルへのフルパス名でなくてはいけません。
第一項が DEFAULT である行の記述は、リポジトリ名が
ファイル中のどの正規表現にも合致しない場合に適用されます。
第一項が ALL である行全てが、
最初に合致した正規表現または DEFAULT に加えて適用されます。
ログ・メッセージの雛型は、ログ・メッセージの既定値として用いられます。
しかし、cvs commit -m message や cvs commit -f
file によってログ・メッセージを指定した場合、
こちらが優先されます。
rcsinfo ファイルの記述例は See verifymsg.
CVS が別のマシンのリポジトリを利用している場合、
最初に作業ディレクトリを取り出した時に rcsinfo に
記述されていた雛型が使用され、以後変更されません。
rcsinfo や雛型を変更した場合には、
新たに作業ディレクトリを取り出す必要があります。
作業コピーの中に、いつも決まった名前のファイルがあるけれど、
CVS の管理下には置きたくないという場合がよくあります。
例えば、ソースのコンパイル時に生成される
オブジェクト・ファイルなどです。
cvs update を実行した場合には通常、
これらのファイル各々に対して、
知らないファイルがあったと出力されます
(see update output)。
CVS は、update, import, release
の実行時に無視すべきファイルのリストを
(sh(1) のファイル名形式で) 保持します
このリストは、以下の方法で構築されます。
RCS SCCS CVS CVS.adm
RCSLOG cvslog.*
tags TAGS
.make.state .nse_depinfo
*~ #* .#* ,* _$* *$
*.old *.bak *.BAK *.orig *.rej .del-*
*.a *.olb *.o *.obj *.so *.exe
*.Z *.elc *.ln
core
$CVSROOT/CVSROOT/cvsignore が存在すれば、
その内容がリストに付加されます。
.cvsignore が
あなたのホーム・ディレクトリに存在すれば、
その内容がリストに付加されます。
$CVSIGNORE の内容全てがリストに付加されます。
-I オプションによって CVS に与えられた内容が、
リストに付加されます。
.cvsignore があれば、
その内容をリストに付加します。
.cvsignore 内の形式は、
それが含まれるディレクトリのみで有効であり、
サブディレクトリに対しては効果を持ちません。
上記五つのファイル内で単感嘆符 (!) を記述すると、
無視するファイルのリストが空になります。
これは、通常は CVS に無視されるファイルを、
リポジトリに格納したい場合に使用します。
cvs import に -I ! を指定すると、全てを持ち込み、それは
素朴な配布や他の余分なファイルがないこと知られているソースから持ち込ん
でいるときにして欲しいことです。しかし、上の規則を見ると、玉にきずがあ
るのがわかると思います。もし配布に .cvsignore ファイルがあると、
そのファイルの形式は -I ! が指定されたとしても実行されます。唯
一の対策は持ち込むために、.cvsigonre ファイルを消去することです。
これはやっかいなので、将来は -I ! はそれぞれのディレクトリの
.cvsignore ファイルを上書きするように修正されるかもしれません。
無視をするファイルの構文は、空白で分けられたファイル名の一覧からなるそ
れぞれの行が続いたものであることに注意してください。これは空白のある
ファイル名を指定する綺麗な方法を提供しませんが、foo bar という
名前のファイルに合致させるために foo?bar のような対策を使うこと
ができます (fooxbar などにも合致します)。また、現在は註釈を指定
する方法が無いことにも注意してください。
CVS を使って自分自身のファイルを CVSROOT ディレクトリに維
持することは役に立つかもしれません。例えば、logcommit.pl という
スクリプトがあり、それは以下の行を commitinfo 管理ファイルに含
めることにより実行するとしましょう:
ALL $CVSROOT/CVSROOT/logcommit.pl
CVS で logcommit.pl を維持するためには、以下の行を
checkoutlist 管理ファイルに追加します:
logcommit.pl
checkoutlist の形式は、一行につき CVS を使って維持したいそ
れぞれのファイルのファイル名を書いたものです。
このように checkoutlist を設定した後で、そこに一覧として挙げら
れているファイルは CVS の元からの管理ファイルと同じように機能しま
す。例えば、そのファイルの一つを格納するときは、次のようなメッセージを
得るでしょう:
cvs commit: Rebuilding administrative file database
そして、CVSROOT ディレクトリに取り出されているコピーも更新され
ます。
passed (see Password authentication server) を
checkoutlist に載せるうことはセキュリティに関する理由により
推奨されないことに注意してください。
checkoutlist で提供されるよりも一般的な文脈で取り出したコピーを
維持するための情報は、Keeping a checked out copy を参照してくだ
さい。
ファイル $CVSROOT/CVSROOT/history は、
history コマンドのためにログ情報を記録します
(see history)。
ログを記録したい場合には、このファイルを作成する必要があります。
cvs init でリポジトリを準備すると、
自動的に作成されます (see Creating a repository)。
history ファイルの書式を説明したものは、
CVS ソース・コード内の註釈しかありません。
CVS の将来のリリースで書式が変更されるかも知れないので、
このファイルは必ず cvs history を通して利用して下さい。
管理用ファイルを記述するときに、CVS の動作環境についての 色々な情報を利用したい場合があると思います。 ここでは、その実現方法を幾つか紹介します。
CVS を実行した人物のホーム・ディレクトリを
(環境変数 HOME から) 参照するには、
/ または行端の直前に ~ を記述します。
同様に user のホーム・ディレクトリは、
~user と記述します。
これらの変数はサーバ側で展開されるため、pserver
(see Password authenticated) を用いる場合には正しく展開されません。
この場合、CVS を実行する人物が動作を変更できるように、
ユーザ変数 (下記参照) を用いると良いでしょう。
CVS 内部の情報を参照したい場合もあると思います。
CVS の内部変数は ${variable} という書式で参照できます。
この variable は文字で始まり、
アルファベットと _ から構成されます。
variable に続く文字がアルファベットや _ でない場合は、
{ と } とを省略しても構いません。
参照可能な CVS の内部変数には次のようなものがあります:
CVSROOT
RCSBIN
CVSEDITOR
VISUAL
EDITOR
USER
ユーザ変数を用いれば、CVS を実行する人物が、
管理用ファイルで用いる値を自由に設定できます。
ユーザ変数は、管理用ファイルに ${=variable} と記述します。
ユーザ変数の設定は、CVS の広域オプション -s に、
引数 variable=value を続けます。
このオプションは .cvsrc に記述しておくと良いでしょう
(see ~/.cvsrc)。
例として、実験用ディレクトリを管理用ファイルから参照するため、
ユーザ変数 TESTDIR を用います。それから、以下のように CVS
を起動し、
cvs -s TESTDIR=/work/local/tests
管理ファイルに sh ${=TESTDIR}/runtests と書いてあれば、文字列
は sh /work/local/tests/runtests に展開されます。
$ が上記以外の解釈を受けることはありません。
また $ 自身を表現する別の方法も用意されてないため、
$ という文字を引用することはできません。
管理ファイル config は CVS の振舞いに影響するいろいろな雑
多な設定を書きます。構文は他の管理ファイルと少し違います。変数は展開さ
れません。# で始まる行は註釈と解釈されます。
他の行はキーワード、=、値からなります。この構文は厳密であること
に注意してください。余分な空白やタブは使えません。
現在定義されているキーワードは:
RCSBIN=bindir
SystemAuth=value
yes であれば、pserver は使用者を調べるときに、
CVSROOT/passwd に見つからなければ、システムのデータベースを調べ
にいきます。no であれば、全ての使用者は CVSROOT/passwd
に存在している必要があります。既定値は yes です。pserver につい
ては、Password authenticated を参照してください。
PreservePermissions=value
no です。
このキーワード使用の完全な意味は See Special Files.
TopLevelAdmin=value
checkout コマンドが取り出されたディレクトリ中に作成される
CVS に加えて、新しい作業ディレクトリの最上位にも CVS ディ
レクトリを作成するように修正します。既定値は no です。
このオプションは、取り出されたサブディレクトリではなく、最上位のディレ
クトリで多くのコマンドを実行するときに便利です。そこに作成される
CVS ディレクトリにより、それぞれのコマンドに CVSROOT を
指定する必要がなくなります。CVS/Template ファイルの場所も提供し
ます (see Working directory storage)。
LockDir=directory
LockDir オプションを使用可にする前に、CVS 1.9 やそれ以前のもののコピー を追跡して消去したことを確認してください。そのようなバージョンは LockDir をサポートしていませんし、それをサポートしていないというエラー を出すこともありません。結果として、もしこのようなことが起こってしまえ ば、CVS の何人かの使用者はある場所にロックを置き、他は別の場所に置くと いうことになり、リポジトリが壊れてしまう可能性があります。CVS 1.10 は LockDir をサポートしていませんが、LockDir が使用されているリポジトリで 実行されると警告を印字します。
これは、CVS に影響する全ての環境変数の 完全なリストです。
$CVSIGNORE
$CVSWRAPPERS
$CVSREAD
checkout と update により作成される作業コピーが、
強制的に読み込み専用となります。
設定しなければ、作業ファイルの修正許可が与えられます。
$CVSUMASK
$CVSROOT
$CVSROOT が設定されていない場合や、
他のものを優先させたい場合には、
コマンド行で cvs -d cvsroot cvs_command...
としてリポジトリを指定することができます。
一旦作業ディレクトリを取り出した後は、
CVS が適切なリポジトリを (CVS/Root に) 記録します。
従って、最初に作業ディレクトリを取り出す時を除いて、
通常はこの値に注意する必要はありません。
$EDITOR
$CVSEDITOR
$VISUAL
$CVSEDITOR は $EDITOR よりも優先されます。
Committing your changes を参照してください。
$PATH
$RCSBIN が設定されておらず、
CVS にパス名が埋め込まれていない場合、
使用する全てのプログラムを捜す時に $PATH が使用されます。
$HOME
$HOMEPATH
$HOMEDRIVE
.cvsrc やそのような他のファイルが置かれたディレ
クトリを捜します。Unix では、CVS は HOME だけを調べます。Windows NT で
は、システムは HOMEDRIVE を例えば d: に、HOMEPATH を例えば
\joe に設定します。Windows 95 ではおそらく自分自身で HOMEDRIVE
と HOMEPATH を設定する必要があるでしょう。
$CVS_RSH
:ext: が指定された時、
CVS が接続に使用する外部プログラムを
指定します。see Connecting via rsh。
$CVS_SERVER
cvs です。see Connecting via rsh。
$CVS_PASSFILE
cvs login server が実行された時に使用されます。
既定値は $HOME/.cvspass です。
see Password authentication client。
$CVS_CLIENT_PORT
$CVS_RCMD_PORT
$CVS_CLIENT_LOG
$CVS_CLIENT_LOG.in$CVS_CLIENT_LOG.out$CVS_SERVER_SLEEP
$CVS_IGNORE_REMOTE_ROOT
-d 広域オプション
が指定されているときに CVS/Root を上書きするのを抑制することが
できました。後のバージョンの CVS は CVS/Root を再書き込み
しませんので、CVS_IGNORE_REMOTE_ROOT は効果はありません。
$COMSPEC
$TMPDIR
$TMP
$TEMP
TMPDIR を使用します。
この指定方法は、Global options 参照。
CVS には、(システムが提供する _tmpnam 関数経由で)
常に /tmp を使用する部分があります。
Windows NT では (システムが提供する _tempnam 関数経由で)、
TMP が使用されます。
CVS のクライアントが用いる patch プログラムは、
TMPDIR を使用します。
設定されていない場合、(少なくとも GNU patch 2.1 は)
/tmp を使用します。
サーバとクライアントの両方共が CVS 1.9.10 以降を実行しているなら、
CVS は外部の patch プログラムを呼び出しません。
リポジトリの形式は CVS 1.3 から互換です。CVS 1.6 以前を使っ ていて、オプションの開発者間通信機能を使いたいときは、Watches Compatibility を参照してください。
作業ディレクトリ形式は CVS 1.5 から互換です。CVS 1.3 と CVS 1.5 の間で変更されました。CVS 1.3 で取り出されたディレク トリで CVS 1.5 か、それより新しいものを実行すると、CVS はそ れを変換しますが、CVS 1.3 に戻るためには、新しい作業ディレクトリ を CVS 1.3 で取り出す必要があります。
遠隔プロトコルは CVS 1.5 から相互作用可能ですが、それ以前では無理 です (1.5 が遠隔プロトコルのある最初の公的リリースですが、古いバージョ ンがまだあたりをうろついているかもしれません)。しかし、多くの場合、新 しい機能とバグ修正の利点を得るためにクライアントとサーバの両方を更新す る必要があります。
CVS の使用に問題があれば、この付録が役立つかもしれません。特定の エラーメッセージが出ているなら、そのメッセージをアルファベット順に探す ことができます。そうでない場合は、他の問題の章を眺めて説明されているか どうかを知ることができます。
これは CVS で起こるかもしれないエラー・メッセージの部分的な一覧で す。完全な一覧ではありません--CVS はたくさん、たくさんのエラー・ メッセージを印字する能力があり、しばしば一部分はオペレーティング・シス テムにより提供されます。しかし、ここでの意図はよくあるもの、混乱する可 能性のあるエラー・メッセージの、両方もしくはどちらかにあてはまるものの 一覧を挙げることです。
メッセージはアルファベット順ですが、cvs update: のような前置き
の文章は順番にするときには省かれています。
この一覧は古いバージョンの CVS で印字されるメッセージがある場合も あります (使用者は特定の時にどのバージョンの CVS を使用しているか を必ずしも知らないというのが理由の一つです)。
cvs command: authorization failed: server host rejected access
file:line: Assertion 'text' failed
cvs command: conflict: removed file was modified by second party
cvs add
file を実行します。それが望まれていれば、他の人々の修正を見てま
だそれを消したいかどうかを決定します。消したくなければ、ここで止めます。
消去したければ、 cvs remove file を実行して、削除を格納し
ます。
cannot change permissions on temporary directory
Operation not permittedこのメッセージは、Red Hat Linux 3.0.3 と 4.1 でクライアント/サーバのテ スト一式を実行しているときいに、再現不可能な方法でときどき発生しました。 我々は何がそれを起こしたのか、また linux (もしくは、このマシンそのもの!) に特有かどうかも分かりません。他の unix でも問題が発生した場合は、おそ らく
Operation not permitted は Not owner や当のシステム
が unix の EPERM エラーで使用している他のものになっているでしょ
う。追加の情報があれば、BUGS で説明されているように我々に知らせ
てください。もし CVS を使用していてこのエラーを経験したときは、そ
れを発生させた操作をもう一度繰り返すとちゃんと動作するでしょう。
cvs [server aborted]: Cannot check out files into the repository itself
/usr/local/cvsroot で、
/usr/local/cvsroot/test のようなサブディレクトリにファイルを取
り出そうとしたことです。しかしながら、サーバの一時ディレクトリがルート
のサブディレクトリに設定されている (これも許可されていません) というよ
り微妙な場合もあります。これが問題の原因であるなら、一時ディレクトリを
別のところに設定してください。例えば、/var/tmp に。一時ディレク
トリの設定のしかたは、Environment variables の TMPDIR を
参照してください。
cannot open CVS/Entries for reading: No such file or directory
cvs [init aborted]: cannot open CVS/Root: No such file or directory
cvs [checkout aborted]: cannot rename file file to CVS/,,file: Invalid argument
cvs [command aborted]: cannot start server via rcmd
:local: を指定することを忘れたのでしょう。
ci: file,v: bad diff output line: Binary files - and /tmp/T2a22651 differ
cvs checkout: could not check out file
co プログラム (RCS プログラムの一部で
す) が失敗の値を返したということです。他のエラーメッセージがその前にあ
るはずですが、別のエラーメッセージなしに発生することも確認されており、
原因はよくわかっていません。現在のバージョンの CVS は co を実行
しないので、このメッセージが別のエラーメッセージとともに現れなければ、
それは間違いなく CVS のバグです (see BUGS)。
cvs [update aborted]: unexpected EOF reading file,v
EOF in key in RCS file を参照。
cvs [login aborted]: could not find out home directory
cvs update: could not merge revision rev of file: No such file or directory
rcsmerge プログラムを見つけるときに問題が発生し
たときにこのメッセージを印字します。それが PATH にあることを確
認するか、外部 rcsmerge プログラムを必要としない現在のバージョ
ンの CVS に更新してください。
cvs [update aborted]: could not patch file: No such file or directory
patch プログラムの探索に問題があったということです。それ
が PATH 上にあるとを確認してください。メッセージの外観とは違っ
て、file を見つけるかどうかについて言っているのではないこ
とに注意してください。クライアントとサーバが現在のバージョンの
CVS を実行しているなら、外部 patch プログラムは必要ではなく、この
メッセージを見ることはないでしょう。しかし、クライアントかサーバが
CVS 1.9 を実行していれば、patch が必要です。
cvs update: could not patch file; will refetch
dying gasps from server unexpected
-t 広域オプションを使用しているときに再現可能です。もし興味
があれば、それは Andy Piper の1997年11月4日の src/filesubr.c への変更
で修正されました。このメッセージが出たときは、おそらく失敗した操作をた
だもう一度試すことができます。また、この原因に関して情報を発見したなら、
BUGS に書かれているように我々に知らせてください。
end of file from server (consult above messages if any)
rsh プログラムを使用してい
て、それがエラーを出して終了するというものです。この場合 rsh
プログラムは、上のメッセージの前にメッセージを印字しているはずです。
CVS のクライアントとサーバの設定の情報は Remote repositories を参照してください。
cvs commit: Executing 'mkmodules'
cvs commit: Rebuilding administrative file database
両方のメッセージが表示されれば、データベースは2回再構築されていて、こ
れは不必要ですが、無害です。重複を避けたくて、CVS 1.7 以前を使っ
ていないなら、modules ファイルにある全ての -i mkmodules
を消してください。modules ファイルの情報は modules を参照
してください。
missing author
*PANIC* administration files missing
rcs error: Unknown option: -x,v/
cvs [server aborted]: received broken pipe signal
Too many arguments!
contrib ディレク
トリにある log.pl スクリプトにより印字されます。CVS のバー
ジョンには、log.pl が既定の CVS インストールに含まれている
ものもあります。log.pl スクリプトは loginfo 管理ファイル
から呼ばれます。loginfo で渡されている引数があなたのバージョン
の log.pl が期待するものとあっているか調べてください。特に、
CVS 1.3 以前の log.pl はログファイルを引数として期待します
が、CVS 1.5 以降の log.pl はログファイルは -f オプ
ションで指定されることを期待します。もちろん、log.pl が必要でな
ければ、loginfo 中で註釈にして、使用しないようにすることができ
ます。
cvs [login aborted]: unrecognized auth response from server
inetd.conf が存在しない cvs 実行ファイルを指していると
きです。これをデバッグするためには、inetd が書くログファイル
(/var/log/messages やあなたのシステムの inetd が使うその他のも
の) を見つけてください。詳細は Connection と Password authentication server 参照。
cvs commit: Up-to-date check failed for `file'
cvs update を実行した後に誰かが変更を格納
したということです。ですから、cvs commit を継続する前に
cvs update をする必要があります。CVS はあなたのした変更と他の人
がした変更をマージします。衝突が発見されなれば、M cacErrCodes.h
のように報告され、cvs commit を実行する準備が整っています。もし
衝突が発見されれば、その由を印字し、C cacErrCodes.h と報告され、
手で衝突を解消する必要があります。この過程の詳細は Conflicts example を参照してください。
Usage: diff3 [-exEX3 [-i | -m] [-L label1 -L label3]] file1 file2 file3
Only one of [exEX3] allowedこれは
diff3 と rcsmerge のインストールに問題があること
を示しています。特に rcsmerge は GNU diff3 を探すようにコンパイ
ルされているけれど、代わりに unix の diff3 が使われています。一番簡単
な解決法は外部の rcsmerge や diff3 プログラムに頼らない
現在のバージョンの CVS に更新することです。
warning: unrecognized response `text' from cvs server
ok のようなもの) で、続きに余分な
キャリッジリターンがあると (多くのシステムではこれはメッセージの2番目
の部分が1番目の部分を上書きします)、おそらく、既定では透過的なデータス
トリームを提供しない、多くの unix でない rsh のバージョンで
:ext: 接続方法を使用としているのでしょう。その様な場合はたぶん
:ext: の代わりに :server: を試みるのが良いでしょう。
text が何か他のものなら、CVS サーバに問題があることを表します。
CVS サーバを設定するための指示を見てインストールを再度確認してください。
cvs commit: [time] waiting for user's lock in directory
cvs commit: warning: editor session failed
#!/bin/sh vi $* exit 0
この章は CVS サーバに接続しようとしたときに問題が起こったときに何 をすれば良いかということを書いています。 Windows で CVS コマンド ライン・クライアントを実行しているなら、まず CVS 1.9.12 以降に更 新してください。以前のバージョンのエラー報告は、問題がどうであったかに ついて、ほとんど情報を提供しません。クライアントが Windows でなければ、 CVS 1.9 は問題ありません。
問題を追いかけるためにエラー・メッセージが十分でなければ、次の手段は使 用している接続方法によってかなり異なります。
:ext:
:server:
:pserver:
cvs [pserver aborted]: bad auth protocol start: foo
これの動作に失敗すれば、inetd が正しく動作しているか確認してください。 inetd.conf での起動を cvs の代わりに echo プログラムに変更してください。 例えば:
2401 stream tcp nowait root /bin/echo echo hello
その変更をして、inetd に設定ファイルを再読み込みするように指示した後で は、"telnet servername 2401" はテキスト hello を表示して、サーバが接続 を切るはずです。これが動作しなければ、CVS の問題を気にする前にそ れを修正してください。
AIX システムでは、システムにポート 2401 を使おうとするプログラムがあり ます。これは、ポート 2401 は CVS での使用に登録されているという点 で AIX の問題です。この問題を解決するために AIX のパッチがあるというこ とを聞いたことがあります。
他の良いデバッグツールは inetd に -d (debugging) オプションを付
けることです。詳しい情報はシステムの説明文書を調べてください。
これは上の分類には合わない問題の一覧です。順番には特に意味はありません。
C:/ に設定されているということ
かもしれません (Environment variablesの HOMEDRIVE と
HOMEPATH 参照)。 CVS はホームディレクトリがスラッシュで終わらな
いことを期待しています。例えば、C: や C:\cvcs です。
cvs update が衝突を発見し、マージを試みたけれど、
衝突があることを報告しなかったら、RCS の古いバージョンが存在しま
す。一番簡単な解決は、おそらく外部 RCS プログラムを使用しない現在
のバージョンの CVS に変更することです。
当時 Cygnus Support にいた Roland Pesch <roland@wrs.com> は CVS 1.3 とともに頒布されたマニュアルを書きました。 記述の多くは、彼の文章から受け継いでいます。 また彼にこのマニュアルの初期の草稿を読んでもらい、 多くのアイディアと訂正を頂きました。
メーリング・リスト info-cvs も時には有益でした。
私は以下の人物が行なった投稿による情報を含めました:
David G. Grubbs <dgg@think.com>.
RCS の man からいくつか文章を引用しています。
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>, Michael Brown <brown@wi.extrel.com>.
ここの貢献者の一覧は包括的なものであはありません。このマニュアルへの貢
献者のより完全な一覧は CVS のソース配布のファイル
doc/ChangeLog を見てください。
CVS もこのマニュアルも完璧ではなく、また永遠にそうならないでしょ う。CVS を使用していて問題にぶつかったり、バグを見つけたと思った りしたときは、いろいろな方法があります。また、マニュアルにはっきりしな いところがあれば、マニュアルのバグと考えられますので、これらの問題も CVS 自身の問題と同様に行動をするに値します。
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 http://www.signum.se/ Cyclic Software United States of America http://www.cyclic.com/ info@cyclic.com
http://www.cyclic.com http://www.loria.fr/~molli/cvs-index.html
もし非常にやる気になれば、ネット上での情報を増やすと感謝される可能性が 高いでしょう。例えば、標準の CVS 配布が Windows 95 について作業を する前に、CVS を Windows 95 で実行するための説明とパッチのあるウェ ブページがあり、色々な人がその題がメーリングリストやニュースグループで 出る度にそのページを知らせることで手助けをしていました。
訳註: 日本語のウェブページは以下のものが良いでしょう。
http://www.cyclic.com/cvs/lang-jp.html http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
bug-cvs に報告することもできます。誰かがあなたのバグ報告
に対して何かをしようと思うかもしれないし、思わないかもしれない、という
ことに注意してください--もし解決策が必要なら、上の方法のどれかを考慮
してください。ですが、おそらく人々は特に大変な結果になるバグと、簡単に
修正できるバグの両方、もしくはどちらかに該当するもに関心があるでしょう。
また、バグの本質と他の関係する情報を明確にすることで可能性を高めるこが
できます。バグを報告するためには bug-cvs@gnu.org に email を送
ります。bug-cvs へ送ったものは GNU Public License の条件の
下で配布されるかもしれないことに注意してください。もしこれを好まなけれ
ば、送らないでください。普通は、メールを bug-cvs ではなく、
CVS の管理者に直接送ることの正当性はありません。そのようなバグ報
告に関心のある管理者は bug-cvs を読んできます。また、バグ報告を
他のメーリングリストやニュースグループに送ることは bug-cvs へ送
る代わりにはならないということにも注意してださい。CVS のバ
グをどの場所でも好きなところで議論するのは良いことですが、
bug-cvs 以外に送られたバグ報告を管理者の誰かが読んでいるとは限
りません。
結構頻繁に、既知のバグの一覧や特定のバグが知られたものかどうかの一覧が あるかどうかを尋ねられます。CVS のソース配布の BUGS ファイル は既知のバグのリストの一つですが、必ずしも包括的なものであろうとはして いません。おそらく、既知のバグの包括的な、詳細な一覧は存在することはな いでしょう。
この CVS のマニュアルは、
CVS 1.10.7 に付属していた、
cvs.texinfo を日本語訳したものです。
文書の構造やノード名等は(この節を除いて)そのまま使用しており、
文章は自分に可能な限り忠実に訳しています。
修正案、訂正等がありましたら、なるべく廣保まで御連絡下さい。
廣保 誠 <hiroyasu@iedc.mke.mei.co.jp>
大阪大学の西田圭介さんが、引地夫妻に問い合わせてこの文書の
配布条件の推奨訳を入手したり、一部の下訳を送ってくれたりしました。
また CVS について日本語で情報交換するためのメーリング・
リストを立ち上げました。現在このメーリング・リストは
京都工芸繊維大学の西本卓也さんが引き継いでいます。
詳細は http://www-vox.dj.kit.ac.jp/nishi/cvs/cvs.html
を参照して下さい。CVS 1.9 から CVS 1.10.7 への更新は
林芳樹 <g740685@komaba.ecc.u-tokyo.ac.jp> が行いました。
この文書を修正・再配布する場合には、 原英文の配布条件に従って下さい。 以下に許諾文の参考訳を付けます。
Copyright © 1992, 1993 Signum Support AB Copyright © 1993, 1994 Free Software Foundation, Inc.
上記の著作権表示と本許可告知が すべての写しに前もって載せられている場合にのみ、 本マニュアルをそのまま複写し配布することを許可します。
本マニュアルの修正版の複写と配布は、修正版全体が本許可告知と同一の条件の もとに配布される場合にのみ許可します。
本マニュアルの外国語 (英語以外の言語) への翻訳版の複写と配布は、 上記の修正版の場合に準じますが、 本許可告知は Free Software Foundation の許可を得た 翻訳でなければなりません。