OSDir.com

Arch の Tom Lord とのインタビュー: バージョン管理システムについて

Software / OSDir Original Date: Sep 24, 2004 - 09:20 AM

by Steve Mallett


バージョン管理システムはどんなプログラマにとっても切実な必要のあるツールだ。
近年 Subversion において、この分野で多大の進歩がなされているが、
世の中にはさらに異なるバージョン管理システムが存在する。しかも、
こうしたシステムの仕事について、これまでの定義を完全に書き換えるものだ。
Tom Lord は、その Arch Revision Control System の作者である。
OSDir は Tom にインタビューして、Arch にまつわる物語を聞いてみた。
そして Arch が他の (たぶん読者が現在使用している) ものと
どのように異なっているかについても尋ねてきた。


OSDir: Arch を書くことにした動機をお聞かせください。

Tom Lord: まず、働きながら大学に通っていたころ、もうずいぶん昔だけど、
ぼくが尊敬していろいろ学び取ろうとしていた人たちの中に、
「大規模プログラミング」という分野へ関心を持つ人たちがいたんだ。
これは何百人、何千人というプログラマの関わるプロジェクトを
いかに管理するかという問題で、ぼくもこれに興味を持つようになった。
そしてリビジョン管理がその一部だったわけさ。

ほんの数年前、大きな電話会社の (今はもうない) 調査研究所で一時的に
コンサルティングをしていたことがあるんだけど、そこのボスは、
あまり心配しなくて良いように CVS を使ってくれと言ってきたんだ。
でも、そうするわけにはいかなかった。
ぼくにとって CVS っていうのは、ただただ気持ち悪いものなんだ。
ほとんどの場合は単に邪魔だし、役に立つと思える主要部分、つまり
ブランチング、マージング、タギングといったものは、苦痛でしかない
扱いにくい代物だ。どうしようもないシステムさ。で、そのときぼくは
何週間か極秘プロジェクトを立ち上げて、ボスを安心させるもっと良いものを
発明しようとした。まあ少なくとも何らかのリビジョン管理を使うように
しようとは思っていた。さて、その小さなプロジェクトは失敗した。
それも、ひどい失敗だった。今にして思うと、そのときはブランチングや
マージングの重要性が分かってなかったんだろうな。ソースツリーの
スナップショットを取るだけのものを作ろうとしたんだ。それはできたよ。
でも制限的なシステムにしてもあまりに動作が遅すぎたし、あまりに大量の
ディスクスペースを使ってしまうものだった。ディスクを使いすぎる点で
悪名高いぼくの観点からしても、使いものにならないほどだ。

Subversion プロジェクトを知ったのはそのころだった。特に二つの理由で
興味深いと思ったね。第一に、スマートなマージング機能を売りにしていたこと。
第二に、ストレージ管理部分をトランザクション型ファイルシステムにしたこと。
ぼくはトランザクション型ファイルシステムの考え方にとても共感を持っているから、
Subversion はすごいプロジェクトだと思った。あとで Subversion の設計と実装は
ひどい欠陥製品だと考えるようになったけど、そのときにはまだぜんぜん
問題じゃなかったんだ。Subversion の生涯ではかなり初期の段階だったから、
実際に使ってみることもできなかったしね。


OSDir: 批評も理由の一つでしょうが、実際のコーディングに取り組むようになった
いきさつはどのようなものでしたか。

Tom Lord: 何年かして、いきなり解雇された。ドットコム・バブルがはじけたあと
だったから技術職を探すのはとても難しかった。やけになって、なんでもいいから
さっさとぼくのうわべだけのキャリアを引き揚げてくれるフリーソフトウェア
プロジェクトを見付けて、履歴書に「ほら、ぼくのできることが分かったかい?」と
言えるようなことを書きたいと思って、もがいていたんだ。たぶん、ぼくの
運が良ければ、直接お金になるようなプロジェクトを作ることもできたんだろうね。

そうやって探しているうちに、また Subversion に気付いて、リビジョン管理
システムの話題を全体的に見直すようになった。前よりもずっと、この問題に
ついて考えるようになったよ。ストレージ管理の必要条件であるとか、
ディスクを使いすぎないようにすることとか、ブランチングとマージングのために
必要な事柄や、はたまたツリー全体の不可分コミットについて、などなど。

