青木日記

■ stat

「超ヤバい修羅場」から「ふつうの修羅場」にレベルダウン！ ひゃっほーう

(19:31)

■ SVKとブランチは混ぜるな危険

さいきん訳あって SVK を派手に使っているのだけども、 SVK (2.0.2 だったかな) はブランチが絡むとバグバグですな。 前に書いた問題の他に、以下の 3 つが発覚した。

1. でかいレポジトリでブランチを消すと激しくマージしたあげくメモリを使い切る
2. でかいレポジトリでブランチを移動すると激しくマージしたあげくメモリを使い切る
3. 「なんかコミットして、そのファイルを含むブランチかタグを作って --lump でマージ」 を 2 回繰り返すとファイルがコミット前のバージョンに戻る

特に最後のバグが危険すぎる。 状態を保存するためにタグを作ってるのに、そのタグが壊れるんでは話にならない。 原因が最後まで追いきれてないんだけど、 どうやら svk:merge プロパティの付けかたがおかしくて、 マージしたリビジョンが追えなくなってるぽい。 incremental merge と lump merge では svk:merge の付きかたが違うので、 マージのしかたを変えるとバグが出たり出なかったりするわけだな。

一方、バグ 1 と 2 はふたつの原因があるような気がしている。 バグ 3 と同じく svk:merge の付けかたと、メモリリーク。 そもそもマージが起きるのがなんか変だし、 起きたら起きたでメモリを使い切るのがなんかおかしい。 しかも、バグ 1 と 2 で使うメモリ量はファイルサイズには関係なく、 ブランチ内のファイル数だけが関係することがわかっている。 このバグは OS 依存かもしれないが、 少なくとも Solaris 8, Solaris 10, Mac OS X (Leopard) では発生する。 Linux は Debian の SVK が version 1 系だったので試してない。

んで、1 と 2 は incremental push + lump pullにすれば防げるのだが、 3 は incremental push + incremental pull でないと防げない。 ということでお手上げである。

結論：SVK のローカルワーキングブランチ内でタグ・ブランチを操作してはいけない。 作るのも消すのも移動するのもいけない。 タグ・ブランチは全部 SVK デポの外で作り、 ブランチ単位でワーキングブランチを作るべき。

正確に言うと、やばいのはタグ・ブランチではなくて copyである。 でもって svn move は copy + remove なので、 でかいディレクトリを move するだけでもバグ 1 が発生する。 したがって、大量のファイル (を含むディレクトリ) のcopy または remove を行う場合は一切 SVK を経由してはならない。

(19:37)

■ Solaris に Subversion と SVK を入れる

SVK + Subversion って、Solaris に入れようと思うと超大変じゃね？ sunfreeware にある Subversion のバイナリは apache2 と一緒に使うと apr のバージョン違いで落ちて使いものにならないし、 自分でコンパイルしようと思うとリンクまわりで死ぬほどひっかかる。 いったんコンパイルが通らないと libtool が障害にしかならなくて実に腹立たしい。 Subversion は無駄にライブラリ使いすぎなんだよ。 dlopen も使いすぎ。嫌がらせとしか思えない。

それから、インターネットにつながってないマシンだと CPAN につながらないので SVK のインストールがめんどくさい。 mini-CPAN 使おうかなあと思ったけど、量が多くてゲンナリする。 けっきょくインターネットにつながってるマシンで一回コンパイルして、 そのときにダウンロードされたキャッシュファイルをコピーしてもってきた。 Ruby も、RubyGem がないとなんにもできねーとかいう 状況にはならないでほしいと真剣に思った。 最後に、sunfreeware にある Perl 5.8 のバイナリは Sun Pro CC でコンパイルされているので Perl XS を gcc でコンパイルしようと思うとはまる。

(19:37)

■ RHG の再利用関係

うーむ、なぜか最近 RHG 再利用の動きが活発になってるなあ。 でも RHG に関しては正直俺に言われてもしょうがなかったりする。 いちおう出版社に聞いてみますが、期待しないで待っててください。

個人的には、RHG 自体を元に何かするよりも、 構成や内容を参考にしながら 完全に書き直しちゃったほうがなにかと楽だと思ってます。 長い文章を書くときの問題は章の構成管理とかであって、 文章自体を書くことはさほど問題ではありません。

それに、1.9 を元にするなら少なくとも 第 3 部 (評価器) は完全に書き直さないといけないし、 第 1 部 (オブジェクト) と第 2 部(パーサ) もかなり変わってるので 元の文章が使える部分は予想外に少ないと思います。

(22:09)