manページ  — CVS

• 書式
• 注
• 解説
• 不可欠なコマンド
• オプション
• CVS OPTIONS
• 使用法
• CVS のスタートアップファイル
• CVS COMMAND のまとめ
• 共通の COMMAND OPTIONS
• CVS COMMANDS
• 関連ファイル
• 環境変数
• 作者
• 関連項目
• 日本語訳

より有用な kflag としては -ko と -kb (バイナリファイル用) と -kv があります。-kv は export の際、どこか別のサイトで後に import されてもキーワード情報が残るようにしたい場合に有用です。

このオプションを `cvs checkout' か `cvs update' でファイルのコピーを作成するときに使うと、 tag の指定は ``sticky'' です: cvs は tag を記憶して以降の update コマンドでも、他のものを 指定するまで、それを使い続けます。 tag としては シンボリックまたは番号によるものが使用できます。 RCS ファイルが指定されたタグを含んでいないときに警告メッセージを抑止するため 全体に作用する -q オプションをコマンドオプション -r と一緒に指定すると便利な場合が多くあります。 -r は checkout, commit, diff, history, export, rdiff, rtag, update コマンドで使用できます。 警告: これは cvs コマンドの 左側 に指定し、全体に作用する `cvs -r' オプションと同じではありません。

`cvs add' の引数が直下のサブディレクトリを指しているなら、そのディレクトリが ソースリポジトリの現位置に作成され、必要な cvs 管理ファイルが作業ディレクトリに作成されます。 ディレクトリがすでにソースリポジトリに存在した場合でも、 `cvs add' はあなたのバージョンのディレクトリに管理ファイルを作成します。 これによって、あなたがソースを checkout した後に誰か他の人がディレクトリを作っていても `cvs add' でそのディレクトリをあなたの私的なソースに作成することが 可能になります。以下のようにすることができます:

example% mkdir new_directory
example% cvs add new_directory
example% cvs update new_directory

`cvs update' を使った別のアプローチもあります:

example% cvs update -d new_directory

(新しく できた ディレクトリをあなたの作業ディレクトリに 追加するには、おそらく `cvs checkout' か `cvs update -d'を使用する方が簡単でしょう。)

`cvs commit' で変更が恒久的なものとされるまで、追加されたファイルは ソースリポジトリには置かれません。 `cvs remove' コマンドで削除されたファイルに対して `cvs add' を行うと、間で `cvs commit' コマンドが実行されていなければファイルが復活します。

新しいファイルを `cvs commit' で恒久的なものにするときに、いつものように、ログメッセージを指定する 機会があります。もしファイルの 作成 と対応するもう一つのログメッセージを指定したいならば (例えば、ファイルの目的を説明するなど)、 add コマンドの `-m message' オプションで指定することができます。

`-k kflag' オプションで このファイルがチェックアウトされるときの デフォルトを指定できます。 引数 `kflag' は RCS ファイルに記録されて `cvs admin' で変更することができます。 展開された キーワードを持たないであろうバイナリをチェックインする場合には `-ko' を指定すると便利です。

modules はいくつかのソースディレクトリとファイルを 集めたものに対するシンボル名 (それ自体は `modules' というモジュールとしてソースリポジトリに定義されています。 cvs(5) 参照) か、あるいはリポジトリ中でのディレクトリまたはファイルへのパス名です。

指定した modules に応じて、 checkout は再帰的にディレクトリを作成して適切なソースファイルで満たします。 その後はいつでも、(他のソフトウェア開発者達がソースの彼らの分のコピーを 編集しているかどうかを気にすることなく) これらのソースファイルを編集したり、 他の人によってソースリポジトリに行われた新しい変更を取り込むために これらを更新 (update) したり、 あなたの作業を恒久的な変更としてリポジトリに 登録 (commit) することができます。

