私は Subversion の開発者で、非常に初期からこのプロジェクトにかかわっているものです。 この文章は私自身が書いた私的なものです。批判的になる気持はまったく ありません; Subversion についての単に個人的な意見と感じ方にすぎません。 公式なドキュメントではありませんが、Subversionについての悪い噂がある 場所にはどこでもこのドキュメントをリンクしてくれればと思います。 この意図はネット上で私がいろいろと耳にした共通の噂や間違った理解 のいくつかについて疑いを晴らすためのものです。
はじめる前に、興味を持っているシステム管理者に対してひとこと。 もしSubversionを理解し、あなたのグループあるいは企業でこれを利用する ことを考えているのであれば、ふつうそうするように、新製品にたいして接 するようにしてください。つまり、注意深く接してください。Subversion を信用するなと言っているわけではありません・・・しかし常識的に考える べきではない、と言っているのでもありません。テストなしに重要な目的に 利用するのは避けて欲しいと言っているのです。誰も新しい製品を強制され たくはありませんしあなたがシステムに対して責任を持とうとするのであれ ば、広く利用してもらう前に自分でよく馴染んでおく必要があるでしょう。 小さなプロジェクトを見つけてSubversionを、まずは「テスト的に」使って みましょう。最終的に Subversion を気に入れば、その開発者たち(テストに 参加してくれた開発者たち)を幸せにできますし、より大きなシステムに対して も利用する用意ができることになるでしょう。
さて、私がよく耳にする FUD のいくつかを以下に挙げます。
Apache の話を先にします: Subversion は Apache を必要とは しません。Apache Portable Runtime (APR) ライブラリを必要とはしますが、それは Apache ウェブサーバとは別のものです。 APR は Subversion クライアントとサーバが、Apache にできることのすべて を可能にするもので、これは Netscape Portable Runtime (NSPR)が Mozilla についてそうであるのと同じ関係にあります。
Subversion は二つの異なるサーバがあります: 独自の WebDAV モジュール つきの Apache2 を使うこともできますし、CVSの pserver と良く似た スタンドアロンの小さな 'svnserve' を走らせることもできます。どちらが "公式のもの" ということはありませんし、それぞれ利点、欠点があります。 Subversion Book の 6 章のはじめ、 comparison of featuresを見てください。 (訳)
次に、"コンパイルの難しさ" について触れます: 最後に CVS をコンパイルした のはいつですか? え、そんな経験はない? ということは、それはシステムに 最初からインストールしてあったわけですね? ちがいますか? もしあなたが 良くサポートされたオペレーティングシステムを利用しているなら Subversion のバイナリはあなたのディストリビューションに標準パッケージとして含まれて いる(rpms, debs, fink, など)か、あるいは簡単に ダウンロード できるはずです(win32 の場合)。
コンパイルは開発者の話であってユーザの話ではありません。Mozilla, Evolution, KDE, そして Gnome だって同じようにひどい外部依存性がある ではありませんか。しかしほとんどのユーザはこれを気にしていませんが それは自分たちでコンパイルする必要がないからです。結局、Subversionは たくさんの複雑な機能をもっていて、それをもう一度いちから作りたくなかった から、さまざまな外部依存性があるわけです。Subversion だけが特別だという ことはありません。
まず、Subversion プロジェクトはつねに以下のような"基本的な公理"が あります:
CVS は非常にすぐれた、そしてバージョン管理にふさわしいことが証明 されたモデルである; 単にうまく実装されていないだけだ。
つまらないものを洗練しているのではなく、ダイヤモンドの原石を磨いて いるのです。Subversion は CVS モデルをつかい、それにディレクトリ バージョン機能、不分割コミット、データベースバックグラウンド、 バージョン化されたメタデータ、効率的なバイナリファイル処理、柔軟な ネットワーク機能、そして、厳密な C の API などの機能を付け加えて きました。それは CVS が最初からやるべきであったことです。
もし、プロジェクトのこの基本的な公理に反対であるなら、もうあまり 話すことはありません; Subversion はあなた向きではありません。 かわりに"分散型" バージョン管理システムを試すと良いでしょう。 たとえば svk, monotone, or arch. 分散システムは最近大流行で、このようなシステムはSubversionとは別の 方法を利用していますが、私はいずれもすばらしい考え方であることを 疑っていません。
しかし、ここに自分で考えるにあたって、いくつかの資料があります:
単に "CVS の上にちょっとした機能を乗せただけ" といってプロジェクトを 侮辱するのはやめてください。それらの機能は単に CVS の上に"乗せた" だけではありません。CVS のコードベースはひどいことになっていて、 単に拡張することは不可能でした。これが、私たちが完全に新しい設計で いちから開発を始めた理由です。Subversion と CVS はまったくコードを 共有していません; 共通点は、同時実行可能な、集中モデルを採用している ことと、似たようなユーザインターフェースをもっていることだけです。
私たちはジャーナル化されたライブラリを実装することから始めましたが、 これは作業コピーとバージョン化されたディレクトリを管理するものです。 それからトランザクションデータベース上にリポジトリを実装しました。 これは完全なツリーのある一時点でのスナップショットを格納するための ものです。Subversion が自分自身によってバージョン管理される以前に、 このことだけで 14ヶ月のコーディングが必要でした。その後、安定化、 バグ修正、機能が戻ってしまっていないかのテスト、そして数週間ごとの リリースのために2年半かかりました。バージョン化されたディレクトリは 非常に困難な問題でした。
Subversion が "アルファ" 状態となった時点で、すでに何十人という私的 な開発者と会社が実際の作業にかかわることができるようになっていました。 ほかのプロジェクトなら、おそらくこれをもって "1.0" と呼んでいたこと でしょう。しかし私たちは意図的にそのような呼び方をできるだけ遅らせる ことに決定しました。それは私たちは、ユーザの非常に重要なデータを管理 することについての作業であったので、1.0 というような名前をつけること には極端に保守的であったためです。私たちは多くの人々が Subversion を 利用する前にその名前(1.0)を待つ形になるだろうし、その呼び名に対しては 特別な期待を感じているだろうということに気づいていました。それで、 保守的であることにこだわりました。その意図は SCM に対する評判を落として しまうようなデータ消失を起こさないようにすることでした。
まず最初に、私たちを脅しても、どこにも行き着きません。多くの人々は まずリソースを提供しておいて、その後プロジェクトを脅すという手段によって プロジェクトに影響を与えることができると考えているようです。Subversion は他のオープンソースプロジェクトと同様、実力主義を基本としたコードの 貢献と多くの議論によって成り立っています。どんな人に対してもそうですが、 あなたが参加することも歓迎ですが、それは他のすべての人が従っている ルールにあなたも従う限りにおいて、です。詳細は HACKING document を見てください。
次に Subversion の開発者ははっきりしない機能が忍び込むことに対して非常に 敏感です。多くのプロジェクトは目標がはっきりせず、"完了した"ということに たいする明瞭な定義がないので、プロジェクトの範囲がブレたり拡張され、 コミュニティーの興味は移り変わり、そして何もリリースされない、という結果 になってしまいます。その証拠に、Sourceforge 上の何百という死んでしまった プロジェクトをみてください。プロジェクト立ち上げの初日に、私たち開発者 は、何が Subversion 1.0 で解決すべき CVS の問題点であるか、そして 何がそうではないかについての明瞭な定義を列挙しました。もしこの議論を知らない のなら、残念なことです。 それはfront page of the websiteにあり、 何年にもわたり、私たちの変わらぬ指針でありつづけました。もし 1.0 後の 機能の優先順位について影響を与えたいのであれば、プロジェクトの議論に自由に 参加しコーディングの準備をしてください。 issue tracker と mailing lists にアクセスし、未実装のあなたのお気に入りの機能についての現在までの 議論を見てください。どんな機能でも、あなたが最初に考え付いたのではない だろうと、かなり確信を持って言えますので。
最後に、私がネット上で見かけたいくつかの SCM の "比較表" について、 ちょっと暴言めいたことを書きます。ぶちまけた話、いくつかの理由で このような表の信頼性は非常に低いと考えています。それらの多くは 特定の SCM システムのコア開発者によって書かれたものであり、客観的な 比較ができるような人によるものではありません。意識的であれ、 無意識であれ、議論全体はその開発者自身のシステムにとってもっとも重要な 方法論や機能からみた構図になっています。また、別の場合、その表を 書いた人は単なる情報収集屋です: その表は書物の評論のような具合です。 その著者は動き回り、それぞれのプロジェクトの自分たちによる説明を読み、 私たちのためにとてもよくまとまった要約を提供しているように見えますが、 ある集団が設定した具体的な仕事のためにシステムを実際に利用した経験など、 まったくないか、あってもほんのわずかなのです。最後に、このような表の 背後にある仮定について個人的な反対意見を持っています。さまざまな SCM の機能はそれらがあたかも何かプラトン的な理想のシステムがどこかに存在 してるいかのような列挙の仕方になっています: "完全なシステムと比較した ときに、こいつらのシステムがなんぼの物か、調べてやろうじゃないか!" バカなやつらだ。完全なシステムなんてどこにも存在しないのに。そ れぞれのシステムは利点と欠点を持っていて、それぞれ異なる用途に対しては 多かれ少なかれフィットするのです。どんな比較表も、あなたにたいしてどれが最良 であるかなどと教えてはくれないでしょう。あなた自身が試してみなくては ならないのです。
これは危険な議論です -- 誰もコンピュータ言語論争なんかしたくないのですから。 私たちが C 言語を選んだいくつかの理由を書きます。私たちの開発者からの ものを引用します:
可搬性です。C++ コンパイラは Cコンパイラほど標準化されていません。 ある C++ コンパイラでの動作は別のものでは動作せず、C++ライブラリをリンクする ことなど、夢ような話です。
C 言語が得意な、熟練したプログラマーは非常にたくさんいます。
C ライブラリ API はほとんどどのような言語からもアクセスできます。 このような性質は Java にはありません。
可搬性がここでのポイントです。Subversion が C ライブラリの集合体として 書かれていることは C 言語を使わなくてはならない、ということを意味する わけではありません。perl, python, Java, そして C++ などのための Subversion ライブラリバインディングがあります。これらはすべて サードパーティーのプロジェクトで利用することができます。
RCS ファイルを直接いじるのは安全だといっているのですか? 質問を かえましょう: そもそもどうしてあなたは RCS ファイルをエディタでいじらなく てはならないのですか? どうしてあなたのシステム管理者は CVS リポジトリに あるファイルを直接いじるんでしょうか? 私の経験から言って、それはほとんどの 場合CVS 自身によって生じたいくつかの欠点や困難をやり過ごすためだと思います。 よく定義されたシステムではリポジトリを"ハック"する必要はないはずです。
ネットワークをまたいでよく編成されたデータを共有したい場合、今日一番 オーソドックスにやる方法は何でしょう? 簡単です: データを(MySQLのような) データベースに入れてウェブインターフェースからアクセス可能にすれば よいのです。それは 古典的な LAMP ソリューションです。
Subversion は同じことをします: データをデータベースに格納しネットワーク越し に利用可能とします。誰も MySQLに重要なデータが入っていることでパニックを起こしません し、MySQL データはエディタでハックできません。低レベルのデータが見たい場合は テーブルをダンプするためのデータベースユーティリティーを使えばよいのです。 もしデータを移行したければ可搬で透過的な形式にダンプすれば良いのです。
ええ。確かにそうでした。われわれはずっと、スピードよりもデータの正しさに ついて多くの努力をしてきました。しかし2003年の終わりになって パフォーマンスの最適化についてかなりの時間を割けるようになりました。 私たち自身のテストによれば Subversion 1.0 はスピードにおいて CVS に かなり近いところまで来ているといえます。
嘘を言う気はありません。Subversion 1.0 にはいくつかの不具合がありますが 宇宙が消滅するほどの時間をかけずに(Karl Fogelからの引用) そこそこ役にたつレベルのものをリリースするため、不完全な部分も含まれて います:
エラーメッセージの多くがわかりにくい。それに頼って作業しているのに。
文字セット変換に失敗することはよくあります。リポジトリはすべてのパスと コミットメッセージを UTF8 で保存していますがクライアントは常に 入力 UTF8 データを固有のシステムロケールに変換できるとは限りません。 これらの不具合についてもっとまともな状態にして、UTF8 が問題なく利用できる ようにする必要があります。
'svn diff' が履歴に従わない。Subversion は、ファイルやディレクトリの ブランチ(コピー)がソースコードの関連履歴を管理する方法についてたくさんの ノイズを入れてしまいます。しかし 'svn diff' ではなく、'svn log' を使えば 実際の履歴を知ることができます。 svn diff に渡す適切な引数を見つけるために svn log を使うことによって、この 問題を回避することができます。しかし、それはやはりまだ みっともない問題であるとは言えます。
BerkeleyDB は注意深く扱う必要があります。一方でそれは、完全な SQL システム を設定するのではなく共有ライブラリ中のトランザクションデータベースを持つための 非常に便利な方法ですが、もう一方でほとんどの機能はデータベースについては非常に いい加減です。もしリポジトリにアクセスするプロセスが(apache, svnserve, svnadmin, svn, などなど)すべての db ファイル上で完全な読み書き権限を持たない場合、あるいは プロセスが割り込み中断された場合には正しい状態に戻るために、 データベースはロックしてしまい、ジャーナル復帰する必要があります。 こうなっても別に大きな問題はありませんが、このような問題は、あまりシステムに詳 しくないユーザの不注意の結果であることがほとんどです。"大いなる力は大いなる 責任がともなう" -- しかしほとんどの人々はこの責任に気づいてはいず CVS リポジトリ のように SVN リポジトリを扱うことでだめにしてしまいます。どうか 本のこの部分を読んでください 。(訳)そうすれば "教育を受けたユーザ" になることができます。そして、どうか どうか: あなたのリポジトリをネットワークドライブ上に置かないでください!