Skip to main content.
Google custom search

開発者用 CVS 覚書

'HEAD' が、期待したような使い方をできない理由 (トップ)

HEAD は "main trunk 上の最新版" と同義ではなく、実は、 もっと特別な意味を持っています。 'cat' を例に、見てみましょう。

  • "cvs update -A" (または "cvs update -Dnow") すると、以下のリビジョンが得られます: 
    	Makefile	1.9
	cat.1		1.16
	cat.c		1.21
  • "cvs update -r netbsd-1-4-base" すると、以下のリビジョンが得られます: 
    	Makefile	1.8
	cat.1		1.16
	cat.c		1.19
  • "cvs update -r netbsd-1-4-PATCH001" または "cvs update -r netbsd-1-4" すると、以下のリビジョンが得られます: 
    	Makefile	1.8
	cat.1		1.16
	cat.c		1.19.2.1

どの場合でも、 "cvs update -r HEAD" して得られるのは、 "cvs update -A" や "cvs update -Dnow" した時と同じものです。

一方、 "cvs diff -r HEAD" した場合は以下のようになります:

  • current の場合 (あらかじめ "cvs update -A" 等としておいた場合) 、以下の diff が得られます: 
    	file:		1st -r:	2nd -r:
	-----		-------	-------
	Makefile	1.9	1.9
	cat.1		1.16	1.16
	cat.c		1.21	1.21
    (つまり、何も出てきません。)
  • -r netbsd-1-4-base でアップデートしておいた場合は、以下の diff が得られます: 
    	Makefile	1.9	1.8
	cat.1		1.16	1.16
	cat.c		1.21	1.19
    (そう、逆向き (新しいものに対して古いものへの差分) になっています。 "cvs diff -r foo" による比較は、リビジョン foo のファイルが先に、チェックアウト済みのファイルが後になるからです。)
  • -r netbsd-1-4-PATCH001 または -r netbsd-1-4 でアップデートしておいた場合は、以下の diff が得られます: 
    	Makefile	1.9	1.8
	cat.1		1.16	1.16
	cat.c		1.19.2.1 1.19.2.1

いいかえれば、 "cvs update -r HEAD" は、 (少なくとも、 attic 送りになったファイルがない単純な場合に限れば) "cvs update -A" または "cvs update -Dnow" と同義ということです。

しかし、 "cvs diff -r HEAD" は、各ファイルを、 そのファイルの属する枝の最新版と比較します。 枝上の一部のファイル (分岐はしたが、その枝で変更されていない場合) は、差分は分岐元の枝の最新版と比較した結果になります (上述した例では、 cat/Makefile が該当し、 trunk の最新版と比較されています) 。それ以外のファイル (分岐後に分岐先の枝で変更されたファイル) では、 差分は現にチェックアウトされた枝の最新版と比較した結果になります。

いいかえれば、 -r HEAD に対する diff は、ファイルが trunk の最新版と合致するかの確認用としては、 使えないということです。

そういう用途には -Dnow が使えます (ただし、削除済みファイルの存在に関しては、 壊れ気味です……ですが、少なくとも冗長過ぎるということはありません

枝へ commit した後、並列に更新して -kk を使いたい場合は、 以下のように指定することもできます。

  1. cvs update -kk
    (チェックアウトした枝の最新版を、 -kk を指定して取得します。 この枝に変更を加えて commit したばかりであれば、 各ファイルを単に -kk 化するだけです。)
  2. cvs update -A -kk

変更/追加/削除されたファイルがなければ、この二つはどちらも同じ結果になります。

以上ですが、要するに、 HEAD は危険な面もあるので使わないように、ということです。 (cgd)

.cvsignore ファイルは使用禁止! (トップ)

.cvsignore ファイルは、 NetBSD ソースコードリポジトリーの 大半の部分では、使われていません。 (議論の結果、ソースツリーから 追放されたのです。) pkgsrc 以外の全モジュールは、 今もこの禁制下にあります。

.cvsignore ファイル追放の理由は、簡単に言えば、 NetBSD の開発上で問題を引き起こすからです。このファイルによる主な問題は 二つあります: 掃除が不完全になることと、 配布物にゴミファイルが残ることです。

掃除が不完全になる問題についていうと、 NetBSD のソースは、 構築してから掃除すると、元のソースファイルだけが残らないといけません。 もし、 make cleandir して完全に掃除したあとで、 オブジェクトファイルや中間生成ファイル等のファイルといった、 ソース以外のファイルが残ったら、それはバグです。 .cvsignore ファイルは、このバグを隠してしまうので、使ってはいけないのです。

ゴミファイルを含まない配布物を構築することに関する問題については、 配布物にゴミファイルが含まれていないことを確認する一番簡単な方法は、 "cvs update" を "-I! -ICVS" を付けて実行することです。 しかし、 -I を指定して作業をすると、 .cvsignore で指定されている内容が、 CVS で無視されるファイルのリストに追加されます。 このため、 .cvsignore ファイルで指定されたファイルを CVS が将来にわたって無視するようになってしまうのです! この結果どういうことになるかは、明らかでしょう: .cvsignore ファイルで指定されたようなファイルが何かの間違いでソーススナップショットに 紛れ込んだ場合、それを除去できなくなります。

.cvsignore ファイルを含んだパッケージをインポートする場合は、 "cvs import" コマンドに "-I .cvsignore" オプションを付けて、 CVS がこのファイルを無視するようにしてください。

リポジトリー内のファイルの移動や複製 (トップ)

時には、ファイルを CVS 履歴を保持したままで 移動あるいは複製する必要な事態が起こります。 そういったことは CVS ではサポートしていないので、 CVS の通常の クライアント-サーバーの仕組みで行うことはできません。

かつては RCS ファイルそのものを移動するためのスクリプトがありましたが、 今はそういうことはサポートされません。普通にファイルを削除して、 新しい場所にファイルを追加してください。その際、将来追跡がしやすくなるよう、 それぞれに移動先と移動元を書いておいてください。 一度に沢山のファイルを扱う場合は、 cvs add するかわりに cvs import してもかまいません。

リポジトリー上のログメッセージを変更する方法は? (トップ)

cvs commit した後に、その commit メッセージを変更することが必要になった場合は、 cvs admin コマンドを使って変更することができます: 

$ vi /tmp/newmsg
$ cvs admin -m 1.1:"`cat /tmp/newmsg`" file

複数のファイルを commit している場合は、対象のリビジョンとファイル名ごとに、 このコマンドを繰り返す必要があります。 ファイルとリビジョン番号の一覧は、 source-changes メーリングリストに送られているメールから調べられます。 また、対象のリビジョン番号が同じファイルがある場合、それらをすべて引数として与えれば、 一回の cvs admin コマンドで複数のファイル名を指定することができます。

Back to  CVS リポジトリー問題