CVS import

cvs import -m 'comment' module-path vendor_tag release_tag

などについて。

初めて cvs の保管庫を作って、その中に何かを登録する時 (これも参照のこと → start-without-import)
自分で新しくプログラムや、文書を作っていたが、それを cvs 管理にしたい時
「オープンソースの追いかけ」(オープンソースの追っかけ)をしたい時

には、cvs import を使う。cvs import は、現目録(current directory) にあるものを cvs 保管庫に登録する。
(保管庫をもしまだ作っていないなら、次のような方法で、予め用意しておく)

mkdir  /home/cvs-root
setenv CVSROOT /home/cvs-root
cvs init

ここでいきなり cvs add とやっても、次のようになってしまう。

ttyp5:makoto@u  10:04:05/020805(~/)> cvs add test-module
cvs add: in directory .:
cvs [add aborted]: there is no version here; do 'cvs checkout' first
ttyp5:makoto@u  10:04:38/020805(~/)>

なので、普通は、最初に import を行なっておく。しかし例えば CVS/Root, CVS/Repository CVS/Entries $CVSROOT/module-name を手動で作れば、 cvs import 無で始めることも可能ではある。その時は次のようにする。

cvs import をしないで手動で始める時
名前	内容例等	説明
CVS/Root	/home/cvs-root	$CVSROOT
CVS/Repository	my_name	$CVSROOT の下の名前
CVS/Entries	D/sample////	mkdir sample して見る
$CVSROOT/module-name	mkdir $CVSROOT/my_name	保管庫の方も作っておく

cvs import の書式は次の通り。

cvs import -m 'comment' module-path vendor_tag release_tag

-m で説明を加える。module-path が保管庫(またはその中の path) の指定になる。

上で二つ tag という字が出て来るが、この二つは大きく違う。

vendor_tag というのは vendor 枝の名前 (ずうっとこの名前が付く)
もし同じ名前が以前に登録してあれば、その枝の(新しい)葉として登録される。
release_tag というのは、この葉(の集合)に付ける名前 (この時点限り)

しかしどちらにしても全て自分で考えて名前を付ける必要がある。

import が終ったら、そこに置いてあったものは不要になる。後の作業は、別に目録 (directory) を作って、そこに checkout して行う。

import の時に

無視されるもの

RCSLOG RCS SCCS CVS* cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* *.old *.bak *.orig *.rej .del-* *.a *.o *.Z *.elc *.ln core

linux の kernel を、何も考えないで import すると net/core を無視してしまう。 -I\!\* のようにしておけば、それを避けられる。一例:

cvs -d /export/cvsroot import -I'!'  -m 'initial import' linux FSF v2_4_17 2> ../err 1> ../log &
tail -f log | grep ^I

この grep の操作の結果として、表示に (本当は必要なものなのに) 先頭に I の字が出ていたら失敗

逆に無視して欲しい時

には、 -I の後に名前を書いておけば良い。複数のものを無視して欲しい時には、例えば

-I'*.ncb' -I'*.sln' -I'*.suo'

のようにすれば、その三つの接尾辞が付いているものは無視される。実際には次のようにする。

cvs -d /export/fr import -I'*.ncb' -I'*.sln' -I'*.suo' -m 'message' module_hoge VENDOR tag

これは例えば、それらは後から -kb を付けて二進形式 (binary mode) で追加する、などという方法の時に良く使う。

実際に import する前に、ちょっと回り道。

幹(trunk) 枝(branch) 葉(leaf)

↑ 枝分れ ↓

→ → (葉の番号)

(枝 1.2.2)             +--1.2.2.1 ---                            1.2 を基に自分で tag, rtag を使って作った枝
                      /
                     /
(枝 1)     1.1 === 1.2 === 1.3 === 1.4      幹 trunk             1 という(特別な)枝に .1 .2 .3 .4 という葉が付いている
              \      
               \      
