[CVS超入門]

▼修正済のソースツリーを CVS 管理下に移行する

要するに、他から持ってきたプログラムを改造しまくっているが、 そろそろバージョン管理しないと収拾つかなくなってきた、という事例。

大抵の場合、すでにいじくり倒したブツが入っているディレクトリ がありますね？ とりあえず projectY/ と しときましょう。

まだRCS化もしてないとします。 RCSからの移行は別途。

• 下準備
• オリジナルを登録する
• 確認
• 作業領域の移行
• 修正物を登録

$Id: cvs-lmod.html,v 2.4 2017-10-05 21:18:18+09 kabe Exp $

▽オリジナルを登録する

まず別のところに projectY のオリジナルを展開します。 んでオリジナルの ディレクトリに入り込んで (basename `pwd` == projectY)

	% cvs -d ~/cvsroot import projectY VENDOR RELEASE_X

▽引数解説だ。

マニュアルとかでは "repository" "vendor-tag" "release-tags" としか書かれてないからわけわからん。

repository

上の projectY の所。難しいことは抜きにすると、 要するに ~/cvsroot/projectY として リポジトリにディレクトリが掘られる。 (`pwd`が projectY かどうかは実は関係ない。)

vendor-tag

VENDOR の所。 「オリジナルの最新版」に対する名前として使うので、 単なるパッケージ名(バージョン番号なし)が普通。
RCS 的には、版番 1.1.1 にこのタグ名がつく。 要はベンダ枝に対してつける枝タグ。

release-tags

RELEASE_X の所。 普通はバージョン番号のついたタグ名 (VERSION_1_0とか)をつける。 風習として全部大文字で書くことが多いようです。
RCS 的には、版番 1.1.1.1 にこのタグがつく。 要は点タグ。

repositoryで指定したものが、 あとで cvs checkout で指定する「モジュール名」や 作業用に掘られるディレクトリ名として使われていくので、 ここに細かいバージョン番号が入ったもの (projectY-2.5.3とか)は 使い勝手が悪くなるのでおすすめしません。 細かいバージョン番号は release-tagsで指定すべし。

タグ名のつけ方には特に構造はなく、人間が勝手に決めます。 VERSION_1_0 でも version-1-0 でも CVS にとっては単なる 文字列なので、プロジェクト内(もしくは俺様脳内)でなんらかの 合意をしておくこと。

▽importてなんだよ。exportじゃないのか

一人称がリポジトリ側なので import なんですねぇ。 export コマンドは「リポジトリから配布用に取り出す」です。

▽なんで 1.1.1なのさ

俺様がいじくる枝が幹 (X.X) として使えるように、です。

▽なんで 1.1.1 と 1.1.1.1 にタグをつけるのさ。同じぢゃん

将来、ベンダから別のリリースが出たとき、 別の版番がつけられるように、です。 VENDORで索けば最新版を指すようになります。

▽オリジナルのRCS版番がつけ替わるのはいやじゃ

cvs import ... -kb とすれば、 $Id ... $ などのキーワードは置換されずにそのままになります。 実際は、リポジトリへの登録は常にオリジナルのままで行われている (RCSも同じ)ので、 次の checkout や update でのキーワード置換を抑制せよ、という 「ひっつきオプション」(sticky option)がつきます。

% ident Makefile.in
Makefile.in:
     $Id: cvs-lmod.html,v 2.4 2017-10-05 21:18:18+09 kabe Exp $
% cvs stat Makefile.in
===================================================================
File: Makefile.in       Status: Up-to-date

   Working revision:    1.1.1.1 Fri Jun 14 19:39:25 2002
   Repository revision: 1.1.1.1 /usr/local/src/wnn/cvsroot/FreeWnn/Makefile.in,v
   Sticky Tag:          (none)
   Sticky Date:         (none)
   Sticky Options:      -kb

とりあえず気が済んだら、オリジナルは不要なので消します。

▽本当に登録されてるのか

確認してみましょ。ls -lR ~/cvsroot/projectY の中身が詰まっていることで 納得すればそれでもいいですが、明示的に取り出してみましょう。 安全のため新しくディレクトリを掘って、その中で

	% cvs -d ~/cvsroot checkout projectY
	cvs checkout: Updating projectY
	U ....

なんか登録されないファイルがあるんですけど？

▽そろそろ俺様の修正を登録したいぞ

まあまあ。実は大きな問題があって、今あなたが保有している 修正ソースツリーは 「作業領域」(working directory) として 認知されていないので、CVS関係のコマンドが使えんのです。 (cvs import は数少ない例外。) 具体的には各ディレクトリに CVS/ がない。

マージ作業は「まっとう」な方法がないらしく、 しょうがないので力業です。…

1. リポジトリから取り出して「作業領域」を作る

安全のためディレクトリを掘ってから、 cvs -d ~/cvsroot checkout projectY として ./projectY/ を取り出します。

2. CVS/ 以外のファイルを全部消す(ぉ

% find projectY -name CVS -prune -o -type d -true -o -exec rm -f {} \;
なお、オリジナルから消したファイルは ない と断言できるのであれば、 この全消去操作はやらなくてもかまいません。

3. いじくった俺様ソースツリーを「作業領域」へコピーする

% (cd ...俺様/projectY; tar cf - .) | (cd projectY; tar xvf -)
左側が俺様修正の入ったもの、右側が新しい作業領域。

これで新しい projectY/ が作業領域として使えるようになりました。

だから今までの修正ツリーをCVS化したわけではなく、 新しい CVS 作業領域に今までのツリーをコピっただけです。 もちろん逆手順も可能ですが、間違えると被害が大きい。

確認：新しい projectY/ に入り込んで

	% cvs -n update
	cvs update: Updating .
	....

▽やっと登録できる

その前に、 cvs -n update で、頭に '?' がついているファイルがあれば 始末をつけておきます。

'?'がつくファイルは、リポジトリ中にはない未認知ファイルを 表します。単なる一時ファイルとかであれば無視していいですが、 今後必要なファイルであれば cvs add filename で登録します。

	% cvs add new_file
	cvs add: scheduling file `new_file' for addition
	cvs add: use `cvs commit' to add this file permanently

この段階で cvs diff を使えば、一網打尽 diff が取れるので、 更新ログの文句を考えておくこと。 cvs diff -u なんかも使用可能。

いよいよ本登録を cvs commit で行います。 やっぱりエディタが起動するので、書けるのであれば 更新ログを書き連ねておきます。

	% cvs commit
	((エディタ起動中))
	Checking in new_file;
	/....../cvsroot/projectY/new_file,v <-- new_file
	...

▽おつかれさまですた

しばらくいじくりまわしてみて、何とかなりそうだと思ったら、 以前まで使っていた俺様ディレクトリを廃棄して現行の作業領域と入れ替えます。 どこかで cvs checkout projectY として、必要なものが全部出てくれば完全です。