Kernel hackerのためのcvs入門 (初心者向け)

$Id: tut-kernel.html,v 1.32 2001/10/29 09:23:37 itojun Exp $

概要

• ひとりでhackしていても
• ちょっとしたkernel hackでも

まえがき

• FreeBSDのバージョンはどんどんあがる
• ついていくのが大変
• かといって、あまりに実験的なのでFreeBSD本家にマージしてもらうわけには いかないぞ
• バージョン管理で頭が痛い
• 配布したくてもパッチキットの作成が大変
• パッチキット作成をさぼっちゃう
• 配布しないと使ってもらえないから、テンションさがる、やるきが落ちる
• せっかく作ったものがごみになっちゃう

そこで、cvsを使いましょう。 cvsが威力を発揮するのは、

• 複数人での並行開発
• ディレクトリツリーまるごとのバージョン管理
• 複数のマシンを使い分けての開発

以下の説明には、簡単のために省略していることや、わたしが誤解していることが あると思います。 まあ、とりあえず入門書ってくらいなので、多めにみてください。 ほんとのことはman pageとかinfo fileとかに書いてあります。 「これはひどい」ってのがあったら 教えてください。直します。

cvs入門

とりあえず、cvsは(beta versionですが)1.9.10かそれ以降を使ってください。 1.8だとdiffの生成にちょっと虫さんがいるように思います。 1.9だとファイルの追加やsticky tagの処理に虫さんがいるような気がします。

その1: カーネルの改造作業をする

ステップ0: イメージトレーニング

FreeBSD 221-RELEASE === FreeBSD 222-RELEASE ===>
  \			  \
   \			   \
    改造版221 ----->        改造版222 ----->

恐がることはなにもない。 失敗したら最初からやりなおせばいいだけの話。

ステップ1: リポジトリの準備

% cd ~
% mkdir practice
% mkdir practice/cvsroot
% setenv CVSROOT ~/practice/cvsroot	# 環境変数設定
% cvs init				# 初期化

ステップ2: 最初のバージョンのimport

• importしようと思っているディレクトリツリーのてっぺんを カレントディレクトリにしてからimportする。
• もともとついてるRCS tagを保存したいので、-koオプションをつける。

% cd /usr/src/sys
% cvs import -ko sys FREEBSD r221

FreeBSD 221-RELEASE === FreeBSD 222-RELEASE ===>
  \			  \
   \			   \
    改造版221 ----->        改造版222 ----->

試しに、FreeBSD 2.2.1-RELEASEのソースをとりだしてみよう。

% cd /tmp
% mkdir x
% cd x
% cvs co -r r221 sys

ここで注意しないといけないのは、 r221みたいな、基本の枝には変更を加えちゃいけない ということである。 これをやってしまうと、あとでdiffとれなくなるのだよ。 次に枝わかれのさせかたとかをやるので、変更するならr221以外の枝について 作業をしましょう。

ステップ3: 枝わかれさせよう

% cvs rtag -b -r r221 itojun221 sys

FreeBSD 221-RELEASE === FreeBSD 222-RELEASE ===>
  \			  \
   \			   \
    改造版221 ----->        改造版222 ----->

% cd /tmp
% mkdir y
% cd y
% cvs co -r itojun221 sys

ステップ4: 改造しよう

% cd /tmp
% mkdir y
% cd y
% cvs co -r itojun221 sys

ファイルを変更する

とりあえずいきなり編集してしまってよい。

編集が終ったら、cvs commitとすると、itojun221の枝の 最新版としてリポジトリにとりこまれる。 cvs commitはディレクトリ木全体に働くので、 ある木の下を全部commitしたければ、てっぺんでcommitしたらいい。

ちなみに、どの枝に対して変更が加わるかは、 「どの枝をcvs coしたか」で決まる。 各ディレクトリにCVSていうディレクトリがあるはずだけど、 ここに覚えておいてもらえるのだ。 たいていはこれで問題ないはずだ。

「リポジトリに」ディレクトリを追加する

ディレクトリのあるところに行って、cvs addする。

