いつも思うことだが、バックアップや世代管理を個人の作業に期待するのは愚策である。基本的にはそんなにマメに世代バックアップを用意するなんてばからしくやってられない。しかしだからと言って共同の作業スペース（Windows や Mac のファイル共有をイメージすれば分かりやすい）上のデータをすべて世代管理するなんて、膨大すぎて非現実的である。
「いわゆるコード」の場合、CVS で管理していれば working copy と repository は自動的に分離される。したがって repository そのものが爆発することは、まぁ運用ポリシーにもよるがそんなにないだろう。しかし repository と working copy が同居しやすい場合((例えば Zope や WebDAV 経由の Subversion なんかがそういう状態になりやすいだろう。実際には working copy と repository はイコールにはならないが、手軽なので「確認用の環境を用意しない運用になりやすい」んじゃないかと思う。))、リポジトリの爆発という問題とどうつきあうのかという、けっこう深刻な問題が発生する。
あ、cvs admin みたいにこの revision は必要ないから削除とか、そういう操作ができればいいのか？（もちろんすべてのファイルについてそんなことやっちゃいられないが。） Subversion は次世代のバージョン管理として期待値はでかいが、クライアント環境をあまり選ばない（CVS みたいに面倒なことを気にしなくてよい）分、repository の管理能力を問われそうな感じだな。あ、Zope + Subversion てのも手かな？ 普段 Zope にどかどか突っ込んでいって、ちゃんとしたバージョンの段階で Subversion に突っ込んで publish、ZODB のサイズを見て不定期に pack を行う。あ、これいいかもしんない。
- Zope + CVS
- Subversion + CVS
- Zope + Subversion
- Subversion + Zope
なんかの組み合わせがなくはないのかな？ とりあえず操作性や柔軟さを考えて CVS をフロントには置かないってことで。
優先度は高くなかったはずなのだが、VikiWiki のバージョンを上げた。理由は Farm 機能。Farm 機能の運用実績では Hiki が筆頭だが、Hiki はやはり書式が貧弱なので、PukiWiki 互換の書式を使うことができる VikiWiki で Farm を起こそうと考えた。
AddModules の記述は必要
公式サイトのドキュメントでは
#AddModule mod_ruby.c
が書かれているが、実際にはコメントアウトしてるとソース垂れ流しになってしまう。
実行属性は必要
これは実に残念。でも Forbidden になるのでソース垂れ流しにはならない。
どこかのサイトで見つけたこの記述
AddHandler ruby-script .rbx .rbx
は要らなかった
ファイルの拡張子に応じて SetHanlder する記述が必要
<Files *.rbx>
SetHandler ruby-object
RubyHandler Apache::RubyRun.instance
</Files>
結果
VikiWiki は mod_ruby 化したら確かに速くなったが、permission の関係でエラーがあちこちで出るようになった。setup.rb に頼らず自力でそのままファイルを展開した方がマシだったろうか？ 本家に mod_ruby でも動くと書いてあったからやったのだが、鵜呑みにしすぎか？ 面倒くさくなってきたので今日はこの辺で。
mod_ruby の本当のおいしさはやっぱ embedded ruby、eRuby なんだよな。<% %> なのは ASP も睨んでのことですね。確かに ASP での利用も可能なようです。
開発スピードと完成度と、ドキュメントの分かりにくさを考えると VikiWiki はステた方がいいのか？(^^;
へぇ。んーでもこれ man じゃーないんだな。