Subversion な人たちに対する当然の敬意として言うけど、彼らの多くは
こっちから見てずいぶんすごいハッカーたちだ。でもぼくは、彼らが
完全に失敗したことに気付いた。Subversion は駄作だ。ひどい。とても良い
アイディアを基に、ひどい設計をしてしまった。ふつうの観察者の目からは、
たぶん Subversion の問題点を認識するのは難しいと思う。なんたって、
アイディアは良いのだし、開発者のスキルも高い。プロジェクト管理も素晴しく
うまくやっている。しかしながら、その問題点を知ってしまったぼくは、
Subversion プロジェクトに入れてもらおうという気にはなれなかった。

分かってる。これはちょっと煽ってるのとはわけが違うんだ。だから少し
詳しく説明させてほしい。今では大勢の人が Subversion を使って、かなり
満足している。これはぼくもよく知っている。でもぼくの観点では CVS から
進歩したとは言えないんだ。Subversion はいろんな分野であまりにも
後退してしまっている。同時に、そうした後退にもかかわらず、いくつか
CVS がうまくやっていなかったことを正しく行なっているのは確かだ。
だからもし、そうした点だけに注意を払っているのであれば、Subversion は
CVS より進歩していると言える。

でも、ぼくは一生懸命 Subversion アーカイブを保守したいとは思わない。
管理者の荷が重すぎるよ。CVS より悪くなってるように見えるし、
Subversion そのものをハックしたいともぜんぜん思わない。だって
コードが長すぎるし複雑すぎる。彼らがずっと前から約束している
スマート・マージング機能はものすごく欲しいけれども、それはまだ
できていないし。

だから簡単に言って、Arch を書くようぼくを駆り立てたものは、
単純で時代遅れで利己的な競争意識だったのさ。
彼らの鼻をあかしてやりたかったんだね。


OSDir: CVS について、修正すべき点は何でしたか。

Tom Lord: CVS はがらくただ。もうこれに同意しない人はいないはずだよ。
タギングなどの動作は、苦痛とも言えるほど遅い。ブランチングやマージングの
インタフェイスは貧弱で、まったくとは言わないけど、ほとんど使えない。
ファイル名の変更の扱い方は見苦しいし、ネットワークプロトコルもだめだめ。
リモートサーバはペラペラで弱っちょろい。そう、ローカルの動作もペラペラだ。
不可分コミットがないのも問題だ。CVS のアーカイブフォーマットは
設計からしておかしいし、堅牢じゃない。あと、「NFS 越しのゼロブロック」
問題を聞いたことがあるかい?

CVS には強みもある。非常に安定したコードだ。これは、もうだれも CVS を
いじりたいとは思っていないのが大きい。また、量的な強みもある。
CVS の設置と子守りについては多くの管理者が知っているし、使い方については
多くのハッカーが知っている。CVS の抱える重大な問題に関しても、
たとえば不可分コミットがないことや、腐ったブランチングとマージングも、
十分に訓練されたチームならやり過ごすことができる。GCC プロジェクトが
CVS を上手に使っている最良の見本だね。

それで、CVS は失敗作だけど、上から空が落ちてきたとかいうほどのことではない。
もっとうまくやれるはずだというだけのこと。そして、大空が落ちてきていない
ということは、フリーソフトウェア・コミュニティにおける CVS の広まりは
ぼくたちの飛べる高さを制限しているということになる。

分かりやすい例として、CVS が非分散システムであり、コミッタを
その他すべてと分けて考えるという点がある。コミッタだけがブランチを作れる。
コミッタだけが、ブランチをメインラインと同期させるために CVS から
最良の援助を受けられる。CVS はフリーソフトウェアの世界に、なくても良い
一種の階級差別を作り出すんだ。非コミッタは二級市民というわけ。もちろん、
実際のメンテナだけがメインラインに変更をコミットできるようにするのは
合理的だ。その区別さえないのであれば、メンテナの存在意義がなくなってしまう。
でも、リビジョン管理の他の利点までも非コミッタから奪ってしまうのは不合理だ。

