重要な変更を加えた製品の配布に伴なって メジャー・リリース番号を更新した場合、 これに合わせてリビジョン番号も変更したい場合があると思います。 普通はリビジョン番号を気にする必要は何もないのですが、 多くの人がこれを望み、また悪影響もありません。
例えば (変更していないファイルも含め) 全てのファイルを RCS のリビジョン 3.0 に上げるには、 以下のようにします:
$ cvs commit -r 3.0
しかし、製品のリリース番号と RCS のリビジョン番号を
一致させようとするのは、一般的に言って愚かな行為です。
リビジョン番号は、CVS が内部で使用する番号であって、
それ以上の意味はなく、普通は気に掛ける必要がないことを
理解しなくてはいけません。
代わりに tag や rtag コマンドを使い、
特定のリリースに対してタグ名を付けることが
できます。「A.17 tag---取り出したバージョンにタグ名を付ける」 と 「A.15 rtag---モジュールにタグ名を付ける」 を参照。
`-r' に指定する番号は、 既存の全てのリビジョン番号よりも大きい番号でなくてはいけません。 つまり例えばリビジョン 3.0 が存在していた場合、 `cvs commit -r 1.3' はうまくいきません。
オプション `-r' を用いて、枝リビジョン (リビジョン番号が
偶数個のドットを含むもの) に格納することができます。
枝リビジョンは rtag か tag コマンドに
オプション `-b' を指定して作成します
(「A.17 tag---取り出したバージョンにタグ名を付ける」 か 「A.15 rtag---モジュールにタグ名を付ける」 を参照)。
そして 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 [[ ハック中 ]] $ cvs commit
オプション `-r' は作業ディレクトリに貼り付けられるため、 これを指定する必要はありません。
例えば、先週取り出したリビジョンを元にして、 極めて実験的な変更をソフトウェアに加えてきたとします。 ここで実験に他の開発者を加えたいが、 幹の開発系統を妨げたくない場合は、 その変更点を新しい枝に格納すれば良いでしょう。 すると他の開発者も実験中のコードを取り出して、 CVS の衝突解決の恩恵を全て受けることができます。 このシナリオは次のようになるでしょう:
[[ ハックされたソース置場 ]] $ cvs tag -b EXPR1 $ cvs update -r EXPR1 $ cvs commit
update コマンドで、全てのファイルに
オプション `-r EXPR1' が貼り付けられます。
このとき、update コマンドでは
ファイルに対する変更が削除されないことに注意して下さい。
`-r' が貼り付けられているため、
commit すれば自動的に正しい枝に変更が格納されます。
これとは次の手順もあります:
[[ ハックされたソース置場 ]] $ cvs tag -b EXPR1 $ cvs commit -r EXPR1
しかしこの場合、 変更されていたファイルだけに `-r EXPR1' が貼り付けられます。 従って別のファイルを変更して、フラグ `-r EXPR1' を付けずに 格納した場合、誤って幹に格納されてしまいます。
他の開発者が実験に参加する際には、 単純に以下のようにして下さい:
$ cvs checkout -r EXPR1 whatever_module