(枝 1.1.1)      +--- 1.1.1.1 --- 1.1.1.2    vendor branch         1.1.1 という (1.1 を基にして作った)
                |                                                枝に  .1 .2 .3 .4 という葉が付いている
                |
(枝 1.1.3)      +--- 1.1.3.1 --- 1.1.3.2    vender branch(その二) 1.1.3 という (1.1 を基にして作ったもう一つの別な)
                                                                  枝に ...(以下同じ)

上の図では、縦軸が枝の番号/ 横軸が葉の番号

幹	枝 1 というのが、別名幹(trunk) という特別な枝。しかし性質としては枝。
枝	枝の番号はいつも奇数桁。奇数桁とは、1.1.1 のように数字が三つ並んでいること。最後の桁が本来の枝番。 1.1.3 なら 3 が枝の番号ということになる。残る前の方、先の例では 1.1 は基になった葉の番号。その葉から分れて出来た枝という意味になる。	枝番	偶数	tag,rtag で作る
			奇数	import で作る
葉	枝に一つ数字を作けて葉になる(つまり偶数桁)。改訂(Revision) という言葉が使われるが、「葉」の方が分り易いと思う。

枝 1.1.1 というのはちょっと特別

import には二通り意味があって、

人様からもらったもの (open source)
自分で作ったもの (from the scratch)

があるが、どちらの場合も、結局は、何でも始める時には、

import を使って 1.1.1 に登録する。

ところが、これを(別のところに持出して)、何か変更してから、 commit で保管庫に反映すると、(枝 1.1.1 の葉にはならずに) それは 1.2, 1.3 のように、幹に作用する。

多分これは歴史的な理由か何かだと思うけれど、最初の import は必ず 1.1.1 に行なわれて、それが 1.1 と意味的には同じだからだと思う。

自分で新しくプログラムや、文書を作って、cvs 管理にしたい時

という訳で import して 1.1.1 とし、後は commit, tag して行けば幹での作業になる。あるいは、import は使わずに、作った時点で一つ一つ cvs add して行くというのが一つの方法。その時には最初に、保管庫側に目録(directory) を付って持出しておく。

「オープンソースの追いかけ」をしたい時

何が問題かと言って、 (itojun さんからの情報にも書いてあるが)

もらって来て、少し直す。
動いた。
するとむこうが新しくなっている。
もう一度変更し直し ?
ああ大変

が「大変でなくなる」

つまり、

「むこうが新しくなっている」のを、
最初に自分で決めて import した vendor_tag と同じ vendor_tag で import すれば
1.1.1.1 だったものが
1.1.1.2 などのように登録されて vendor 枝が伸びて行く。
その差分を(自分で変更している)幹に戻すことが出来る。そういう時、簡単には
```
cvs update -j 枝の名前
cvs update -j 枝の名前 filename
```
(ここの例で言えば「枝の名前」は vendor_tag になる)
等とすると、「枝の名前」に行なわれた修正が、自分の作業域の方に反映される。一つ目の方法は、「全ての変更を」になるし、二つ目の方法は「filename に行なわれた変更を」になる。
実際には、その後に commit をすると、初めて幹が変更される。

cvs import -ko ....

のように -ko を付けておくと元々付いている $header$ などを変更せずに、そのままにしてくれる。自分で作っている時や、何か project に参加している時には不要だが、勝手に追いかけをやるとか、日本語 patch を作って配ろうという時などには、 -ko を付けて、元の RCS tag を保存する(のが普通だと思う)

オープンソースにも枝がある時

もし「むこう側」が複数の版を並行して開発している場合、例えば -current と stable など、の場合には、 import する時に -b 1.1.3 のようにして枝を作って、 import すれば良い。

Last Update

19:53:07 03/12/08
claudebot
Apache/2.0.65 (Unix) mod_ssl/2.0.65 OpenSSL/1.0.1g DAV/2 PHP/5.4.26
 (since 2002/02/03)