Warpっぽくいこう

CVSVSRCS なーんつって (？) -- 2000.10.10, 2000.10.18

ホントはこう。CVS vs RCS。・・・ つっても対決って訳じゃないんだけどね。ま, なんとなく。

さて, バージョン管理っつったって, 世の中には CVSしかない訳じゃない。 ちゃーんと SCCS(Source Code Control System) だとか RCS(Revision Control System) とかもある訳よ, コレが。 (他にも探せば見つかるだろーけど)
でも, CVSがもてはやされるのにも理由がある。 SCCSとか RCSは古いからなのだ ・・・ って断言するほど古い訳でもないけどね。
あまり大規模のソレに向いていない ってことだと思う。
ま, config.sysの管理なんかだと RCSのがよかったりするんだけどね。

まず, ここでは RCSを取り上げて CVSと比較してみよー。

1. CVSは, 一つ一つのファイル以外に, 全体の番号(リビジョン番号とかタグ)も持っている。それにサブディレクトリ以下も管理する。
2. 貯蔵庫(repository)を, バラバラではなく集中管理している。んで, ネットワーク上にソレをもって管理する事もできちゃう。
3. だれかが修正終わるまでロック ってのじゃなく, いつでも誰でも修正可能。衝突(conflict)することもあるけどね。

こーしてみると, えらく違う気がする。そー思うかもだけど, あろーことか CVSの内部は RCSで動いてたりする。 そう, 少し古いバージョンの CVS 1.9.2? あたりは, cvsを動かすために rcs と diff と patch が必要だったのだ。ジャーン。 てゆーより, 最初の CVSは(RCSを動かすための)単なるスクリプトだったとも聞いてるにょ。

どーだろー, 似ていると言えば似てなくもないのかも。

で, コレが RCSから発展したってことで, 気を付ける点とかあったりなんかする。
まず, ファイル名変更ができない。できないっつーか, いったん削除して ソレを別の名前で追加するって手もあるんだけどね。 でも, 苦肉の策って感じも否めない。
さらに問題なのは, ディレクトリの変更。コレがファイルだと 先ほどのソレで何とかしのげても, ディレクトリのばやい無理っぽい。手元に貯蔵庫(repository)があるのなら, ソレも一緒にアレすることで なんとかできるかも知れないんだけどね。

◇

比較のとこで分かるよーに, RCSでは追加だろーが更新だろーが ファイル名を指定する訳だから何だってよい。 つまり指定のファイルが元々なければ追加だし, (RCSディレクトリに)すでに存在してたら修正ってこと。
対して, CVSではワーク・スペースでコマンド実行するだけで Entriesファイルを元にいろいろやってくれるんだけど, だからとゆって, ワーク・スペースに存在するファイルをいちいちディレクトリ探査してる訳でもにゃい。 てことで, ファイルを追加するときだとか取り除くときには明示的に指定する必要があるって訳よ。

• cvs add ファイル名
• cvs remove ファイル名

で, そののちチェックイン(てゆーか コミット)って寸法。

新規にチェックインするのは, cvs addだけじゃなくって, 一回目にも紹介した cvs importてのもある。 こちらはディレクトリ探査を行いながら勝手にどんどん追加してくし, リビジョン番号を 1.1.1.1 とかにしちゃうし(コレは仕様なんだけど), バイナリ指定の -kb だと全部が全部ソレになっちゃうし, それからそれから ・・・ そー, 変なテンポラリファイルまで追加してくれるし, もー 文句いっぱい。(ディレクトリ探査すんのは便利なんだけどね)
あ, 一番の違いはコミットしなくても cvs import自体がソレっぽいってとこかな。

cvs importには他にも問題がありそーなんだけど, 詳しく調べきれていないんで置いとくとして ・・ んで, だったら cvs addがいいじゃんってことで, 幾つか 主砲 手法があるにょ。

1. ディレクトリだけ作って cvs import → cvs co して,
   • find . -print | xargs cvs add
   • または find . \! -name . -print | xargs cvs add (↑の発展形)
   そー, コレが 雑記(Misc)でつぶやいてたことなのら。