% ls
foo/	baa/	baz/
% cvs add foo

追加をリポジトリに反映させるためには、cvs commitすること。

別にcvsに管理してもらいたくないディレクトリをほるのは、普段どおりで 構わない。

やまもりディレクトリ/ファイルを追加するときはcvs importを 使いましょう。

「リポジトリに」ファイルを追加する

リポジトリ上で管理されるファイルを増やしたいときは、 ファイルのあるところに行って、cvs addする。 再帰的にaddしたり、"/"を使ってパスを書いたりはできないので、 addしたいファイルがやまほどあるときは各ディレクトリを訪問すること。 それから、親ディレクトリは全部先にcvs addしておかないとダメ。

追加をリポジトリに反映させるためには、cvs commitすること。

てもとでファイルを置いておきたいだけなら、そのまま置いておいていい。

やまもりディレクトリ/ファイルを追加するときはcvs importを 使いましょう。

「リポジトリから」ファイルを削除する

リポジトリ上で管理されてたファイルの管理をやめさせたいときは、 もとになるバージョン(FreeBSD 2.2.1-RELEASE)にはあるんだけど、 改造版には要らないファイルを削除するには、cvs remove -fを 使う。

% ls
foo	baa	baz
% cvs remove -f foo

削除したことをリポジトリに反映させるためには、 cvs commitすること。

てもとでファイルを削除したいだけなら、いきなり削除していい。

ファイルをリネーム

これはちょっとめんどくさいので、cvs FAQをよんでください。 「リネーム」の場合に、バージョン情報をどう扱うのかは結構難しい 問題なので、利用者のセンスがちょっと問われる。 簡単に言えば、単純にremoveしてaddすると、バージョン 管理情報が引き継がれないのです。 引き継がれないと困ることもあるし、引き継がれると困ることもありますよね?

差分をとる

リポジトリに入ってるitojun221の状態と、 てもとのディレクトリの差分をとるには、こうする。 全部commitしてあれば、なにも表示されないはずだ。

% cvs diff

context diffがいいな、とかいう場合には-cをつける。

% cvs diff -c

特定の枝の最新版と作業ディレクトリの差分をとる (例: 2.2.1-RELEASEとの差分) ときには、-r 枝の名前とすればいい。

% cvs diff -c -r r221		# 2.2.1-RELEASEと作業ディレクトリの差分

特定の枝の最新版どうし(例: 2.2.1-RELEASEと、itojun221)の 差分をとりたくなったら、-rをふたつつける。 現在いるディレクトリについての差分が見れるはずだ。

% cvs diff -c -r r221 -r itojun221	# 2.2.1-RELEASEとitojun221の差分

注意: GNU patch 2.5は、cvs diffで作ったdiff fileを 処理できない。 Index:行を優先して見るpatchコマンドでないとダメ。 今後のcvsのバージョンアップで状況は改善されるかも、しれない。

変更状況を見る

commit前にファイルの変更状況を見たいときは、cvs -n update とする。 本来は他のひとがリポジトリを書き換えたときに、その状況を てもとのディレクトリに反映するコマンドなんだが、どうせいまは ひとりで作業していることになってるので、問題なし。

行頭の文字の意味はこんなかんじ。

A: addされていてまだcommitされてない

M: 変更されていてまだcommitされてない

R: 削除されていてcommitされてない

?: リポジトリに入ってないファイル。入れのこしがないよう 気をつけよう(*.oとか、.cvsignoreに羅列された ファイルは無視される)。

リポジトリに入れたくないファイルはどうしよう?

cvsは*.oみたいな、よくある「無視してほしいなってファイル」を 無視してくれるようになっている。 が、場合によってはyacc使ったりするときのように、*.cなのに 無視させたいファイルがでることがある。

そういうのを指定しておくには、各ディレクトリに.cvsignoreって ファイルを置こう。 .cvsignore自体もcvsで管理するのを忘れずに。

% echo 'foo.c' > .cvsignore
% cvs add .cvsignore

他には?

