2006-04-10

CNET Japan の幅が広がってうっとうしくなったな

つーか Feed でチェックだけしといた記事の本文が飛んでなくなってるし…。トラックバックは見えるけど本文が見えないっていういやんな状態になってる。

つか障害の原因てまだ調査中なんだ。そら大変だ。とりあえずこっちはこの使いにくいデザインへの対策を考えよう。ってことで。

今さら Trac の感想

※ もうこの「今さら〜」というタイトルの付け方がマンネリだなぁ。

さて、頭の回転の速い Subversion 使いのみなさんにはもうすっかりお馴染みの Trac だが、わたしゃどうも道具を使いこなすまでが遅くてなかなかついていけない。しかしえっちらおっちら試してきた過程で思いついたことは一応書き留めてある。これから Trac を試してみようとか、ちょっと試したけどなんか思ったように動かんかった、という人に少しは役に立つかもしれないのでこのメモの抜粋を公開しようと思う。嘘、不足はツッコミよろ。

なお、以下のメモは FreeBSD 上で Trac 0.9.3 を動かしたときのものである。

まず Trac って何?

Subversion リポジトリブラウザ & Wiki & BTS(Bug Tracking System) の統合ツール。trac ロゴには Integrated SCM & Project Management って書いてあるように、Web ベースのプロジェクト管理ツール、という位置づけでそんなに外れてないと思う。(進捗管理とかできないけど)

Trac を動かすには何が必要?

  • Webサーバ1
  • Python
  • SQL系のDBMS(SQLite でも動くのでそんなに難しくない)
  • Subversion

CGI, FastCGI, mod_python で動く。らしいけど、自分で確認したのは CGI と FastCGI のみ。

Windows でも Linux でも MacOSX でも動かせそう。個人的には FreeBSD でしか試してないけど、Windows なら All-In-One-Trac というものもあるので、必要なものが少なくない割には導入は楽になってきているんじゃないかと思う。

どういう人が使うと嬉しい?

Subversion を使って何らかのデータの管理を行っている人。cvs の場合は cvstrac という C で書かれたツールがあるようだが、試してないのでどんなもんかは知らない。

何ができない?

qwikWeb みたいにメールで Wiki の更新とかできないはず。ただし BTS(Ticket) の変更をメールで通知する機能はある。ViewCVS と違って特定のディレクトリ以下の tarball を download する機能はない。

インストール記事は書きません

頑張ってくれ。

セットアップするときの注意点

必ず svn リポジトリが一つは create されてること。

[2006-09-14 追記]svn リポジトリを cvs2svn で作成した場合、どうもデフォルトでは svn:eol-style=native という属性が付加されるっぽい。こうすると例えば Windows と Linux が混在している環境では「リポジトリ上では同じだが、手元でいじっているファイルの改行コードは違う」という現象が起きる。で、この working copy のファイルを利用して何かをしようとすると改行コードの違いが思わぬ副作用をもたらす可能性があるので注意。

deploy ツールを用意しろってことかなぁ。

重いので fastcgi か mod_python がオススメ

最初 CGI で動かしたんだけど、自宅サーバではびっくりするほど重かったので、fastcgi か mod_python がオススメ。マシンパワーが余っているか、気の長い人なら CGI でも大丈夫だと思う。

あと、Apache 2 用の fastcgi のセットアップのドキュメントで

<IfModule mod_fastcgi.c>
  FastCgiIpcDir /var/run/fastcgi
  FastCgiConfig -initial-env TRAC_ENV /var/lib/trac/HOGE
</IfModule>

みたいに書いてある場合もあるんだけど、fastcgi で TRAC_ENV を設定する場合は = で結んでおかないといけないので、上のままでは動かない。

<IfModule mod_fastcgi.c>
  FastCgiIpcDir /var/run/fastcgi
  FastCgiConfig -initial-env TRAC_ENV=/var/lib/trac/HOGE
</IfModule>

にする。(個人的には fastcgi の設定は lighttpd の方が楽だと思う。)

mod_python は自分では試してねっす。fastcgi は落ちたときに自動的に再起動してくれるとか便利な機能があるので楽ちんだと思うんだな。

マルチバイト文字(含む日本語)の問題

基本的には UTF-8 で扱うので日本語についても問題なく使える。UTF-8 に対応しているブラウザで編集すれば Wiki についてはなんら問題ない。trac-ja が提供されているが、これは基本的に UI やマニュアルの日本語訳であって、日本語の処理に問題があるためではない。2

問題は Subversion で管理するテキストファイルのエンコーディングが UTF-8 じゃない場合。これの解決方法は二つある。3

  1. プロジェクト全体のエンコーディングを trac.ini の default_charset に指定する
  2. 個々のファイルについて svn の機能でエンコーディングを指定する
svn propset svn:mime-type "text/plain;charset=ENCODING" filename

基本的には 1 の方法だけで問題ないはず。というのもこういうツールを使う人はもともとプロの開発者とかその手の人が大半なので、ある単位のファイル群のエンコーディングがバラついていることはまずあり得ないから。