別の例としてネットワーク・プロトコルを挙げよう。CVS サーバは高速 LAN を
通して会話するぶんには無害だけど、ここではインターネット越しに通信してみよう。
特にずっと遠くから、そしてサーバが忙しくしているところへ話しかけてみる。
こういうとき、リビジョン管理システムで何をするにも中央サーバと
連絡をとらなくてはならないというのは完全に時代錯誤であり、
現代社会においてはただ単純に間違っている、ということに気付くはずだよ。

もう一つ、あまり分かりやすい例ではないけど、CVS がファイル名変更や
ブランチング、タギングを厄介で薄っぺらいものにしているという点がある。
この制限のせいで、メンテナは最善の仕事をすることができないようになっている。
メンテナは複雑なソースツリーの再構築をしぶる。そうすればファイルや
ディレクトリの名前を変えることになるからさ。それで、屑コード (原語: cruft)
はいつまでもプロジェクトから掃除されないまま、ある程度残ることになる。
また、メンテナはブランチに作業することをしぶる。CVS ではそうした作業が
苦行になるので、なんでもメインラインにやってしまうんだ。そして
メインラインは「バグフィクス用フリーズ」局面まで、信頼性のない期間に
突入する。

究極的に言って、ほとんどのユーザが行き着いたのは CVS を
最もお馬鹿な方法でだけ使うということのようだね。複数のプログラマが
単独のツリーでみんな一緒にハックすることができるようにするハブとして
使うのさ。CVS でそれ以上のことはしないんだ。そう、それは悪いことじゃない。
でも、それはバージョン管理という命題の 10 パーセントに過ぎない。
みんなが CVS をそうやって使っているということは、このツールの欠点が
プログラマのプロジェクト組織運営に制限を課しているということを暗示している。


OSDir: それでは Subversion についてはどうです? 何が足りないのですか。

Tom Lord: Subversion は CVS 問題をいくらか修正したよ。不可分コミットがある
(これはもちろん Arch にもある)。CVS そっくりの CLI もある。
リビジョンとブランチに対して、CVS より良い名前スキームを持っている。
Arch も優れた名前空間を持っている。Arch のは少しばかり初心者を当惑させる
ものであることが実証されているけど、経験を積んだユーザは少なくともこれを
非常に良いものだと考えている。また Subversion は素晴しく魅力的なアイディアに
基づいている。トランザクション型ファイルシステム、つまり、ファイルや
ツリー全体のコピーでさえも非常に安上がりな動作となる仕組みだ。

Subversion は同時に、ぼくの意見では、CVS より悪いところがある。
その実装はあまりに混み入っている。BDB を主要なバックエンドとして使うことで
管理者の苦労が増えている。データベースのログファイルやバックアップを
管理したり、障害のたびにサーバ側でリカバリプロセス (あるいはもっと
大変な手順) を実行しなくてはならなかったりする。メインラインだけ
管理すれば良いのなら素晴しいのだけれども、ブランチングすると、
貧弱なマージング機能がいたずらし始める。Subversion はかなり重量級の
サーバを要求するし、今ある分散動作サポートは言わば後付けによるものだ。

それに、Subversion の問題点は、ぼくの意見ではけっこう根の深いものだよ。
マージング問題の解決は非常に難しい。だって「ブランチングは単に
ツリーのコピーである」というパラダイム全体を再考しなくてはならないんだから。
BDB 依存は原理的には解決できるけれども、Subversion はおそらく
Arch のアーカイブ・ストレージ管理システムにおける美しいまでの単純さに
近付くことはないだろうと思う。そしておそらく Subversion はいつまでも
サーバサイド・コンピュテーションに依存するだろう。これは世界規模から見て
どんな規模にも柔軟に対応できる開発環境のためには、まったく不適切な選択だ。

こうして、Arch を書くよう突き動かしたものに話が戻って来た。
ぼくはツリー全体の diff と patch を取る方法を発見したことで、
リビジョン管理にメチャクチャ簡単な解法があることに気付いたんだ。
これには、Subversion にある問題点が一つもない。
ぼくは Arch が既にはっきり CVS より優れていると信じているし、
Subversion と SVK より良いものであるとも信じている。
そして、これからさらに納得のいく形で良くなっていくと思っている。


OSDir: では、開発者は Arch に移行すべきなのでしょうか。