思い付いたら追加します。 知りたいことがあったら言ってね。

ステップ5: コンパイルはどうするの?

sys/compileの下が邪魔なら、.cvsignoreで制御してあげればよいと 思います。

ステップ6: FreeBSDの配布をおっかけよう

• 2.2.2-RELEASEをリポジトリに取り込む
• 2.2.2-RELEASEに対するパッチ版をつくる

まず、2.2.2-RELEASEのソースをリポジトリに取り込みます。

% cd /usr/src/sys		# 2.2.2-RELEASEのソースツリー
% cvs import -ko sys FREEBSD r222

FreeBSD 221-RELEASE === FreeBSD 222-RELEASE ===>
  \			  \
   \			   \
    改造版221 ----->        改造版222 ----->

% cvs rtag -b -r r222 itojun222 sys

FreeBSD 221-RELEASE === FreeBSD 222-RELEASE ===>
  \			  \
   \			   \
    改造版221 ----->        改造版222 ----->

% cd /tmp
% mkdir z
% cd z
% cvs co -r itojun222 sys
% cd sys
% cvs update -j r221 -j itojun221

<<<<<<< foo
nantara kantara
=======
kantara hontara
>>>>>>> r1.1.1.1.2.1

その2: もっとらくちんになろう

他にもtcl/tkなフロントエンドなんかもあるらしいが、使ったことないので割愛。

その3: 配布キットの準備をする

% cvs rdiff -r r221 -r itojun221 sys >sys.diff

• rdiffは、リポジトリに入ってるものどうしの差分をとる。 てもとにcvs checkoutしたツリーがなくてもいい。 そのかわり、モジュールは指定しないといけない。
• diffは、てもとのcvs checkoutしたツリーと リポジトリの間の差分をとる。 モジュールは言わなくていいけど、作業ディレクトリに いるときじゃないと使えない。

とりあえず、diffの作成が楽になっただけでもcvsを導入した甲斐はある、 というものだ。

その4: 複数のノートパソコンで開発する!

複数台のノートパソコンを使い分けている場合、ソースがそこらじゅうに ちらばったりしませんか? その場合、

• cvsリポジトリをデスクトップの計算機に準備
• ノート -> デスクトップにsshとかrshとかできるようにしておく

やりかたは簡単で、

% setenv CVS_RSH ssh		# rsh使うなら不要
% setenv CVSROOT desktop.itojun.org:/usr/home/itojun/practice/cvsroot

たとえば、2台のマシンのカーネルを揃ってバージョンアップして実験したいとき とか、cvs coで最新版カーネルを持って来てコンパイルなんてことが できます。 マシンAで変更した内容をcvs commitしたら、マシンBで cvs update -dとすると、 変更が反映されますのでソースの同期も自由自在です。

「うまくいくんかい」というあなた、FreeBSDとかNetBSDとかがちゃんと 開発できてるのをみれば一目瞭然でしょう。 開発者は全世界に散っていて、ひとつのリポジトリに対して remote cvsしてうまくいってるわけです。 ましてやわれわれの場合、開発者はひとりなのだから、 問題が起きたら自分で反省すればいいだけの話(笑)。 面倒な議論や相談は要りません (もちろん、研究室内とかwide内とかで複数人開発してもいいすけど、 その場合いつバージョンをfreezeするのかい、とかそういう問題が 出るので、別のむずかしい問題に挑戦するハメになるのことね)。

その5: 複数人で開発する!

まずはリポジトリが開発メンバ全員からgroup readable/writableであるか 確認してください。 必要ならchgrpする。

各個人のやる作業はほとんど変わりませんが、commitだけが違います。

複数ひとがいるときは、各個人がてもとに作業用のソースコードツリーを cvs coしていることになります。 また、「ぼくがcheckoutした」時点よりあとに、誰かがcommit作業を してるかもしれません。ので、てもとのツリーは「リポジトリの最新の 状態に対する変更」であるとは限りません。

ので、cvs commitするまえに、以下の手順で てもとの木を、「リポジトリの最新の状態に対する変更」にしてください。

