いやいや、遠慮するこたないと思いますよ。 何を言われてもぼくが不要と思えば実装しませんし、 自分で必要だと思ったから To Do に入れたわけです。 要望はストレートに言ってくれたほうが助かります。
イントラネットで動かす場合を考えると Windows 2000 あたりは重要なターゲットですし、 インストールが簡単になるにこしたことはないと思います。 最終的な目的は「共同作業をすること」であって 「BitChannel を使う」ではないのですから、 プラットフォームの違いとかバックエンドの違いなんてのは本質的とは言えません。 本質的でない部分はできる限り気にしないで済むのが適切です。
その前提を踏まえたうえで特に Subversion 対応を考える理由としては、 まずマーケティング的な効果が挙げられます。 どう考えたって「CVS 対応！」よりは 「Subversion 対応！」のほうがインパクトがあるに決まってる。 なにしろ流行りものだし。
第二に、サーバ構築の手間が挙げられます。 現在は基本的にローカルレポジトリを念頭に置いて開発してますが、 別にリモートでまずいってことは全然ありません。 特にこれからは CVS で直接手を出せるようにしたいと思っているので、 そうなればリモートレポジトリも重要になるでしょう。 が、しかし、CVS サーバの構築って死ぬほど面倒なんですね。 その点 Subversion はサーバを作るのが簡単なので、 対応しておくにこしたことはないと思います。
ただしここで一言言っておきたいのですが、 ぼくは Subversion を信用していません。 だから Subversion に対応しても自分では使いませんし、お勧めもしません。
(18:35)
『Rubyレシピブック』 2800 円で 5 月 28 日配本だそうです。 配本つーことは、本屋にはもうちょい後にならぶ？ あ、31 日出版となってるな。
とにかくそのあたりです！
(19:27)
Subversion を信用できない理由はただ一つで、 Berkeley DB を使ってるからです。 別に RCS じゃなくてもいいんだけど、 テキストベースのデータベースでありさえすれば何も文句はありません。 なぜテキストがいいかと言えば、 いざとなったら ls と cat と vi で管理できるからです。 バイナリデータベースは vi で直接いじれません。
もちろん反論があるのは知ってますが、 これまで見た限りでは説得力を感じませんでした。例えば "Dispelling Subversion FUD" では「普通データためるなら RDB (= バイナリデータベース) 使うだろ、 なぜ Subversion には文句を言うのか」と言ってますが、 ことバージョン管理システムに関しては文句を言われるべきだと思います。
なぜならば、バージョン管理システムの本質とは即ち安心担保システムだからです。 昔のコードは全部残ってるからどんどん変更してください、 プログラムもデータベースフォーマット (RCS) も枯れてて安定してます、 それでも万一の場合はエディタで直接編集できます、 という保証があるからこそ安心してソースコードをいじれるんです。 いつ古いコードに戻れなくなるかわからないという不安があったら XP なんかできません。
ここで重要なのは心理的な効果であって、 本当に vi 編集が必要になるか、それで復旧できるかどうかは問題ではありません。 「もしそうなっても安心だ」と思える (信じられる) ことが肝心なのです。 その点、ぼくは vi で編集できればどうにかなると信じられます。 しかし vi が使えないんでは直す自信はありません。 従って Subversion は信じられません。 さらに言えば、そういう心理的な安心感を考慮してくれない Subversion 開発チームも信用できません。
(22:43)
まあ CVS に比べりゃ不安定だと思いますが、 (一般的なアプリケーションに比べて) 特に不安定ってことはないんじゃないですか。 いや、使ってないから知りませんけど。
しかしぼくが文句を言いたいのはあくまで データベースの設計それ自体であって、 プログラムの安定度じゃないということは追記しておきたいと思います。 また、新しい機能がほしいわけでもありません。 さらに言うならば、CVS サーバは文句なしに最低です。
(22:51)
あとさー、Subversion の新機能って 実はたいして嬉しくなくない？
Windows でもチェックアウトできんの？
別に PNG が画像的に diff できるってわけじゃないんでしょ？
ふーん。
これは重要な進歩だな。
必要な人は必要なんだろうけどねえ。
あるにこしたことはないよね。
この点は文句なしに素晴しい。つーか CVS がダメすぎ。
ということで総合すると、おれにとって文句なしに長所で、 どうしても欲しいと思える特徴は「サーバ構築が容易」ってところだけだ。 あとはどうでもいいか、CVS でも妥協できるレベルだな。
(23:03)
今週土曜日は RHG 読書会です。 案内は
あたりを参照してください。
ちなみに今回は p.267 (10 章「パーサ」の途中) からで、 たぶん「状態付きスキャナ」に入るでしょう。 きついんだここが。
(03:44)
Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved.
Subversion を信頼してないというのは、やはりまだ枯れてないということでしょうか。
それとも、他に理由があったりするのでしょうか？
新機能がそんなに魅力的でないというのはあくまで「よりよい CVS」ですから仕方がないですね。
心理的安心感に関しては、コミットごとに dump すればそれなりに得られます。dump してしまえば、フォーマットは単純ですし、手で編集も出来ます。
コミットごとにdumpしてCVSに…
MSWin版ではfork未対応で停止しますね(当然か
http://ruby-talk.com/blade/60221
入れてごにょごにょしたら動きました。
なるほど、win32-popen なんてのがあるんですね。
ありがとうございます。こちらでも動作を検証してみます。
両方の嫌なところだけ合成されるに 20 ルピー > dumpしてCVS管理
個人的にはテキストベースの方がエンコード云々で全く信用ならないんですが・・・
>テキストベースのデータベースでありさえすれば何も文句はありません。
こう言ってるのだから，データベースは１世代で構わないわけでしょう．ということは，「コミットごとに dump」とは別問題ですね．じゃあ，berkdb でも dump して vi で編集して undump すればいいのでは？たまにしか起こらないデータ破壊の対策として毎回効率の悪いテキストベースのデータベースを使うなんて．
逆に言えば、速度しか利点がないじゃないですか。
俺は速度よりも安心感が欲しいんです。
dump して vi で編集して undump では駄目なんですか？
「安全性」ではなく「安心感」ってところがミソなんですかね．安全性を追求するならもっと他のやり方がありそうな気がするので．
>バージョン管理システムの本質とは即ち安心担保システムだからです。
これも個人的には納得できません．安心感を得ることが本質なら，もはや差分管理はやらないと思います．ハードディスクも巨大化していますし．差分管理しなければ diff も DB も不要になります．
実際は diff や branch など，情報整理の利便性が追求されていると思います．
> dump して vi で編集して undump では駄目なんですか？
データベースが壊れていたら dump が動くとは限りません。
> >バージョン管理システムの本質とは即ち安心担保システムだからです。
>
> これも個人的には納得できません．安心感を得ることが本質なら，
> もはや差分管理はやらないと思います．ハードディスクも巨大化
> していますし．差分管理しなければ diff も DB も不要になります．
> 実際は diff や branch など，情報整理の利便性が追求されていると思います．
べつに差分じゃなくてもいいんじゃないですか。
「それなりに手軽に使えて、すぐ元に戻せるシステム」
のうちで今のとこベストなのが CVS だから使ってるだけで、
その実装がすべて理想にかなっているなんて言ってません。
> 「それなりに手軽に使えて、すぐ元に戻せるシステム」
> のうちで今のとこベストなのが CVS だから使ってるだけで、
> その実装がすべて理想にかなっているなんて言ってません。
なるほど．