山本です。 >GUI版としてはTortoiseSVN[*2]というものがありますが、私は使っ >たことがないので論評は差し控えます。 私は個人的用途に TortoiseSVN を使っているので、WinCVS と 両方使っていることになりますが、ruby の開発に TortoiseSVN を使うようになっても問題ないかといわれると自信がありません。 私の用途は、ごく小規模な開発に限られていて、一番 Revision が多くなっているリポジトリでもまだ数十のレベルです。ruby ともなると数千にはなるでしょうから、パフォーマンスが どのくらい変わるかが一番気になります。 というわけで、CVS からの移行の前に、お試しで Subversion の リポジトリも用意してもらえれば、議論もしやすいのではないか と思います。 # CVS はファイル単位の管理なので、cvs log や cvs diff は # あくまでそのファイルの履歴に対する処理になり、ChangeLog # や eval.c でもなければそれなりに素早いのですが、 # SVN は リビジョン単位の管理なので、全てのファイルが # リポジトリ全体のリビジョン数の影響を受けて遅くなって # しまうのではと気になってます。 # http://developers.slashdot.org/comments.pl?sid=148329&cid=12437730 # という話がある一方で、http://websvn.kde.org/ なんていう巨大リポジトリ # もあったりして、よくわからないのですが。。。 私の思いつくメリット・デメリットは 1. subversion のブランチは copy on write なので軽い。 ファイル・ディレクトリの移動も追跡できる。（こちらはリポジトリ構造の 安定している ruby ではご利益がないかも） 2. subversion は各ファイルごとに HEAD をローカルコピーとして 持つので、HEAD に対する diff は非常に速い。（updateも？）その代わり、 ローカルコピーにおけるファイル数が二倍になる。 3. WinCVS のグラフ機能は秀逸。TortoiseSVN にも一応グラフ機能があるが、 役に立たない。 4. TortoiseSVN はいまいち安定してないような気もする。一度か二度だが、なぜか コミットログが化けたことがあったし（日本語で書いているせいかも） 1.14 以降に上げたときにやたらクラッシュしたので、依然 1.13 を使っている。 最近のはわからないが、 http://svn.collab.net/repos/tortoisesvn/trunk/src/Changelog.txt を見ると、いまいち不安。 5. subversion はコミットが atomic なので、同時に複数のファイルが変更されても 変更を追いやすい。cvs だと、ChangeLog を頼りにそれぞれのファイルのログを 調べて、コミットログの同じリビジョンをつき合わせたり、時刻で checkout して あたりをつけたりすることになる。また、やったことはないけど、HEAD から ruby_1_8 へのバックポートなんかも、マージを使えばやりやすくなるかもしれない。 そういえば最近、特定リビジョンの変更だけを revert するのに、クリック一発で revert できたのは便利だった。 6. subversion は BerkleyDB がバックエンドだった頃は、すごく不安定でリポジトリが 壊れやすかったらしい。FSFS は安定しているそうなので問題なし？ 7. WinCVS だと、ファイル内容に変更がなくても、タイムスタンプが変わってしまうと 「変更あり」の扱いになってしまう。そのため、削除して checkout しなおす必要が ある。TortoiseSVN ではファイル内容を比較しているのか、そんなことはない。 最後に、私が TortoiseSVN を導入したときに参考にしたサイトをつけておきます。 http://tortoisesvn.bluegate.org/Help/dailyuseguide.html http://ukai.jp/Articles/2003/uu-svn/ http://arch.bluegate.org/pipermail/subversion-jp/2004-May/000087.html http://asshole.dip.jp/subversion.php http://terai.xrea.jp/Subversion.html