YamaKenZの日記: 分散SCM: 履歴管理システムとパッチ管理システム 7
/etc等の管理は仕事もプライベートもいまだにCVSでやっているんだけど、自宅環境・仕事環境共に刷新の時期を迎えたのでこのへんを参考に分散SCMを後継として検討してみた。SubversionもBerkeley DB依存が無くなったのでシステム管理に使えるようになったけど、どうせならもっと便利にしたいので。
私的な結論としては、フリーな分散SCMではMercurial一択。ただし、これには「履歴管理システムとして使うなら」という条件が付く。実際にいじってみて分かった事だけど、「分散SCM」という言葉で乱暴に括られているソフトウェアは、履歴管理システムとパッチ管理システムという2つの異なる性格のシステムに分かれている。どちらの性格が大元になっているかによって内部アルゴリズムからUIのデザインにまで影響が及ぶが、決定的な違いはリビジョン番号があるかどうか。
リビジョン番号というのはある変更に対する「人間が」識別・記憶可能な短かいIDであり、これがサポートされない場合は、ツールの助けを借りて数十桁のハッシュ値を比較したり、「2007-01-09のヤマケンの変更(どれ?)」といった不正確極まる参照で我慢するしかない。これは共同作業者との議論や開発記録文書において特定の変更に言及するコストを著しく押し上げるので、自然とそれらの活動は萎縮してゆくと思われる。結果として、そのようなシステムにおける他人との共同作業では、モジュール単位での分担・委譲とモジュール内でのワンマン開発、日付単位の大雑把な変更記録といった特定の利用スタイルに収束してゆく力が大きく働く事になる。従って、この文で「パッチ管理システム」として分類されているものを採用する場合は、この点を十分に検討する必要がある。
会社組織による開発やuim、SigSchemeのように、細粒度commitの共同開発スタイルや仕様変更の詳細な記録等が必要な場合には、リビジョン番号をサポートした「履歴管理システム」の方を選んでおかないと、ヘタをするとプロジェクトの危機に陥りかねない。さらに、会社組織の場合にはSubversionのような中央集権型のシステムの方が管理コスト上のメリットが大きい場合もあると思われる。
今のところuimをMercurialに移行しようとかは全然考えてないんで、その辺は期待しないで下さい。しばらく個人的に使ってみます。
おまけ: 独断と偏見による分散SCM評価 (Mercurial贔屓)
- 履歴管理システム組
- Mercurial
概念モデルとUIがよく整理されている、パッチ管理システムとしての機能がMercurial Queuesとして分離されていて理解しやすい、基本的に速いが、Psycoサポートの無い非力なマシン(PDA, NAS等)ではちょっと遅い、symlink未サポート - Bazaar
概念モデルがシンプルでない、UIや説明文が蛇足・虚飾気味、Mercurialより遅い
- Mercurial
- パッチ管理システム組
- git
リビジョン番号が無い、renamingのサポートが擬似的、不便な「余計なお世話」UI - darcs
猛烈に遅くなる、リビジョン番号が無い、大粒度変更の開発スタイルを前提としたキッチンシンクUI
- git
- 候補脱落組
誤解がある場合はお知らせいただけると嬉しいです。
カナ (スコア:0)
http://members.jcom.home.ne.jp/tanitsu/2006-09-08.html#2006-09-08-1
Re:カナ (スコア:1)
Try-Code追従 (スコア:0)
Re:Try-Code追従 (スコア:0)
2007-02-26版の変更が2007-03-25版でキャンセルされました。前回のパッチはスルー、バージョン表記部分だけ更新です。
Re:Try-Code追従 (スコア:0)
日付け間違えました。
Re:Try-Code追従 (スコア:0)
Re:Try-Code追従 (スコア:1)