checkout はディレクトリの作成に使われることに注意して下さい。 作成されるディレクトリのトップレベルは常に checkout が起動されたディレクトリに追加され、そして通常、指定された moduleと同じ名前を持ちます。 module がエイリアスの場合は、作成されたサブディレクトリは違う名前を持つかも しれませんが、それがサブディレクトリであること、そして checkout はファイルが私的な作業領域に取り出される際に各ファイルへの 相対パスを表示すること (全体に作用する -Q オプションを指定していなければ) は当てにできます。

すでに以前の checkout で作成されているディレクトリで `cvs checkout' を実行することも許されています。これは 以下で説明する update コマンドに -d オプションを指定するのと同じ効果を持ちます。

`cvs checkout' で使える options は以下の標準のコマンドオプションです。 -P, -f, -k kflag amp;, -l, -n, -p, -r tag, -D date

これらに加えて、以下の特別のコマンドオプションを checkout で使うことができます:

-A オプションで sticky なタグ、日付または -k オプションをリセットできます。(作業ファイルを -r, -D, -k オプションのいずれかを使って取り出すと、 cvs は対応するタグ、日付、kflag を記録して以降の 更新 (update) でそれを使い続けます。 -A オプションを使って cvs に それらの指定を忘れさせ、ファイルの ``head'' バージョンを取り出します)。

-j branch オプションはベースとなったリビジョンと、そこから変更された結果の リビジョンとの差分をマージします (例えば、もしタグがブランチを 指しているときは、 cvs は、そのブランチで行われた全ての変更を作業ファイルにマージします)。

2 つの -j オプションを指定すると、 cvs は 2 つの各々のリビジョン間での変更をマージします。 これは特定の差分を作業ファイルから ``削除'' するために使うことが できます。

加えて、各 -j オプションをブランチで使う場合に必要であれば 日時指定を加えることができ、選択するリビジョンを指定した日時以内に 制限できます。 日時を加える場合はタグにコロン (:) を付けて指定します。 例としては `cvs import' でローカルな変更と衝突する部分のあるソースを import するときに 実行するように指示されるコマンドがあります:

example% cvs checkout -jTAG:yesterday -jTAG module

-N オプションと `-d dir' を指定することで作業ディレクトリでモジュールのパスが短縮されるのを 防げます。(通常、明示的に対象ディレクトリを指定すると cvs は なるべくパスが短くなるようにします。)

-c オプションで、作業ディレクトリのファイルやディレクトリに作成や変更を 行う代わりに、モジュールファイルをソートしたものを標準出力にコピー します。

-d dir オプションで、モジュール名ではなく、 dir で指定した名前のディレクトリを作業ファイルのために作成します。 -N を一緒に指定しない場合は、dir の下に作成されるパスは 可能な限り短くなります。

-s オプションを使って -s オプションでモジュールファイルに格納されたモジュール単位の ステータス情報を表示します。

コミットする対象となる files を指定しない場合、現在の 作業ディレクトリ中の全ファイルが調べられます。 commit はあなたが本当に変更したファイルだけを慎重にリポジトリで変更します。 デフォルトでは (または明示的に -R オプションを指定した場合)、サブディレクトリのファイルも 調べられ、もし変更されていればコミットされます。 -l オプションで現ディレクトリのみ コミット するように制限できます。 変更されていなくても強制的にファイルをコミットしたい場合があるかも しれません。 これは -f フラグで可能で、これは同時に再帰も抑止します (もちろん -R で再帰するようにできます)。