Tom Lord: Linux カーネルプロジェクトを見てよ。少なくとも、Bit Keeper (BK) の
ライセンスにハメられる (訳注: drink one's koolaid で、甘いものにだまされて
中毒になって破滅させられるという意味らしい) のが気にならない開発者たちを
見てほしい。BK ユーザのカーネル開発者たちは、Arch との共通点がたくさんある
システムを使っているんだ。分散開発の高度なサポート、チェンジセット指向、
苦労いらずのブランチングおよびマージング。Arch 同様に BK も、コミッタだけが
リビジョン管理の恩恵を受けて非コミッタは受けないという階級差別を
撤廃する。この機能をコミュニティは喜んで受け入れた。狂喜乱舞した。
多くの開発者は、BK がカーネル開発をいかに改善したかを、公言してはばからない。
明らかに、こうしたツールにはプロジェクトをより良くする力があるというわけさ。

今の例はあまり科学的じゃないな。でも、すさまじく暗示的だろ。ぼくにはこれが、
ソフトウェアプロジェクトの管理に使うツール、特にリビジョン管理ツールの
質と能力が、プロジェクトそのものの品質に大きな影響を与えるということを
暗示しているように思えるな。ちょうど今、フリーソフトウェアは
どんどん多くの分野でノンフリーに負けないようになってきている。
このリードを持続させ広げていきたいんだったら、どのようにプロジェクトを
運営していくかということや、そのためにどんなツールを使うかということを
考えるのが重要な焦点の一つになるだろう。ぼくたちフリーソフトウェア開発
コミュニティは、少なくとも商業界のライバルたちと同じ程度に頭が良いことを
実証してきたし、数の点で勝っている。ぼくたちは素晴しいソフトウェアを
作りたいという衝動に動かされ、しばしば成功を収めている。
もしぼくたちが貧弱なツールでプロジェクトを管理したり協力方法を実装したり
したために事態を紛糾させてしまうとしたら、これは恥ずかしいことだ。


OSDir: 将来のリリースでは何が出てくるのでしょうか。

Tom Lord: 既に Arch は、大きなツリーや大規模プロジェクトをとても良い具合に
扱えるようになっているのだけれども、ちょっとひっかかる問題もあるんだ。
その問題とは、ローカル環境を「ほんのちょっぴり」注意して調整しないと
こうした益を受けられない、ということだ。

すなおにパッケージのまま、特別な段階を踏まずに Arch を使って、
とても大きな、あるいはとても忙しいプロジェクトの作業をしようとした場合、
パフォーマンスの面で、でこぼこの悪路走行を強いられることになる。
まあ、ある意味それでも大丈夫だろうよ。すべてのユーザが問題を抱えるわけでは
ないし、問題を抱えるようになる人たちもどうすれば良いかすぐに分かるし。
それでもぼくは、パッケージのままでも Arch がもう少しうまく動くように
できると考えている。

ぼくたちは、単に調整方法を単純にするだけではなく、完全に調整された Arch
さえも高速化するようなワザを用意してある。だから、理想的な状況では今でも
十分に速いけれども、今年の年末ごろに理想環境ではものすごく速くなる計画だ。

また、現時点で Arch コマンドセットには CVS コマンドセットとの目立った
違いがある。たとえば、非常に特殊な例外を除いて、Arch はツリーに対する
変更をすべて一度にコミットするよう奨励している。CVS のように変更の
一部だけをコミットすることはできないんだ。

今より CVS 風に作業できるような限定的な仕組みはできているけど、
ぼくたちは最近、それをまたいくらか一般化する方法に気付いたんだ。
うまくいけば今年が終わりを迎えるよりもだいぶ前に、Arch は Subversion と
同じ程度には CVS と似た感じになるだろうと思う。
少なくとも、この重ね合わせ機能に関してはそのようになるだろう。

Arch の GUI もいくつか開発が始まっている。こっちでも、その中のどれかが
十分に成熟してくれるよう望んでいる。それはおそらく Arch と一緒に
配布されることになるだろう。その素敵な副作用として、Arch を既存の IDE と
統合する道が明らかになると思う。



Steve Mallett is the founder and managing editor of OSDir.com, the
care taker for opensource.org, general software wonk, and a dreadful
programmer. You can read about his life in one light meaty snake at
http://steve.osdir.com.


---- This article comes from OSDir.com http://osdir.com/

The URL for this story is:
http://osdir.com/modules.php?op=modload&name=News&file=article&sid=1687