ただしこれが個人的なファイルをとにかく突っ込んでいる場合や Web サイトのファイルを管理したいという場合はこの限りではないと思う。特に Web の場合、サーバサイドスクリプトでは内部エンコーディングとブラウザとの入出力に使うエンコーディングが違う、それに伴って CSS やクライアントサイドスクリプトのエンコーディングが違う、ということはよくある。

この場合は地味に svn propset & svn commit していくしかない。サブディレクトリが見つかると4そこで svn propset は「止まる」ので、あまりたくさんのファイルに対して設定するのはしんどい。もうその場合はプロジェクトを分けちゃうのが正解だと思う。5あるいはコード中にはもうマルチバイト文字は書かない。そう思った理由は以下のリンクに関する記述を参照されたし。

あ、そうそうまだ試してない(まだ試し始めてから ascii の comment しか書いていない)けど commit log も UTF-8 で書かないといけないと思う。

[2006-08-02 追記]subversion 1.1 以降で gettext がリンクされていて locale がちゃんと設定されていれば、svn コマンドは locale を解釈したうえで UTF-8 に変換して commit する模様。どこかで拾った OSX 用 SVN バイナリは locale を解釈しなかったので Fink 版に変えた。

ツールを横断するリンクが便利

Wiki と BTS とリポジトリが一つのツールで扱えてとても便利だなと思うのは、それぞれを簡単にリンクさせられる点。Wiki からソースブラウザ、commit log から BTS へ簡単にリンクが張れる。これはかなり便利に使える。

ということは添付ファイルやめて svn で管理しちゃえばいいじゃん

最近の Wiki では添付ファイルの機能はそれほど珍しくない。Trac でもページに対してファイルを添付して、それをページから参照することができる。ただしこの添付ファイルはほんとにただ添付できるだけ。svn も Trac も履歴管理がバッチリできるのに添付ファイルは蚊帳の外なのであまり嬉しくないのだ。

そこで上のリンク機能。添付したいファイルを svn リポジトリに突っ込んで、Wiki からそこにリンクしてしまえばよい。画像の場合はこれに Image マクロを組み合わせるとそのままページ内に表示できる。具体的にはこんな感じ

[[Image(source:foo/bar.png)]]

で Wiki に書けばよい。なんて便利。これで Wiki のテキストも画像も全部履歴管理できるという塩梅だ。

svn リポジトリに dav アクセスできれば全部 HTTP で済むし、ファイルを編集してブラウザから添付し直して…なんて面倒な操作をしなくて済むのがすごく嬉しい。

認証は単なる BASIC 認証

インストール直後、Web サーバの認証を設定していない状態で login のリンクを辿るとエラーが出る。なんじゃこれと思ったが、

svn の dav アクセス用のユーザーDB をそのまま利用すればいいじゃん

という方針らしい。なんとスバラシイ発想。ま、逆に言えば dav アクセスを許可するつもりがなかった場合はあんまり嬉しくないんだけど。

認証を経ないと使えない機能があるのかどうかはよく知らない6。まだそこまで使い込んでないんで。編集時のユーザー名はその場で記入できるので、普通に Wiki を編集するためには認証は必要ない。ただ login していると Wiki の編集時に自分の名前を記憶しておいてくれるので、その辺は楽。BASIC 認証の設定を済ませたら、せっかくだから dav アクセスも許可しちゃおうかとか思ってきちゃうから不思議だ。(lighttpd を使っている場合は違うか。)

いろんな RSS が取れて便利

CVS で管理しているプロジェクトでコミットの様子を RSS で吐かせようと思うと一工夫いる。しかし Trac では本当に様々な情報について RSS が提供されている。特定のファイルの更新を監視するなど、楽勝でできてしまう。これはいい。

今のところのまとめ

現在は ViewCVS + PukiWiki で似たようなことをやってはいるが、Subversion の CVS に対するアドバンテージ、ツールが統合されていることによる利便性がとても気持ちよい環境である。

一方 Wiki 単体ではプラグインの豊富さや日記形式の記入が楽に行えるなど、PukiWiki のアドバンテージももちろんあるので、全面移行というのはまだちょっと難しいように思う。逆に今までそういう環境を構築していない場合はとりあえず使っとけと言って間違いないと思う。多少セットアップが面倒でもお釣りはくるはず。

あ。ViewCVS と違って tarball のダウンロードできないなぁ。まぁ要らないか。要らない要らない。要らないってことにする。

  1. 個人的には Apache2 と lighttpd で確認 

  2. 一部バグがあるという情報もあるが、これまで利用してきた範囲では特に困ったことは起きていない。あーでも日本語のファイル名とかは知らない。 

  3. もう一つ、default_charset でも svn propset でもなく、Trac を hack して文字コードの自動判別の機能を付加するという方法を採っている人もいるが、ここでは考えない。 

  4. 「”管理対象外”のリソースが見つかった場合」かもしれない。 

  5. ディレクトリの階層さえどうにかなればリポジトリが分かれていなくても Trac 上のプロジェクトは分離できる。 

  6. 添付ファイルの削除や Wiki ページの削除はデフォルトでは anonymous ユーザーでは行えない。この辺は TracPermissions というページに解説があり、設定は trac-admin で行うので目を通しておくとよい。 

About

例によって個人のなんちゃらです