[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
CVS の多くの利用ではあまりリビジョン番号について心配する必要はあ
りません。CVS は 1.1
, 1.2
などのような番号を割当て、
それだけが皆が知る必要のあることです。しかし、CVS がリビジョン番
号を割当てる方法に関してより知識を持ち、より制御したい人もいます。
どのリビジョンが特定のリリースになったか、などの 1 つより多くのファイ ルを含むリビジョンの組を追いかけたいときは、タグ を使います。そ れはそれぞれのファイルの数字リビジョンに割当てることのできるリビジョン 名です。
4.1 リビジョン番号 | ||
4.2 バージョン、リビジョン、リリース | ||
4.3 リビジョンの割当て | ||
4.4 タグ-文字によるリビジョン | ||
4.5 作業ディレクトリからどれをタグ付けするかを指定する | cvs tag コマンド | |
4.6 どれにタグを付けるかを日付やリビジョンで指定する | cvs rtag コマンド | |
4.7 タグの削除、移動、改名 | ||
4.8 タグ付けとファイルの追加、削除 | ||
4.9 貼り付いたタグ |
各バージョンのファイルはそれぞれ一意なリビジョン番号 (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 section 枝とマージ)。そのようなリビジョン番号は 枝とマージ で詳しく説明されています。
上の説明のように、ファイルは複数のバージョンがあります。同様に、ソフト ウェア製品も複数のバージョンを持つことができます。ソフトウェア製品はよ く `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 section タグ-文字によるリビジョン)。 しかし、
数字リビジョンを設定したいのであれば、cvs commit
の `-r'
オプションですることができます。`-r' オプションは `-f' オプ
ションを暗黙に仮定しますので、ファイルが修正されていなくても格納される
ということになります。
例えば、全てのファイルをリビジョン 3.0 にするためには (変更されていな いものも含めて)、次のように実行するかもしれません:
$ cvs commit -r 3.0 |
`-r' で指定する番号は存在するリビジョン番号より大きくなければなら ないことに注意してください。すなわち、リビジョン 3.0 が存在していると、 `cvs commit -r 1.3' とはできないということです。複数のリリースを 並行して維持したいときは、枝を使う必要があります (see section 枝とマージ).
リビジョン番号は開発に従って徐々に増えていきますが、 ソフトウェア製品のリリース番号とは全く何の関係もありません。 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 section ログ方法を使用者自身が設定する).
次の例は、ファイルにタグを付ける方法を示したものです。 コマンドはあなたの作業ディレクトリで実行して下さい。 すなわち、`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
の構文の完全なまとめと、いろいろなオプションの説明は
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 section 再帰的動作.)
checkout
コマンドの `-r' フラグに、
モジュールから取り出すリビジョンを指定します。
このフラグを用いて、
モジュール ` tc' のリリース 1.0 を作るソースを、
将来のいつでも簡単に復元することができます:
$ cvs checkout -r rel-1-0 tc |
リリース時にタグを付けるようにしておけば、 過去のリリースにバグが発見されたが最新版には無い、 という場合などに非常に便利です。
任意の時間を指定してモジュールを復元することもできます。 See section checkout のオプション. `-r' をこれらのコマンドのどれかに指定す るときは、貼り付きタグに注意する必要があります。貼り付いたタグ 参照。
複数のファイルに同じタグを付けるという事を、 「ファイル名とリビジョン番号の行列の中に線を引く」 と考えると良いでしょう。 以下のリビジョンの五つのファイルがあるとしましょう:
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
はリポジトリの内容に直接作用します (コマンドの前に取り出す
ことを要求しませんし、作業ディレクトリを見に行きません)。
以下のオプションはタグを付ける日付やリビジョンを指定します。完全な説明 は 共通のコマンド・オプション 参照。
-D date
date 以前の一番新しいリビジョンにタグを付けます。
-f
`-D date' や `-r tag' と一緒のときにだけ役に立ち ます。合致するリビジョンが見つからなければ、(ファイルを無視する代わり に) 一番新しいリビジョンを使います。
-r tag
存在するタグ tag を含むファイルにのみタグを付けます。
cvs tag
コマンドは同じ `-r', `-D', `-f' オプショ
ンを使って、ファイルをリビジョンや日付により指定することもできるように
なっています。しかし、この機能はおそらくあなたが望むものではないでしょ
う。その理由は、cvs tag
は与えられたタグ/日付ではなく、存在する
作業ディレクトリに基づいてタグを付けるファイルを選ぶからです。ですから、
普通は cvs rtag
を使う方がうまくいくでしょう。例外はこのような
場合です:
cvs tag -r 1.4 backend.c |
普通はタグを修正しません。それはリポジトリの履歴を記録するために存在し ており、削除したり意味を変えたりすることは、普通は望むことではないでしょ う。
しかし、一時的にタグを使用したり、偶然に間違った場所に付けてしまったり する場合もあるでしょう。ですから、タグを削除、移動、改名するかもしれま せん。警告: この節のコマンドは危険です。それは履歴情報を永遠に捨て去り、 エラーからの復帰が難しくなるか、不可能になります。あなたが CVS の 管理者なら、これらのコマンドを taginfo で制限することを考えるかもしれ ません (see section ログ方法を使用者自身が設定する)。
タグを削除するには、`-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 section 枝とマージ)、`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' は、ファイルを幹の先頭のバージョンに戻し、 貼り付いたタグ, 日付, オプションを全て剥します。
貼り付けられたタグの一番普通の使用法は、枝のアクセス で説
明されているようにどの枝で作業しているかを確認することです。しかし、枝
でない貼り付きタグにも利用法はあります。
ここでは、他人の変更が安定しているかどうか分らないので、
作業ディレクトリを更新したくない場合を例に挙げて考えます。
もちろんこの場合、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
に付けるのが良いでしょう。さらなる議論は、二つのリビジョン間の差分をマージする 参照。
[ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by Akihiro Sagawa on June, 15 2005 using texi2html 1.70.