commit は選択されたファイルがソースリポジトリの現リビジョンに対して 最新であることを確認します。 もし選択されたファイルのいずれかが まず `cvs update' で最新にされなければならないなら、そこで通知してコミットせずに終ります。 commit は update コマンドを呼び出しません。update すべきときであるかどうかの判断は ユーザにゆだねられます。

全てがうまくいくと、ログメッセージを入力するためにエディタが 呼び出されます。ログメッセージは一つかそれ以上のログを取る プログラムに書き込まれて ソースリポジトリのファイルに置かれます。 代わりにコマンドラインで -m オプションと共にログメッセージを指定し、 エディタの呼び出しを抑制することができます。また -F オプションで引数の file にログメッセージが含まれていることを 指示することもできます。

-r オプションで特定のシンボリックまたは番号で指定される リビジョンとしてコミットできます。 例えば、全ファイルを リビジョン ``3.0'' に上げる (変更されていないものも含めて) には、以下のようにします:

example% cvs commit -r3.0

cvs はメインの幹上のリビジョン (ドットが 1 つのリビジョン) へのコミットのみ 許します。 しかしながら、 -r オプションでブランチ上のリビジョン (偶数個のドットをもつリビジョン) へ コミットすることもできます。 ブランチとなるリビジョンを作成するには、通常 rtag または tag コマンドの -b オプションを使います。 その後、 checkout または update のいずれかでソースのベースを新しく作成したブランチにすることができます。 それ以降、それらの作業ファイルで行われた全ての commit される変更点は自動的にブランチのリビジョンに追加され、 それによって主たる開発ラインが混乱させられることはありません。 例をあげると、製品のバージョン 1.2 へのパッチを作成しなければ ならなくなったとすると、バージョン 2.0 がすでに開発中だったとしても、 以下のようにできます:

example% cvs rtag -b -rFCS1_2 FCS1_2_Patch product_module
example% cvs checkout -rFCS1_2_Patch product_module
example% cd product_module
[[ hack away ]]
example% cvs commit

極めて実験的なソフトウェアを開発しているとして、 前の週にチェックアウトしたなんらかのリビジョンをベースにしていると します。 あなたのグループの別の人がこのソフトウェアであなたと一緒に作業したいが、 主たる開発ラインの邪魔はしたくないと考えたなら、あなたはあなたの 変更点を新しいブランチにコミットすると良いでしょう。 すると別の人はあなたの実験的な変更をチェックアウトして cvs の衝突解決機能を最大限に利用することができます。 シナリオは以下のようになります:

example% cvs tag -b EXPR1
example% cvs update -rEXPR1
[[ hack away ]]
example% cvs commit

別の人は単純に `cvs checkout -rEXPR1 whatever_module' とすれば実験的な変更を採り入れてあなたと作業できるようになります。

サポートされている format_options のリストは `cvs --help diff' を参照して下さい。

ファイルを何も指定しないと、 diff は現ディレクトリ (そして、標準オプション -lを指定していなければ そのサブディレクトリ) の全てのファイルについて、 ソースリポジトリの対応するリビジョンと異なっているもの (つまり あなたが 変更したファイル) または指定されたリビジョンと 異なっているものについて、その差分を表示します

標準でないオプションは `-d dir' (ソースをディレクトリ dir に書き込みます) と `-N' (モジュールパスを短縮しません) のみです。 これらは `cvs checkout'の同名のオプションと同じ意味を持ちます。

export が使われるときは -kv オプションが有用です。 これによって キーワードが、どこか別のサイトで import が行われたときにリビジョン情報が失われないような形に展開されるように なります。 他の kflag を `cvs export' で使用することもできます。その説明は co(1) にあります。

警告: `cvs history' は `-f', `-l', `-n', `-p' を 共通の COMMAND OPTIONS amp;での説明とは異なる意味に使用します。

いくつかのオプション (上で -report となっている部分) は どんな種類のレポートを生成するかを制御します:

引数 repository で CVS ルートディレクトリ下のリポジトリ用 ディレクトリ名 (またはディレクトリへのパス) を与えます。 もしディレクトリが存在しないなら、import が作成します。

あなたのソースリポジトリで (前回の import から) 変更された ソースへの更新に import を使った場合、開発の 2 本のブランチで 衝突しているファイルについて警告します。 import が指示するように、 `cvs checkout -j' を使って差分を調整できます。

デフォルトでは、ある種のファイル名が `cvs import'で無視されます: CVS 管理、または他の一般的なソース管理システムに関連する名前; パッチファイル、オブジェクトファイル、アーカイブファイル、 エディタのバックアップファイルのための一般的な名前; そして雑多なユーティリティの加工品であることを示すその他の名前。 無視されるファイルのリストの最新については、 (このマニュアルページの関連項目の節に記述してあるように) Cederqvist 著のマニュアルを参照して下さい。

