Diary?

(22:55)

今は仕事でも趣味でも分散 SCM を使っているのだけど、結局今は git と Mercurial の一騎打ちになってんのかな。どっちも最新の情報を追えているわけではないけど、マージングアルゴリズムとか今はどうなってんだろ。これは余裕があったら調べたい所だけど、しばらくはそんな時間は作れそうもないんだよな。

これまでの経験からして、 SCM はマージングアルゴリズムが賢かったり変更履歴の柔軟な管理ができないと（特にチーム開発では）使い物にならなくて、それもかなり無茶苦茶なケースに対して対応できないといけない。割とトホホなケースを出すけど、こんな感じの事故を俺は目にしたことがある。

1. 同じ起源を持つブランチ A とブランチ B が作成される。マージの方向は A→B で固定
2. ブランチ A 由来のリソースがブランチ B で削除される
3. ブランチ B に先に削除されたリソースと同名のリソースが登録される
4. ブランチ A への変更がブランチ B にマージできなくなり、地獄開始

この時に問題になってるのは二番目から三番目にかけての手続きで、この部分の変更履歴をなかったことにできる機能があれば問題は即座に解決できたはずだが、実際にはそういった機能のない SCM だったのでこの問題の解決には相当な工数がかかっていた。というか、そういった機能のある SCM って特に集中型の SCM ではないと思う。流石にここまでのケースは滅多にないだろうけど、マージが SCM を運用管理する上での重大なテーマであることは間違いない。

あと先にマージの方向が A→B で固定と書いたけど、これはリポジトリがフレームワーク・共通ライブラリ系と業務系の二系統で管理されていたからで、これがもっと細かくリポジトリを分けるポリシーだとマージは双方向に発生するし、その頻度も高くなる。つまり、マージに関する事故（コンフリクトとか）が発生しやすくなる。

なのでマージを可能な限り行わないとか（というか手動マージ）、リポジトリは一個しか作らないとかいうポリシーで運用されたりするんだけど、これはいろいろとマズい。特にマズいのは作業途中の状態でコミットしにくくなる事で、例えばどうしてもビルドやテストに影響のある状態でしかコミットできない場合、それをコミットしたら他のメンバーがリポジトリから最新のコードをチェックアウトしたときに悲劇が起こる。

このマージの問題に付いては分散 SCM の方が間違いなく上手く扱えると思っていて、中央のメインリポジトリでのコンフリクトや、コンフリクトが頻発するような状況をどうやって切り抜けるかのノウハウさえあるなら、もういい加減 CVS とか Subversion から脱却してしまってもいいんじゃないかと思う。

まあ SCM については変更管理との兼ね合いもあるので、SCM の方だけ見ていてもダメだったりするんだが。