2. でもでも, cvs add にはファイルを複数指定できるから ・・・ cvs add * って指定もよいかも
3. 他の方法としては, こんなのもあるにょ。
   1. cvs co -l .
   2. md 貯蔵庫名
   3. cvs add 貯蔵庫名 # ← ここで repositoryが作られる
   4. cd 貯蔵庫名
   5. 〜 ここからは普通の作業 〜
   6. cvs add test.c # ・・ とか何とか

こーして出来上がったもの, 例えば貯蔵庫だと RCSのものと全く同じなんで ファイル名,v とかゆーのが出来るはず。 コレをどっかに持ち運んで, 今まさに作ったよーな振りしても ソレはソレでオッケーってな感じ。たぶん。(^^)

駆け足だった気がするけど ・・・ では。(^^)/~

ＣＶＳ っつーディレクトリ -- 2000.8.31, 2000.9.1

今度は, ソレの構造。 そう, cvs co SilkWeb ってときの, ディレクトリの構造にょ。

 work\SilkWeb
 |-- CVS
 |-- sys
 |   `-- CVS
 `-- usr
     `-- CVS

 SilkWeb
 |-- sys
 `-- usr

どこが違うのか？ 間違い探しみたいで, ちょっち見つけにくい。 ・・・ ってことないねよ, やっぱし。 各ディレクトリごとに「CVS」っつーサブディレクトリが作られる訳。
じゃ早速, その中に どんなファイルが入ってんのか見てみよー。

 work\SilkWeb
 |-- CVS
 |   |-- Entries
 |   |-- Repository
 |   `-- Root

  〜

も少し何か入ってるかと思えば たったコレだけ。他の「CVS」サブディレクトリにも同じものが入ってる。そして, その内容はファイル名から推測できちゃうよーなものなのだ。

• それぞれの(「CVS」の上位の)ディレクトリの, ファイルエントリー(Entries)
• それに, リポジトリ(Repository) ・・・ このばやい SilkWeb って入ってるはず
• んで, CVSのルート(Root) ・・・ つまり, どこから持って来たかって情報

Root があるってことで, cvs diffするときなんかは, ここから情報が得られる訳。だから set CVSROOT=\home\cvs も, それに CVSオプション-d の指定も必要ないのら。

OS/2版だったら さらにおまけ付き。10000002.tmp とかゆー, サイズ０のファイルが入ってたりする。んで, コレ, たぶんバグ。わっはっはー。 (←ぉぃ)
きっと cvs importしたときのテンポラリファイルなんだろうね。 だから削除してもオッケ。 Repository側も cvs remove ＜ファイル名＞ で消しといた方がよいかも。
σ(^^) の環境なら こんな感じなんだけど, もっと新しいバージョンじゃ直ってるのかも。ちなみに σ(^^) が使ってんのは↓

  [C:\Home]cvs --version

  Concurrent Versions System (CVS) 1.10.7 (client)

◇

んで, 今度は Repository側のディレクトリを見てみよー。

 \home\cvs
 |-- CVSROOT
 |-- SilkWeb
 |   |-- sys
 |   `-- usr
 `-- rexx
     |-- contrib
     |-- demo
     `-- trip

そう, そこには CVSROOT, SilkWeb, rexx の三つのディレクトリが出て来たりなんかするんだども, 後の二つってば σ(^^) が作った Repository。 てことは, CVSROOT って何？ なんでこんな見慣れないものが？ もしかして知らないうちに小人さんが作ってったとか。 (←なことはない)

実はコレ(CVSROOT), CVSそのものの Repositoryだったりするのら。CVSをカスタマイズするときにゃ コレを使ってアレするのだ。実際そこにはソレなりのファイルがそろっていたりするにょ。
でも, ちょっと待って。ストップ。いきなりソレらのファイルを変更しちゃなんねー。つっても読み込み専用になってるから, そのままじゃ変更出来ないんだけどね。 CVSROOTディレクトリに入ってるファイルに限らず, ここいらのファイルは, すべて CVS用 てゆーか RCSのソレなのら。 だから, こーゆーのを変更するのなら, cvs co CVSROOT って感じで, どっかに展開してから編集しようね。あ, それから, 編集したら忘れずに cvs commit にょ。

・・・ 時間切れかも。あはは。
次回は, 「diffと patchにみる差分の文化」？ それとも, 「rcs ・・・ 古代文明の遺産」？ さぁ, どっち？
って, どっちでもないかも。