外部からのソースは第一レベルの ブランチ、デフォルトでは `1.1.1'に保存されます。 以降の更新は このブランチのリーフになります。 例えば、最初に import したソース集合からのファイルはリビジョン `1.1.1.1'になり、 次の import による更新でファイルはリビジョン `1.1.1.2'になり、以下同様に続きます。

最低で 3 つの引数が必要です。ソースの集合を識別するために repository が必要です。vendortag はブランチ全体を示す タグになります (例えば `1.1.1'と対応します)。 `cvs import'を実行する度にリーフとしてできるファイルを 識別するために少なくとも一つの releasetag も指定しなければ なりません。

cvs の標準のコマンドオプションのうちの 1 つ -m が利用可能です: ログメッセージを -m で指定しないと、(commit でのように) メッセージを 入力できるようにエディタが起動されます。

さらに 3 つの特別なオプションがあります。

`-d' を使って、各ファイルの最終更新日時がチェックインの日付と時刻として 使われるよう指示できます。

`-b branch' を使って第一レベルのブランチを `1.1.1'以外に指定できます。

`-I name' を使って import 中に無視されるべきファイル名を指定できます。 このオプションは繰り返して指定できます。 いかなるファイルも無視されない (デフォルトで無視されるものでも) ようにするには、 `-I !'と指定します。

もしソフトウェアリリースへの影響が複数ディレクトリにわたるなら、 古いソースにパッチを当てる際、 patch が他のディレクトリに置かれたファイルを見つけられるように、 -p オプションを patch コマンドに指定する必要があるかもしれません。

標準オプションの flags -f、-l が このコマンドで利用可能です。他にもいくつかの 特別なオプションフラグがあります:

-s オプションを指定すると、パッチ出力が作られません。 代わりに、2 つのリリース間で変更または追加されたファイルの要約が 標準出力デバイスに送られます。 これは、例えば、2 つの日付またはリビジョンの間で、どのファイルが 変更されたかを調べるのに便利です。

-t オプションを指定すると、新しい方から 2 つのリビジョンの差分が 標準出力デバイスに送られます。これはファイルへの最後の変更が 何であったかを知るのに最適です。

-u オプションを指定すると、パッチ出力として新しい ``unidiff'' フォーマットを使って文脈差分とします。

希望するなら、 -c を使って明示的に `diff -c' 形式の文脈差分を指定できます (こちらがデフォルトです)。

`cvs release' を使うとこれらの問題を回避できます。 このコマンドは以下の点をチェックします: コミットされていない変更が存在しないこと、 cvs の作業ディレクトリの直上または内部から実行していること、 ファイルが記録されたリポジトリがモジュールデータベースに 定義されたリポジトリと同じであること、です。

これらの条件が全て真なら `cvs release' は その実行記録 (意図的にチェックアウトを削除した証拠) を cvs のヒストリログに残します。

-d フラグを使ってソースの作業用コピーを release が 成功したら削除するように指示できます。

リポジトリに commit で変更を反映するまで、ファイルは実際には削除されません。 commit した時点で、ソースリポジトリの対応する RCS ファイルが `Attic' ディレクトリ (これもソースリポジトリの中です) に 移動 されます。

このコマンドはデフォルトで再帰的になっており、 物理的に削除された全てのファイルが次の commit での削除されるようにスケジュールします。 -l オプションを使うか、または実際に削除したいファイルのみを 指定することで、この再帰を抑制できます。

一般に、タグ (しばしばソフトウェア配布物のシンボリックな 名前でもある) は削除されるべきではありません。 しかし完全に廃れてしまったシンボリックな名前を削除する場合 (例えば、 アルファリリースの場合など) の手段として、 -d オプションが用意されています。

`cvs rtag' はすでに存在するタグを移動しません。 しかしながら、-F オプションが指定されると `cvs rtag' はそのファイルに既に存在する symbolic_tag のインスタンスを 新しいリポジトリのバージョンへ移動します。 -F オプションが無い場合、 `cvs rtag' を使ってすでにそのファイルに存在するタグを付けようとすると、 エラーメッセージが出力されます。

-b オプションはタグを ``ブランチ'' タグにし、並行の、 独立した開発を可能にします。 これは以前にリリースしたソフトウェア配布物へのパッチを作成するのに 最も有用です。

標準の -r と -D オプションを使って、すでに特定の タグを含んでいるファイルのみにタグを付けることができます。 この方法はタグの名前を変えるのに使えるでしょう: 古いタグで指定されるファイルにのみタグを付け、 それから古いタグを削除すれば、確実に同じファイルで古いタグを 新しいタグで置き換えることができます。

rtag はデフォルトで再帰的に実行し、引数で指定した modules の全てのサブディレクトリにタグをつけます。 この動作を トップレベルのディレクトリに制限するには標準の -l オプションを 指定します。 また明示的に再帰を指定するには -R を指定します。

モジュールデータベースではタグが指定されたときに必ず実行される プログラムを指定できます。よくある使い方は、興味を持っている グループに電子メールを送るというものです。もしそのプログラムを バイパスしたい場合は、標準の -n オプションを使います。

-a オプションを使うと `Attic' の中の指定されたタグを含む削除されたファイルを rtag の対象にできます。 タグはそれらのファイルから削除され、開発の進展につれての シンボリックタグの再利用に便利になります (そしてファイルは以降の 配布物から削除されます)。

このコマンドを用いて、作業用ソースディレクトリでの `cvs update' による潜在的な影響を予測することもできます。 もし files を明示的に指定しないと、cvs が 作業ディレクトリに置いた全てのファイルについてレポートが 表示されます。 この検索の範囲を (そのサブディレクトリではなく) カレントディレクトリ だけに制限するには、標準の -l オプションフラグを使います。 -R オプションによって、明示的に再帰的なステータスレポートを 指定することもできます。

-v オプションを指定すると RCS ファイルのシンボリックタグも表示されるようになります。

cvs tag がリポジトリを直接操作するという事実に関し、 潜在的に驚いてしまうことがあります。 それは、チェックインバージョンに対してタグ付けするということであり、 これは作業ディレクトリにおいてローカルに修正したファイルとは 違ってもかまわないということです。 誤ってこのようなことをしたくない場合、 -c オプションを cvs tag へ指定してください。 ローカルに修正されたファイルがある場合、ファイルにタグ付けする前に、 CVS はエラーで中断します。

タグの使い方の一つは、プロジェクトのソフトウェア凍結日が やってきたときに開発中のソースの ``snapshot'' を記録するというものです。 凍結した日の後でバグが修正されたら、それらの変更されたリリースの 一部となるソースのみに再度タグをつける必要があります。

シンボリックタグはどのファイルのどのリビジョンがソフトウェア配布物を 作成する際に使われたかを恒久的に記録する意味があります。 checkout, export および update コマンドは、タグをつけたリリースと全く同じものを、リリースのタグが つけられて以降にファイルが変更、追加、削除されたかどうかを気にする ことなく、将来のいつでも取り出すことを可能にします。

標準の -r と -D オプションを使って、すでに特定の タグを含んでいるファイルのみにタグを付けることができます。 この方法はタグの名前を変えるのに使えます。 すなわち、 古いタグで指定されるファイルにのみタグを付け、 それから古いタグを削除すれば、確実に同じファイルで古いタグを 新しいタグで置き換えることができます。

-r または -D フラグに加えて -f フラグを 指定すると、コマンドラインで指定したファイルで古いタグを 持っていないか指定された日時に存在しなかったものにもタグを 付けます。

デフォルト (-r または -D フラグが無い場合) では、 バージョンは明示的に指定されるのではなく、暗黙のうちに作業ファイルの ヒストリの cvs レコードから取られます。

`cvs tag -d symbolic_tag...' とすると、指定したシンボリックタグが追加されるのではなく 削除 されます。警告: タグを削除する前にその根拠をしっかり確認して下さい。 これは効率的に一部の履歴情報を捨てますが、後になってその情報が重要だったと 判明するかも知れないからです。

`cvs tag' はすでに存在するタグを移動しません。 しかしながら、-F オプションが指定されると `cvs tag' はそのファイルに既に存在する symbolic_tag のインスタンスを 新しいリポジトリのバージョンへ移動します。 -F オプションが無い場合、 `cvs tag' を使って すでにそのファイルに存在するタグを付けようとすると エラーメッセージが出力されます。

-b オプションはタグを ``ブランチ'' タグにし、並行して、 独立した開発を可能にします。 これは以前にリリースしたソフトウェア配布物へのパッチを作成するために 最も有効です。

通常、 tag はサブディレクトリに渡って再帰的に実行します。これは 標準の -l オプションを使って抑制できます。 明示的に再帰を指定するには -R を使います。

update は進行状況をファイルごとに 1 行表示することで知らせ続けます。 各行の先頭には以下の `U P A R M C ?' のいずれか 1 文字があり、ファイルの状態を示しています:

-A オプションを用いて sticky なタグ、日付、 -k オプションをリセットできます。(-r, -D, -k オプションの いずれかを使って作業ファイルのコピーを得ると、 cvs は対応するタグ、日付、kflag を記憶し、 以降の update で それを使い続けます。-A オプションを使って cvs にそれらの指定を忘れさせることで、ファイルの ``head'' バージョンを取り出します)。

-jbranch オプションは、変更結果のリビジョンと ベースにしたリビジョンの間での変更をマージします (例えば、もしタグがブランチを指しているなら、 cvs は、そのブランチで行われた全ての変更をあなたの作業ファイルにマージします)。

2 つの -j オプションを指定すると、 cvs は 2 つの それぞれのリビジョン間での変更をマージします。 これは特定の変更を作業ファイルから ``削除'' するのに使えます。 例えば、ファイル foo.c がリビジョン 1.6 をベースにしていて、 1.3 と 1.5 の間で行われた変更を削除したいなら、次のようにします:

example% cvs update -j1.5 -j1.3 foo.c   # 順番に注意...

加えて、各 -j オプションにはオプションで、ブランチと使う場合に、 日付指定を含めることが可能で、選択するリビジョンを指定した 日付の範囲内に制限できます。 オプションの日付はコロン (:) をタグに付けることで指定します。

-jSymbolic_Tag:Date_Specifier

-d オプションを使うと、もし作業ディレクトリに無いディレクトリが リポジトリにあれば作成します。(通常、update は作業ディレクトリに すでに登録されているディレクトリとファイルのみに働きます。) これは最初の checkout 以降に作成されたディレクトリを 更新するのに有用です。しかし不幸にも副作用があります。 もし作業ディレクトリを作る際に慎重にリポジトリ中の特定の ディレクトリを除いた (モジュール名を使ったか明示的に必要な ファイルとディレクトリをコマンドラインで指定したかのいずれかで) とすると、 -d で更新するとそれらの不要かも知れないディレクトリができてしまいます。

-I name を使うと、update の際、名前が name に符合する (作業ディレクトリの) ファイルを無視します。 コマンドラインで -I を 2 回以上指定することで、 複数の無視するファイルを指定できます。 デフォルトで、update はあるパターンに名前がマッチするファイルを 無視します; 無視されるファイル名の最新リストについては、 (このマニュアルページの関連項目の節に記述してあるように) Cederqvist 著のマニュアルを参照して下さい。

いずれのファイルも無視しないようにするには `-I !' を使います。

ローカルで修正したファイルを、 リポジトリ上のクリーンなファイルで上書きするには、 `-C' を使います (修正されたファイルは `.#file.revision' に保存されます)。

標準の cvs コマンドオプション -f, -k, -l, -P, -p, -r も update で使用可能です。