Tom Lord の "svn の診断" に対する反論
by Greg Hudson, 2004-01-28
-----------------------------------------
2003年2月に、Tom Lord は arch-users メーリングリストに "svn の診断"
と題したメールを書きましたが、その中で彼はなぜ Subversion が--
彼が対象としていた読者から見たとき-- 失敗しているかを説明しようと
しました。その頃のメーリングリストアーカイブは現在入手不能なので、
コピーを以下に置いておきます。
http://web.mit.edu/ghudson/thoughts/diagnosing
Subversion だけになじんでいるような読者の一部にとって、それはチーム
ワークを乱し、彼らが自分自身で判断する前にSubversion が失敗作だと
確信させてしまうかも知れません。しかしその文書に含まれているものの
大部分は不正確であるか、Subversionは間違った方向に進んでいるという結論
を得たいがため、議論する余地のある原則と結びついています。
私がおかしいと思うのは以下の点です:
1. Meta-CVS と DCVS は svn よりもうまく CVS を拡張している。
2. SVN 開発者は大きなハンマーを持ち、そのハンマーで叩くための
釘を探している。(訳者: つまり、問題を解くためにある技術を開発する
のではなく、ある技術を開発しておいてから、その技術がうまく適用できる
問題を探しているのは本末転倒でしょ、と言っている)
3. SVN はバージョン管理についての未熟な概念を持っている
4. SVN は実装の問題点を隠すためにAPIを間違った形で利用している。
5. SVN 開発者は譲歩することができない。
6. SVN は間違った Apache と DAV の階層構造の上に作られている。
私が同意している点を一つつけ加えておきます:
7. SVN はバックエンドに Berkeley DB を使うべきではなかった。
1. Meta-CVS と DCVS
"'svn は CVS を目立つほど改良することには失敗していて、その程度
のことであれば meta-CVS や dcvs が同様のことをもっといい方法で
やることができる、といったことが最近言われています。(非常に
もっともだと思います)"
Meta-CVS は低レイアに CVS を使ったディレクトリ構造のバージョン化を
実装しており、それは CVS が RCS を下位レイアに使っていたように(
そしてある意味今もそうですが)使っています。DCVS は CVS サーバの実装
しなおしです。実践的な見地からいうと、両方とも意味のあるほどのユーザ
あるいは開発者のコミュニティーを持っていないように見えるので、この
批判を理論的な見地から評価してみましょう。
Meta-CVS のレイア戦略は初期開発のコストを低減しますが、インストールされて
いる基本部との意味のある互換性確保には成功していません(それはひどいもの
だというのが共通の認識です)、さらにそれはツリー全体のバージョン化を
達成しておらず、あるいは不分割なコミットに失敗しています。さらに
レイア戦略はほとんど常に CVS エラーメッセージが Meta-CVS コマンドに対して
応答するようなところで、非常にわかりにくいエラーケースを発生させてしまいます。
CVS クライアントを利用することによって DCVS はCVSの基本的なイントール
部分との互換性を保っていますが、CVSネットワークプロトコル(
それもまた非常にひどいものだというのが共通の認識ですが)と、クライアント
の操作モデルの両方によって首が回らなくなっています。後者のクライアント
操作モデルとは、すべてのバージョンはファイルパス名によっておこなわれ
ディレクトリやツリーのバージョンといったものを含まないようなものです。
それで、不分割なコミットや他の CVS の改良点があるにせよ、ディレクトリ構造
のバージョン化には成功していません。
Subversion は CVS を目立った形で改良しているでしょうか? それは
あなたが CVS のどの部分が嫌かによります。もしディレクトリ構造のバージョン
化の欠如、ディレクトリツリー全体のどこに変更があったかを知ることができない、
あるいは混乱した効率の悪いブランチ機能のサポート、またあるいは実装上の
さまざまな問題、であるなら、Subversion はわくわくするような新鮮なものですが、
もし分散開発や履歴依存のマージのサポートの欠如を言っているのであれば
現時点での Subversion は退屈でたいした違いのないものでしょう。いずれにせよ
Meta-CVS と DCVS は同じ目標に向かう、より良い道であるとはいえません。
2. 巨大なハンマー
Tom は Subversion 開発者は、二つの巨大なハンマーを持って、それを
使うための釘を探しているといいます: それはトランザクションファイル
システムと連想検索テーブルです。
"というわけで、ここに最初の間違いがあります:トランザクション FS
のアイディアはぴかぴかの真新しいハンマーのようなものです。あなたに
それを使って釘を探させようとすることになるのは当然の話しでしょう"
この批判の問題は、トランザクション FS はいくつかの説明がいるにせよ
Subversion によって考えられるバージョン管理のためにはまさに最適の
ハンマーであるということです("つまりツリーのスナップショットをとる
というアイディア")。これはバージョン管理における間違った概念であると
熱狂的に信じることもできますが、その一方、それはとても有用で
直感的な概念でもあります。詳細は次の節を見てください。
"設計の自由な討論における属性リストのような考え方の適用はどれも
非常に簡単に以下ような感触を人に与えます: '私たちが考えてきた
すべての問題点はこの設計によって非常に自然に解決できる'と。
しかしここで本当に言われていることは、'私たちが
解決しなくてはならない問題はすべて連想検索の方法で表現することが
できる' ということにすぎません。(訳者: つまり、そんなことは当たり
前でしょ、という意味)
Subversion の初期デザインに関する限り、この批判にはいくらかの真実が
あります。が、結果としての Subversion の実装は非常に制限された形での
属性リストしか含んでおらず、この点で Subversion がバージョン管理システム
として正しい方向に進んでいるかどうかを問題にするのは限られます。
Tom の一般的な主張である、Subversion は"あいまいなデザイン上のコンセプト
をもっている" というのは以下の二点が一緒になったものだと考えられます:
(1) 彼の頭の中にある Arch の開発がどうであるか(それはまだほとんど完成
していません)ということと、Subversion の開発中に一般に向けて書き下された
もので彼が読み取ったもの、との間の公平でない比較、(2) 野心的なマージ
機能のサポートは前衛的なバージョン管理システムの基本的で中心的な
ものであること、です。Subversion のデザインは(ほとんどのソフトウェアの
設計がそうであるように)、数学的な厳密さで書き下されたものではありませんし、
Subversion は履歴依存型マージ機能を今後の課題としておくことを初期の段階
で決定したので、彼はデザインの手続きすべてが"あいまいである"と結論ずけた
のです。
3. あまり練られていないバージョン管理の概念
"以前 Walter が言ったのと同じ印象を持っているとしましょう。つまり
私の言い方で言えば: 'バージョン管理システムの最初のそして最も基本的な
問題は作業ディレクトリのスナップショットをとることだ'。
もしこれが魅力的な(しかし間違っているのだが)印象であるというのを
信じないのなら、戻って、どのように私が返事したかを見てください。
それはたくさんの静かで抽象的なパラグラフを含んでいます。リビジョン管理
システムが実際に関係している問題(アーカイブ、アクセス、チェンジセットの
あつかい)は、非常に微妙で、非直感的なものです。"
これは、集中的な、あるいツリー指向のバージョン管理システム
(Perforce, Clearcase, CVS, Subversion)とチェンジセット指向の
もの(BitKeeper, Arch)とを分ける、微妙で重要な点です。この問題についての
完全な記述は膨大なものとなりますが、二面性のある問題であるということを
理解するべきです:
* チェンジセット指向のバージョン管理システムはより強力ですが、
それは、非常に混沌とした形態をとる開発プロジェクト以外のほとんどすべての
プロジェクトでは不要なものです。
* チェンジセット指向のバージョン管理システムは理解するのが困難
です。多くの環境では、バージョン管理システムにとっては学習曲線が緩い
ことが最も重要です。
* チェンジセット指向のバージョン管理システムは正しく理解するのが
困難です。多分これを最もよく支持するのは Larry McVoy がリナックス
カーネルメーリングリストに書いた以下の 2003年 3月のものでしょう:
http://www.ussg.iu.edu/hypermail/linux/kernel/0303.1/0130.html
* チェンジセット指向のバージョン管理システムは、上に述べたような欠点が
あるにせよ、ツリー指向のシステムの上位レイアに構築することができます。
Tom が自分で書いたように、ツリー指向のデータ保持はチェンジセット指向の
保持と相補的な関係にあります。svk (http://svk.elixus.org/)はSubversion
の上位レイアにチェンジセット指向のバージョン管理システムのプロトタイプ
を提供しています。
4. API の利用
"どうやって実装したらよいかの確信が持てない場合、共通するパターンは
実装を API の下にかくしてしまうように決定することです。この方法により
実装をいつでも後で好きに変更できるんです。おわかりですか?"
"第六のまちがい: いたるところで API を定義することが成功につながると
という仮定"
この批判は特に私を困惑させます。というのは私の考えでは Subversion の API
の利用はほとんどの場合 Subversion の機能をサードパーティーのアプリケーション
からアクセスできるようにするためのもので実装の欠陥を上塗りするためのものは
ほとんどないからです。Subversion が API の複数の実装を実現しているいくつかの
ケースでは--エディタ、レポータ、リポジトリアクセス、ファイルシステム API --
少なくともファイルシステムAPI を除けば少なくともふたつのまったく違った実装があります。
5. 譲歩すること
"もしこのチームが六ヶ月間どこかに行ってしまい、その後いまあるような
SVN を持って帰ってきたとしたら、次のように言うのは簡単だったと
思います。'それはすばらしく、役に立つプロトタイプだ。それは確かに
少なくとも概要的にはトランザクション FS を使ったリビジョン管理
システムの証明になっています。実装には明らかにいくつか悪い点があり、
他の同様のプロジェクトが乗り越えようとしているリビジョン管理システム
の問題点を重要ないくつかの点において無視しているのも明らかです。
そしてそれをやるためたのえらくたくさんのコードがあります。
ちょっと開発をしばらく中断して、どうやるのが正しい方法かを見る
ために設計のほうに努力を注ごうじゃないですか"
これは 2002年から 2003年の初頭にかけて Subversion メーリングリスト上で
交わされましたが、Tom はそのように言っていました。
彼のコメントはいろいろな理由でひとの説得に失敗しましたが、ほとんど
二点に集約されます: どれも非常に抽象的であったこと(特に、多くは
arch を詳しく知っていることが前提となっていることが多かったのですが、
その時点で arch はまだそれほど有名ではありませんでした)、また
多くの人たちに共有されてはいない優先順位、たとえば野心的な履歴依存の
マージの重要性についての信念のようなものをアピールしたということです。
Arch についても同様の"失敗のすべくしてした失敗"という議論をすること
できたでしょう -- それは Unix に特化したものでしたし、急な学習曲線は
基本的な克服できないような障害であると主張することによって。
現在のユーザと開発者のコミュニティーの規模からいって、どちらの議論も
成立してはいません。両方のプロジェクトはそれぞれの欠陥にもかかわらず
ある程度人々に受け入れられることに成功してきました。
しかし、より一般的に言って、ソフトウェアプロジェクトが"すべくしてした
失敗" となる傾向は "バカな社会経済的な状況"の結果である必要はありません。
そうではなく、単にどのようなソフトウェアプロジェクトも完全ではなく、
欠点にもかかわらず安定性と重要をうながすことを推進できたものだけが
成功できるということを受け入れればよいだけです。この話題については
ふたつのエッセイがあります:
http://www.joelonsoftware.com/articles/fog0000000069.html
http://www.neilgunton.com/rewrites_harmful/
6. 時流に乗った W3C への便乗
"SVN は HTTP や Apache が仕様であり新しい分散 OS の最良の実装であり
それによってすべてがきれいに解決すると思われているような時勢のもとに
現れました。非合理名 exhuberance にもとづいてすべてを W3C に基づいて
作った巨大な堆積物のようなものです。それはそのような OS ではないし、
すべてをきれいにとくこともできないのです"。
ある真実が含まれていますが、非常に誇張されています。"すべてが WC3で
ある" dog-pile などありません; Subversion は 基本的な XML をさまざまな
場所で利用し Apache の httpd の実装と HTTP, WebDAV そして DeltaV 標準を
三つのリポジトリアクセス方法の一つで利用しています。これらの部品の
利用は困難なしに存在しませんが、それに見合う利益がないわけでもありません。
WebDAV 互換性はデスクトップユーザにSubversino リポジトリを共有ファイル
のようにマウントさせ、"自動バージョン化"の仕組みにより透過的に修正する
ことさえできます。Apache と Neon の利用は認証と認可の制限されてはいるが
役に立つ方法によって比較的簡単にアクセスすることを可能にします。
いずれにしても、作業コピーライブラリ中での XML の利用を例外として、
svnserve を利用することによってこれらすべてを簡単に回避することができます。
svnserve は、HTTP アクセス方法よりも早くて単純な方法です。
7. 同意する点: Berkeley DB
"簡単に、そして手っ取り早く話しが進むように、彼らは Berkeley DB
ライブラリに注目しました。結局: それは私たちが手軽に使うツール
-- 連想配列を使うために飾りつきのトランザクションを提供しているものです。"
"ええと、私はこのアプリケーションのために Berkeley DB はひどい選択だと
思います。それは管理者の悩みのたねになるでしょう。というのは
単純な連想配列用に最適化されていて階層的なファイルシステム用では
ないからです。差分圧縮のためのもともとの仕組みをもっていません--
自分で作る必要があります。結局欲しいのはトランザクションとロック
だけで、あとのすべての機能は仕方なく一緒についてくるものです。"
これらの言い分は完全に正しくはありません: トランザクションとロックに
加え、Berkeley DB もまた比較的低いオーバーヘッドでたくさんの連想テーブル
を持つための便利な方法を提供しています。以前に書いたようにSubversion
開発者は連想テーブルに対して特別の思い入れがあるわけでは
ないので、さようならと言わんばかりのコメントは思いやりのないものだと
思います。
しかし大枠で、論点は妥当なものです: Subversion のバックエンドが
BerkeleyDB に結びついている限り信頼性の問題に悩まされるでしょう。
ロックを消費し尽くしてしまうでしょう。異常終了の操作でデータベース
には復旧処置が必要になるでしょう。複数の unix アカウントからのデータベース
へのアクセスは適切な umaask が必要であり、そうしなければデータベースは
壊れてしまったように見えるでしょう。データベースはリモートファイルシステム
上ではうまく動かないでしょう。データベースをあるプラットフォームから
別のものに移すと、意味不明のエラーがおこるでしょう。
幸運にもsubversion のほかの部分を変更することなしに Subversion の
バックエンドのみを置き換えることは可能であるはずで、それにはサーバ
側のリポジトリロジックすら影響を受けません。
8. 結論
Tom のメールが対象とした読者は Arch ユーザであり、彼らは一般的に言って
Tom の優先順位を受け入れ、Arch が Subversion よりも興味深いと考える
だろう人々です。そのような意味では、彼の"診断"の多くは意味があり、
少なくともその集団にとっては不正確ではありません。しかし、普通の読者は
Subversion が何かある種のとんでもない間違いをしていると結論づけるべき
ではありません; それはCVSを書き換えようとするさまざまなフリーソフトウェア
グループの中でも、もっとも大きな開発集団とユーザコミュニティーを
持っており、そのユーザにとってはSubversionはほぼ肯定的なものです。
# arch-tag: 774813f0-c0e9-4d02-9b72-1109f3b7cc6e_:-)