リーナス・トーバルズ「Subversion ほど無意味なプロジェクトはない」
Tech Talk: Linus Torvalds on git
My hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan for Subversion for a while was "CVS done right" or something like that. And if you start with that kind of slogan, there is nowhere you can go. There is no way to do CVS right.あと、CVS が好きな人は精神病院に行ったほうがいいそうで。tar ボールとパッチのほうがはるかに優れたソースコード管理方法なんだと。
ぼくの CVS への憎悪が意味するのは、ぼくが Subversion のことを史上最大の無意味なプロジェクトだと見ているということだ。Subversion がしばらくの間スローガンにしていたのに、「ちゃんとした CVS」みたいなのがあったよね。そんなスローガンでスタートしたら、もうどこにも行くところがない。CVS をちゃんとすることなんて不可能だからだ。
ソースコード管理（SCM）が使えるための条件は、
- 分散型であること
- パフォーマンスがいいこと
- SCM に突っ込んだコードが完全に同じ形で取り出せることが約束されていること
「パフォーマンス」っていうのは、マージの時のパフォーマンスのことのようで。↓は Subversion チームがブランチ作成が高速にできることを宣伝していたのを指しての発言：
Even if it takes a millionth of a second for branching, WHO CARES? It's the wrong thing you're measuring. Nobody's interested in branching. Branches are completely useless unless you merge them. And CVS cannot merge anything at all. You can merge things once, but because CVS then forgets what you did, you can never ever merge anything again, without getting horrible, horrible conflicts. Merging in Subversion is a complete disaster. The Subversion people kind of acknowledge this, and they have a plan, and their plan sucks too. It's incredible how stupid these people are. They've been looking at wrong problems all the time. Branching is not the issue. Merging is.ほぉ、そうなんだ。
仮りにブランチ作成が 1/1000000 秒でできたとして、そんなことを誰が気にする？ 奴らはまちがった計測をしてるんだ。ブランチ作成にかかる時間なんてどうでもいい。マージをしなければたくさんのブランチはまったく無意味な存在だ。CVS は何もマージできない。一度はできても、CVS は何をしたかを忘れるから、ひどい競合を起こさずにもう一度マージすることは不可能だ。Subversion のマージもひどいもんだ。Subversion の中の人たちもそのことをちょっとは認めてるようで、新しいプランがあるようだけど、このプランがまたひどい。彼らのアホさ加減はもう信じがたいほどだ。ずっとまちがった問題を見てるんだ。ブランチが問題なんじゃない。マージが問題なんだ。
13 comments:
はてなブックマーク：
http://b.hatena.ne.jp/entry/http://...
言及記事：
http://d.hatena.ne.jp/higepon/...
Kuwata さんからも言及もらった：
http://return0.dyndns.org/log/...
なるほど、git のマージのアルゴリズムは（少なくともリンク先の記事が書かれる時点では）そんなに最適なものでもないだろう、ということか。
ちょっと補足すると、リーナスはアルゴリズム（とそこから出る問題）についてはこのトークではほとんどしゃべってなくて、もっぱら分散型の利点とか速度とかファイルじゃなくてコンテンツを追跡することとか統計表示機能なんかについて話してた。詳しくないから分からないけど、（もっといいアルゴリズムを使ってるかもしれない） darcs がトークで一度もあがってないのも速度のパフォーマンスによるものかも。知らないということはないし。
あと、これは別の話で、記事には書いてないけど C++ で書かれた Monotone についての言及はあった（ちなみに、Linus は C++ に言いたいこともあるようで）。「使おうと思って、１日使ったけど、パフォーマンスが so horrendously bad だったからやめた」とのこと。
うお、./J の記事になってる（←いまさら）。
Linus曰く「Subversionは史上最も無意味なプロジェクト」
参考になりそうな意見：
http://enbug.tdiary.net/20071216.html#p01
>>> 最近の動向はあんまり見てないので間違っているかもしれないが、移植性無視、merging algorithmのイケてないgitは論外 <<<
下のブログエントリにまとめがあった：
Linus Torvalds explains distributed source control
http://kylecordes.com/2007/05/17/linux-git-distributed/
↑同じ人による分散型入門の記事も：
A Brief Introduction to Distributed Version Control
http://kylecordes.com/2007/10/11/intro-dvcs/
Bram Cohen も Great Programmer という記事で Subversion をバカにしている：
========================
It's a great example of a project permanently crippled by dumb architectural decisions.
（アホなアーキテクチャの決定によって永久に欠陥品であることが約束されたプロジェクトのよい例だ。）
========================
git と mercurial 両方（とその他の分散システムをたくさん）使った人の git/mercurial 比較記事：
- The Differences Between Mercurial and Git (rockstarprogrammer.org)
Darcs retrospective, and the future (http://hackage.haskell.org/trac/ghc/wiki/DarcsEvaluation)
GHC developers plan to migrate from darcs (reddit.com)
Haskellコンパイラチームが darcs とのトラブルが重なってほかのDVCS（おそらくgitかhg）に移行するもよう。
GHC が git に移行することに決めたもよう。
===========================
It came down to two things: the degree of support available, and
flexibility of the tools (git is much happier to let you modify the history
than Mercurial). Speed ruled out bzr, and Windows support is less of an
issue: git appears to work reasonably well on Windows these days.
===========================
サポート、ツールの柔軟性、スピード、さいきんでは Windows でもわりとまともに動くことなんかが決め手になったようで。
Why git is better than hg bzr svn perforce
http://whygitisbetterthanx.com/ (via reddit)
上の「Linus は C++ に言いたいこともあるようで」のリンクが死んでいる。
新しいリンク先はこちら：
Linus Torvald's rant against C++
あと reddit.com での議論も。
tabesugi.net より上の Linus のメールの翻訳：
============================
From: xxx
To: xxx
Subject: Re: [RFC] builin-mailinfo.c をマシな文字列ライブラリを使うようにすること
Date: Thu, 6 Sep 2007 18:50:28 +0100 (BST)
Message-ID: alpine.LFD.0.999.0709061839510.5626@evo.linux-foundation.org
On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
>
> Git のソースコードを最初に見たとき、ヘンだと思ったこと:
> 1. C++ じゃなくてただの C を使ってる。理由は謎。移植性がどうとか言わないで、
> そんなのウソに決まってるから。
*あんた* のほうこそ大ウソつきだ。
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
つまりこういうことだ: C を選ぶのは、唯一のまともな選択だ。以前 Miles Bader が
冗談で「人をムカつかせるため」といっていたが、実はこれは本当だ。
ぼくは C よりも C++ をプロジェクトに使いたがるようなプログラマーは、みな
*本当に* ムカつかせておきたいようなプログラマーだという結論に達した。
そうすれば連中がやってきてぼくの関わっているプロジェクトを
めちゃくちゃにすることがないからね。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。
というわけなので、申し訳ないね。git のような、効率が一番の目的のような場合は
C++ の「利点」とやらは単に大間違いなんだよ。ついでにこの事実を理解できない
連中をケトばすことができるってのも、大きなメリットだな。
もし C++ で書かれた VCS が欲しいのなら、Monotone を見てみるといい。
ほんとに。連中は「本物のデータベース」を使っているよ。
「素敵なオブジェクト指向ライブラリ」も使ってる。「ナイスな C++ の抽象化」も
使ってる。そして率直なことろ、一部の情報系の人間が喜びそうな
これらすべての設計上の決定のために、できてきた結果はゲロゲロで
保守不可能なカオスだ。
でもあんたはきっと git よりも気に入るだろう。保証するよ。
Linus
============================
Post a Comment