すげー面倒くさかった。redmineよりもindeferoよりも。たぶん。
まぁでも一応は使えるようになったので、メモ。

まず、indeferoのときは、お試しでインストールの時にあれこれいじって環境が汚れたので、今回はテスト用に仮想マシンを立てた。（centos5.6の仮想マシンだけど、ディスクIOが遅い？6.0じゃないのは、インストール手順が探せた(http://famousphil.com/blog/2011/06/installing-gitorious-on-centos-5-6-x64/)のと、本番環境にインストールするのを見越して。タダ使うだけなら、ubuntuにするのがいいかと。この辺とか。 http://tech.lexues.co.jp/archives/500 ）

基本は http://famousphil.com/blog/2011/06/installing-gitorious-on-centos-5-6-x64/ に従うだけ。いくつか詰まったところと、このサイトに変なことを書いてあるところがあったので、そこを直して作業を進める。あとは、自分の理解が足りていなかったところもあったのでそこも補足。

もう作業手順は忘れてしまったので、順不同で箇条書きする。
・鍵認証でsshでコマンドを投げるとき、シェルログインしないので.bash_profileは読まれない。サイトの手順どおりに勧めると、環境変数が読まれなくて、gitでpushできなくなるので、.bashrcでPATHを書く。
・gemでいろいろインストールするのはなくてもいいとかなんとか言っているけど、ちゃんと不足分をインストールしないと動かない。
・上記のサイトでも指摘されているが、actyivemqは不要だった様子。でも、これを入れなかったせいで、後述の、commit間のdiffが表示されない問題が出ているような、、、。
・ultrasphinxをrakeできなかった。http://tech.lexues.co.jp/archives/500 に指摘されているとおりに、config/ultrasphinx/production.confのbase_tagsとなっている部分をtagsと書き変えて作業再開。
・rootのcronで@rebootでサービス開始しろと言っているが、それをやると、cronとmysqlの起動順の違いで起動されない場合があったので、/etc/rc.local（だっけ？）で起動させる。

このくらいでgitoriousが立ち上がった。注意が必要だったのは、config/gitorious.ymlのgitorious_client_port: 80 と gitorious_client_host: の設定。gitorious_client_hostには、gitoriousが立ち上がっているサーバの名前を書く。普通は、gitorious_hostと同じでいいはず。何書いていいのか分からなかったから適当に書いてたら、動かなかった。このgitorious_client_hostを見て、http経由でgitリポジトリとやり取りしている部分があるっぽい？

で、大体ほとんど動くけど、マージリクエストで、diffを表示させるところがうまく表示できなかった。activemqを入れなかったのが原因かも。rubyのソースをちょこちょこ直してみたけど全然変化なしで、困った。

で、とりあえず感想として、RubyonRailsのサイトって、入れるのが面倒くさすぎて、なんだかもうやってられない感じ。gitorious自体はgitの中央リポジトリを持って開発するうえで強力なツールだとは思うのだけれども、、、。はてさて。

で、ついでだからgitoriousの作業フローをここにメモっておく。

中央リポジトリがあらかじめgitorious上に作成されていたとする。
中央リポジトリのコミット権限なしで開発をしたいユーザは、gitoriousのサイト上でリポジトリをcloneする。
このとき、gitorious上では、自分がリポジトリをcloneしたという情報が見える。

cloneしたリポジトリを自分の開発端末にpullして開発、適当にcommitして、gitoriousにpush。

で、gitoriousのサイトで、cloneした元のリポジトリに対してmergeリクエストを出す。このマージリクエストは、redmineのチケットみたいになっていて、いろんな人（リポジトリを持っているプロジェクトのメンバーなど）がマージリクエストに対してコメントを書き、それを反映して、開発者は適当に変更、pushしなおして、マージリクエストを更新していく。

で、中央リポジトリに反映させていいというコンセンサスが取れたら、中央リポジトリのコミッターがマージリクエストされた変更を、コミッターのgitリポジトリでマージして中央にpush。このサイクルを繰り返して開発を進める感じ。

各ユーザは、gitoriousが走っているサーバにユーザを持ったりログインする権限を持っている必要はなく、gitoriousのsshの公開鍵を教えておくことでリポジトリとやり取りする。他の開発者の変更を見たりするときに楽できるから、svnで開発するより楽にリポジトリ管理できると思うけど、、、。どうかなぁ。

git の宣伝はこれ http://whygitisbetterthanx.com/　hgでもそんなにブランチ切るのが遅いの？ほんとに？

個人的にはpythonなしでもインストールできるgitとsvnしか選択肢がない。

で、いろいろ調べた最近はやりの分散型ソース管理システムの比較。

まず、svn対git svnの有利な点は、中央リポジトリが一つあってわかりやすいことと、リビジョン番号が連版になっていること。さらに、大きなバイナリファイルが扱えるという点。　https://git.wiki.kernel.org/index.php/GitSvnComparison

hg対git では、hgの方が履歴書き換え形のコマンドが使えない点と、ローカルリポジトリ固有のリビジョン番号がある点。ただ、リポジトリによって違うリビジョン番号は混乱の元なので、ちょっと使いにくいかなぁ。windowsとの親和性でもやっぱりhgという話。hgはoctopus mergeがない？

http://hgbook.red-bean.com/read/how-did-we-get-here.html

bzr対gitでは、bzrはsvn的な中央リポジトリも使えるし、bzr2.0からhg並みのスピードがでるという点でいろいろ便利そう。launchpadがあるし、バックにcanonicalがついてるから、いろいろはかどるんだろうなぁという印象。

http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html

分散型リポジトリ系ではどれもこれも巨大なバイナリファイルが扱えないという点はどれも同じ。

基本的にはgitの方がややこしいけどgitは速い、という反応。githubとかgitoriousがあるので、将来的にはgitかなぁという感がある。まぁ個人的にはgitなんですけどね。どうせwindowsで使おうというわけではないので。

いろいろあってgitを使い始めた今日この頃。
outofmemoryでcloneとかgcとかいろいろはかどらない事態に遭遇したのでメモ。

原因はある程度の大きさのバイナリ定数ファイル。
ulimitでユーザーの対話シェルでのメモリはガッツリ制限されてる環境での作業が行われているのだけれども、この定数ファイルがメモリの制限値を越えているのが原因で、outofmemoryエラーが発生しているものと考えられる。っつうか、ユーザは0.1%もメモリをつかえないって、ちょっとひどいな。ジョブスケジューラにジョブを投げればメモリもたくさん使えるんだけれども、これって、ちょっと使い勝手がよくない。どうしたものか，，，。（そもそも、darcsやmercurialやbazaarでなくてgitなのは、pythonやghcが入っていない環境で、とりあえずユーザー権限でインストールして使うため、というのも半分はある。つまり、そもそもインストールできるのはgitだけだったという話。svnはすでにはいってるんですけどね。）

といっても、これらのファイルはプログラムには不可分なので、できればリポジトリで一括管理したいところ。でも、他のマシンで試して見たところ。全部で10GB越えるようなリポジトリは、ちょっといろいろはかどらない気がする。でかすぎるんだよなぁ。。。個々のファイルはそれほどでもなんだけれども、、、。

https://git.wiki.kernel.org/index.php/GitSvnComparison
このあたりの記事を読むと、バイナリファイルの管理はsvnの方が良さげとか書いてあるし、他の分散型cvsについても、ちょっと検索すれば、すぐに大きなバイナリ定数ファイルはまずいことがわかる。

結局、定数をどうしても管理するなら、svnを使うというのが、スジなんじゃないかと思いつつも、そういうことはさせてくれないような感じだし、そもそも他人に使わせる段になったら問題。割と困ってしまっている。tarで固めて適当に保存するのがいいのかなぁ。。。rsyncとかつかってみたりして。

—-
結局、バイナリファイルは管理しないことにした。
定数ファイルをそうそう変更することもないので、変更時にtar.gzで固めておけばいいやという判断。

—-
ちなみに、pythonがない環境でのgitのインストールは、公式サイトからtarを拾ってきて
gmake configure
configure –prefix=”path” #CFLAGS=64bitオプションとかもお好みで
config.mak.autogenを編集して、最後にNO_PYTHON=YesPleaseを追加。
Makefileかconfig.mak.autogenのどっちだったか忘れたけど、もしgnu installにパスが通っていなかったら、installコマンドでgnu coreutilsから入れたinstallを使うように、install=を書きなおしておく。
（ちなみに、その環境の下ではcoreutilsのコンパイルは簡単だったので省略）
で、あとは普通に
gmake
gmake test
gmake install
でOK
—-
あと、/bin/shがbashじゃないとダメっぽい。stashとか。ひょっとしたら作業環境のshの方が悪いのかもしれないけど。

注意！（2015-07-22）　このやりかただと、変換に失敗したときに、エラーログが大量に吐かれてしまいますので、注意してください。
たとえば、http://mikan.azulite.net/wiki.cgi?page=Git&action=SOURCEのやり方の方がスマートです。

==============================
ちょっと必要に迫られて対応した。

関数to_utf8あたりをいじって、Encode::from_toとか使ってなんとかするのかなぁ、と思っていたが、
結局は、ファイル読み書きするときに文字コードを変換する方針。

参考はこのへん
http://www.rwds.net/kuroita/program/Perl_unicode.html

diff -u gitweb.cgi new_gitweb.cgi

— gitweb.cgi 2010-11-24 01:03:30.697219844 +0900
+++ new_gitweb.cgi 2010-12-28 22:34:51.702462351 +0900
@@ -16,7 +16,10 @@
use Fcntl ‘:mode’;
use File::Find qw();
use File::Basename qw(basename);
binmode STDOUT, ‘:utf8’;
+use open IN => ‘:encoding(euc-jp)’;
+use open OUT => ‘:utf8’;
+use open ‘:std’;

BEGIN {
CGI->compile() if $ENV{‘MOD_PERL’};

—–追記
その後、shiftjis対応を迫られたので、上の通りで、euc-jpをshiftjisに変えたらうまくいった。
（binmode STDOUTは最初コメントしてたけど、その必要はなかったので、上の記事をちょっと修正しました。）