1. commitの作業をはじめるまえに、リポジトリが更新されていないか 調べるため、cvs updateを実行する。 これで「リポジトリの最新状態」と「自分の手もとでやった変更」が マージされます。
   註: 他のひとがファイル/ディレクトリを増やしている場合、 cvs updateだけでは十分に更新されない場合があります。 cvs update -d -r itojun221とかやると、新しく掘られた ディレクトリについてもきちんと更新されます。
2. cvsがうまくマージできなかったところを手で直す。
3. 動作確認をする。
4. もっぺんcvs updateする。 また更新されていたらマージと動作確認をくりかえす。

上記の手順をよめば、ふたりで並行にcommit作業をすると永遠に終らない(笑) ことがわかるでしょう。 ので、cvsだけに頼らないで、mailとか音声で共同作業者に 「いまからcommitするんでよろしく」とか叫びましょう。 叫ぶのと叫ばないのとではだいぶん苦労が違います。 ちゃんと叫べば、「中途半端な状態でcommitしない」制約も緩くなります。

複数人開発の場合、「いつリリースするか」の制御はかなり難しくなります。 わたしもまだ甘ちゃんなのでこれについてはふれません。 厳しくやるなら、リリース用の枝をほらないといけないかも。

cvsの向き不向き

自分でスクラッチから書いていて、バージョンの枝わかれもしそうにない ソースの場合は、rcsの方が楽な場合もあるかもしれない。 まあ、rcsでいいやと思う間はrcsでもいいでしょうね。

rcsとの違いは、こんなもんかな。

• rcsはひとつのファイルをみんなでよってたかっていじくる。 見える作業ファイルはひとつ。 作業できるひとはひとり。
  cvsはcvs coで各自自分の作業用コピーをつくって作業をする。 ので、見える作業ファイルはたくさん、作業できるひともたくさん。
  (このため、rcsは/etc/aliasesとか/etc/yp/srcとかの管理に向いている。 cvsはどうみても向いていない)
• 上記の都合上、rcsではedit前にrcs -lでファイルを ロックしたりする必要がある。 だから、必ず最新版がみえている。バージョンの枝わかれは 可能だけど、とにかくひとつところをみんなでいじる。
  cvsはみんなでコピーをいじるので、必ずしもすんなりcvs commitが 終るとは限らない。隣の席の次郎君がおなじファイルを変更しているかも しれないからである。
• rcsは単一ファイルにバージョンをつける。
  cvsは複数ファイルの集合にまとめてバージョンをつけられる。

もっと高級テクニック

branchとtagの違いについて

あるbranchから枝わかれしてできたバージョンの並びを「branch」、 branch上のあるバージョンについた名札を「tag」という。 ここでややこしいのが、 「あるbranch xの先頭のバージョンには、 "x"という名前のtagがついている」ということ。 例えば、itojun221 branchの先頭のバージョンには、 「itojun221」というtagがついている。

r221 ================== r222 ======>			vendor(FREEBSD) branch
  \			  \
   * -- * -- itojun221	   \				itojun221 branch
			    \
			     * -- itojun222		itojun222 branch

r221 ================== r222 ======>			vendor(FREEBSD) branch
  \			  \
   * -- * -- itojun221	   \				itojun221 branch
			    \
			     * -- * -- itojun222	itojun222 branch

ある時点のツリーにtagをつける

sticky tag

commitがあったらmailing listに通知する

cvsのバージョンによる違い

• cvs 1.9.16およびそれ以前のものは、ディレクトリをcvs addしたときの 挙動が変な気がする。
• cvs 1.9.10以前のものは、ときどきsticky tagを無視することが あるような気がする。

beta releaseはhttp://www.cyclic.com/から たぐってゲットすること。

To be done

• differences between various branching strategies
  この記事の例題以外にも、いろんなbranching strategyがあるので そのへんの違い/選び方/などなど。
• 複数OSのカーネルソースに似たような変更をするときはどうしよう?

役立つページたち

• http://www.cyclic.com/
• CVS, the convenience store