ＣＶＳへのご招待 -- 2000.8.16

うにょにょ〜ん。 さて, CVS ってゆーのをご存じだろーか。 アレですにょ。リビジョン管理だとか, バージョン管理だとか, そーゆーたぐいのものにょ。 つまり, 何かのソースプログラムを持っているのなら, コレに管理をゆだねることで, たとえ雪が降ろーと, 雷が落ちよーと, 世間の荒波が押し寄せて来よーと, もぉなんでも来ーい って感じなのら。 (← 違う)
今回は, ソレについてのお話し。

んで, ソレは 具体的にはどーしたらよいのだろー。 ソースファイルを管理してくれるっつったって, 勝手に思いのまま編集してくれる訳じゃないし。 ま, ホントにそーだったらありがたいかも。 でも, 無茶苦茶に編集されるんだったらダメだけどね。 (←有難くないって)

1. cvs checkout SilkWeb
2. cd SilkWeb
3. epm /r SlkCGI.cmd ・・・ ソースファイルの編集
4. 〜 時の流れ 〜
5. cvs commit -m "変更内容, てゆーか理由"

凡例： CVSのコマンド, プロジェクト名とか, ここでの例

たとえばコレは, 事前に SilkWebが repository (リポジトリ) として登録されているばやいの話ね。 repositoryっつーのは, 英和辞典によると「倉庫,貯蔵所」とかゆーことらしい。
↑の例は, まずソレを cvs checkoutでゴッソリ取り出して, んで, その中の編集したいものを編集する。やっぱ, 勝手に編集してくれる訳じゃないんだね。 (←当たり前だっての)

てことで, つまり, 幾つかのソースファイルをフォルダー(ディレクトリ)にまとめて, 普通はソレごとアレする訳にょ。 もし, すでに chekcoutしてたら, (2)から始めてよい。 あ, epm ってのはエディターね。拡張エディターのことだお。

で, 編集が終わったら 一通り動作を確かめて, 「これでよいかも」てことになったら, repositoryに書き戻す。つまり checkinみたいなもの。 ・・・ の前に, cvs -n update で 変更したもの一覧だとか, cvs diff で どの部分が変わったのか, そーゆー情報を (編集した本人なら知っているだろうけど)あらためて知ったりできるのら。

◇

こーんな感じ↑で使ってくんだけど, でも最初に準備↓が必要だもん。

1. set CVSROOT=\home\cvs
2. cvs init
3. cd オリジナルが置いてあるディレクトリ
4. cvs import -d -m "First release" SilkWeb SilkWeb r1_1

cvsの管理領域を作るため (2)が必要なんだけど, でも, 一度実行すれば cvs initは(この CVSROOTには)もう使わないはず。きっと。
そんで, その場所の指定に (1)が必要。あと cvs importとか cvs checkoutの時とかね。config.sysにでも指定しとくとよいかも。それとも -d で毎回指定してもよいね。
最初に repositoryを登録する(作る)のが (4)。もしそこで続けて編集するなら cvs checkout -d . SilkWeb ってするといいかも。んで, こちらの -d は日時をアレするオプション。
ま, 分んないときはいつでも聞いてねっ。・・・ cvs --help import って感じで。

まとめだけど, コレのよいとこは何かっつーと ・・・

• バージョン管理っつーだけあって, (いくつか前のものであっても)以前の状態のものを簡単にとりだすことができる。
• だれが, いつ, どこで, なにを, どんな理由で, とゆー情報がきちんと管理されている。きちんと登録しておけば。(^^) 少なくとも, 目的っつーか理由は記入する必要があるけど。
• じつは, コレ, ネットワークにも対応していて, remote repositoryを持ってるサーバーと, 数台のクライアントマシン なんてーことも可能。
• んで, OS/2 だけじゃなくって, UNIX, MacOS, ウインドーズでも動く。
• てーことで, 同じファイルを複数の PCで編集しても, それなりになんとかできる。 (←なんとかって 何)

あ, でも, ソースファイル管理ってだけじゃなくって, config.sysの履歴なんかにも使えるかも。 cvsでソレができるかどーかは知らないけど, 同じよーなものに rcsってのがあるんで, そっちならだいじょぶじょぶ。

◇