ただのにっき

■ Subversion

やまだあきらさんがximapdのMLにもりもりパッチを投げまくっているので、「こりゃTrunk HEADに追従しないと乗り遅れるかも!」と焦り(←客観的には焦る必要なし)、重い腰を上げることに。ってつまり、Subversionを入れたってことなんだけど(おせー!)。

といっても、こんだけ:

% sudo apt-get install subversion

で、ximapdは職場で使っているので、proxyを通さないと社外のリポジトリは使えない。調べたところ、~/.subversion/serversを書き換えるらしい。設定はこんな感じ?:

[global]
http-proxy-host = proxy.example.com
http-proxy-port = 8080

で、coしてみたら、ダメなのだった:

% svn co http://projects.netlab.jp/svn/ximapd/trunk ximapd
svn: REPORT リクエスト (相手: '/svn/ximapd/!svn/vcc/default') が失敗しました
svn: REPORT (URL: '/svn/ximapd/!svn/vcc/default'): 400 Bad Request
(http://projects.netlab.jp)

Status 400って……。proxyのいらない自宅サーバ上でやると問題ないから、svnの使い方は間違ってないんだよな(たぶん)。これは会社のproxyの設定に問題があるってことか?(→コレかな?) 上流のproxyにイチャモンつけるのは難しいなぁ……。自宅でsvn upして、それをscpかrsyncで取ってくることにするか。

……というわけで、ただいま先っぽに追従中。

■ Subversion(2)

せっかくなので真面目に使うテスト。自宅サーバのCVSリポジトリを変換してみよう。ブランチも切ってないから、素直にコンバートできるだろう。もっとも、CVSでも何も困ってないんだけど。

ツールはcvs2svnを使うらしい。保存形式には悪評高き(?)Berkeley DBじゃなくて、そろそろ安定してきたと言われているfsfsを使うことにする。

% sudo apt-get install cvs2svn
% cvs2svn --fs-type=fsfs -s ~/svn /var/lib/cvs

うんうん考え込んだあと(マシンが遅いので)、コンバート完了。これを、ssh経由で職場のマシンからアクセスする。真面目に(といっても関係のありそうなところだけつまみ食いのように)マニュアルを読んでから:

% cd ~/tmp
% svn co svn+ssh://tsukuba/home/sho/svn/trunk/www/komainu

ずらずらずら〜とcheckoutされてきた。成功だ。スムーズすぎて怖い(←珍しくちゃんとマニュアルを読んだからだと思われ)。

■ Subversion(3)

よそのレポジトリを職場からGETできるようにするには、自宅サーバに本家のコピーを持たせちゃえばいいんだよな。そうすればsvn+sshで取れるわけで。でもcvsの-dオプションみたいに、commit先のレポジトリを無理やり変更することはできないみたい……? svn switchが使えるかと思ったけど、違うようだし。

結局、ximapdについては、

• svn exportした本家の内容を自宅サーバのレポジトリにsvn add、svn ci
• 本家の内容を反映するときは上のディレクトリにsvn export --forceで強制上書きしてからsvn ci

って感じにしてみたが、スマートではないよなぁ。まぁこれだと、少なくとも自分で書いて追加したpluginなんかは問題ない。ファイルの追加や削除があったときには少し困る(が自動化は可能か?)。ローカルパッチがどうなるかは……そのときになってから考えよう(汗)。