Diary?

(21:48)

我らが西原先生の夢が叶った。十年ほど前の中学生の時に「鳥頭紀行」で脳みそを引き裂かれるような衝撃を受けて以来、西原先生は常に自分の中の漫画家カーストでバラモンのさらに上つまり神であり、そんなどうしようもないファンとしてこれ程嬉しいことはない。

(22:36)

さて今日の仕事内容と明日行われるであろう「どこから直せばクリティカルパスへのダメージが最小になるかを考える会」について思案を巡らせた結果、割と最悪なパターンが思い浮かんだので今さっきからの 10 分の記憶を消したくなってきた。ってか絶対に俺の事を地雷処理専門家だと売り込んだ奴がいるだろ。もしそうでなくて今の状態になっているとしたら、俺の引き勝負の弱さは異常。

まあそれはともかくとして、やはりこのぐらいの規模のプロジェクトになるとセクションごと（フレームワークと業務とか）で複数のブランチが走ってる状態になってしまうわけで、そっから安定版のマージをいかにスムーズに行うかってのは死活問題になるわけだ。だってマージでこけたら大惨事だもん。まず普通に作業止まるし、衝突の起き方によっては手戻りや追加の泥仕事だし。

普段の単純なファイルの追加・修正・削除だけならどんなバージョン管理システムでも大抵は問題なく行え、特に同一ブランチ内での更新の衝突を避けるだけなら単純にファイルをロックするタイプの集中型リポジトリが一番楽なわけだ。ところがそういうのに限って、ブランチのマージで面倒事が起きやすいんだよな。やっぱリポジトリ内部の状態について割と強い前提条件を立てられるせいかな。

そうなるとマージのアルゴリズムを賢くせざるを得ない分散型のメリットと言うのが無視できない気がしなくもないが、こっちはそもそも使ったことのある人の絶対数が少ないという致命的な問題があり、そもそも変更管理と一体になった分散リポジトリなんぞ俺は聞いたことがない。あとやっぱ現状を見るに Eclipse 用の安定したプラグインもないとダメだし。実に困ったもんだ。