技術的な観点から見ると、確かに subversion の決定のいくつかについては 議論のあるところです。たとえばそれは期待するようなチェンジセットを 直接サポートしないことでその集中型モデルに問題をおこしています。 しかし技術的な進歩と使い勝手とは別のことです; 多くの人々にとって subversion は多かれ少なかれ自分たちが期待するようなインターフェース になっていると考えられます。 データを保持するのに利用されている Subversion の (より安全な普通の ファイルを使うのではなく、)db の利用方法についても考えものです。 というのはある状況ではこれは身動きが取れなくなる可能性があるから です。現実問題としてはそれほど悪いものでもないように見えます (データを抽出することができるからです)が、確かに人によってはこの ことを心配しています。Subversion は BSD の古いライセンスを使って いて、 OSS/FS とは違い GPL互換ではないのは残念なことです。 ( GPL非互換性は問題を起こすかもしれません). Subversion は制限なしにその他の GPL ソフトウェアを保守するのに利用する ことができます。 Subversion はたくさんのライブラリとプログラムに依存しているので (ちょっと大きすぎると感じる人もいます)現時点ではインストールに 少し苦労します; (Linux/FreeBSDなどの)ディストリビューションはおそらく すぐに subversion を取り込むと思われるので、この問題は比較的早く なるなるでしょう。 Subversion 本 にはより多くの情報があります。
CVS を利用し、もう少しましなものに簡単に移行したいと考えているなら
Subversion は最も単純な方法だといえます。CVS と非常によく似た形
で(特に集中型リポジトリを通じて)どのような認証形態でも開発者に
対して共有されたリポジトリを直接修正することを可能にします(
これは実際の修正を記録することでロールバック可能な仕組みがある
からです)。Subversion の目的は: CVS の改良です。
分散開発には強みがあります。特に別々の人々が独立して別々のアプローチを とり(たとえば独立したブランチやフォーク)、あとでマージするような場合 です。このスケーラビリティーの良さと"適者生存"環境のサポートがLinux カーネル保守にとって分散開発手法が重要になる理由です。 Arch はまた集中型開発にも利用することができますが、これについては後 で述べます。
確かに、いろいろ不満もあるのですが、私は arch がとても気にいっています。 非常に多くの強みがあるのに、どうして私が問題を感じるか不思議に思われる かも知れません。そこでこの問題について議論したいと思います。
arch の深刻な弱みは Windows ベースのシステムではうまく動作しないところ です。また今後そうしていくかどうかが不透明です。arch の移植は ネーティブではないもの(Cygwin と Services for Unix)と、ネイティブの ものもあるのですが、現在の win32 の移植は初期段階にあるだけで、 Arch の wiki 上の Win32 ページでは "Arch は非POSIXシステム上で動作する ように意図されたことはない。Microsoft コンピュータ上で arch がうまく 動くことを期待するな。" とあります。少なくとも問題の一部は arch で 内部的に利用されている長いファイル名です; arch は確かに修正を必要とされて いますが、その方向に向かって大きな動きはないようです。他の問題としては 2004 年 3月時点での一般的な移植の問題の中で シンボリックリンク、ファイルパーミッションの扱い、改行の問題があります。 人によっては Windows のサポートが貧弱であるのは問題であると考えてはいない ようです; が、私にとっては(そして他の人にとっても)、そしてどさくさにまぎれて Tez にとっても、これは深刻な問題です。Microsoft Windows システムを利用 していないとしても、人はいろいろな異なる SCM システムを利用したくは ないはずであり、ある SCM が多くの環境でサポートされており、べつのものが そうではないなら、ひとは多くの環境をサポートしているものを使うでしょう。 私は GNU arch の利用はこのサポートの貧弱さが続く限り妨げられると 思います; 良いネイティブの Windows サポートは SCM ツールにとって 非常に重要です。
2004 年の 2 月にArch はファイル名称を含むいくつかのひどい弱点があります。 ファイル名称中の空白をまだ扱うことができません。これは大きな欠点です (ただしこれは最終的にはすぐ修正されるものとしてスケジュールされて います)。さらに基本的なことですが、Arch は 極端に奇妙なファイル名規約 があり、それがスクリプト、コマンドライン からの利用、そしていろいろな普通のツールでの利用に問題を起こします。 "+" プレフィックスは vi, vim, そしてページャー more のようなありふれたツールで問題を起こします。 (特にこれはログ情報の変更を入力するときに問題になります - どうして この世で最も広く利用されているテキストエディタの一つにとって不便な 規約があるのでしょうか?)。 この "=" プレフィックスは bash のファイル名補完のバグも顕在化して しまいます(このバグは最終的には bash では修正されるでしょうが、 バグのある実装はしばらくそのままでしょう。というのは、このような 利用は非常にまれであり、bash は多くのシステムでデフォルトシェルとして 動作しているからです)。また、こちらはもう少し小さな問題ですが、Arch は"{arch}"ディレクトリにデータを格納しますが、 "{}"文字は多くの シェル(特に C シェル)で問題をおこします。特別な意味を持っているから です("*"のようなファイル名のグロブ文字になります)。 たとえば C シェルでは "cd {arch}"とか"vi {arch}/whatever"とかを 実行できません; ディレクトリ名を引用符でくくる必要があります。 この問題はファイル名規約が悪いということではありません; ほとんどの CM システムはそうなのですから!。問題は arch で選択されている規約の 一部は通常利用するツールと干渉してしまうように設計されている ということで、通常のツールを利用するにあたってさまざまな回避策を 使う必要があるということです(たとえばファイル名の前に"./"を つけるとか、"--"オプションを使うとか)。これは GNU Arch の根底に ある考え方が他のツールとうまく協調して動作することである ことを思うと残念なことです。このようなまずい規約はいますぐ簡単に 修正できるようなものではないだろうと思いますが、常に希望はあります。 いくつかの場合デフォルトを上書きする方法がありますが多くはありません またツールは良い規定値を利用すべきです。 これはとても残念なことです。というのは arch の基礎にある設計 は、特定のファイル名規約が要求される部分など全く存在 しないからです。
GNU arch では低レベルコマンドを使ってさまざまな制御することが可能 ですが実際には自動化したい処理のいくつかについてはまだ自動化されて いません。多くの普段利用する操作は、ほとんどの人々にとって一つの コマンドを標準的なオプションで実行するかわりに複数のコマンドを入力 する必要があります。GNU arch で一つのアーカイブを長い時間使うと 最終的に非常に多くのデータが蓄積され、作業が不便になってきます。 arch's 開発者はアーカイブ中に時間と日付を入れることで分割することをすすめて います。 私はこのような蓄積物の扱いは面倒なことだと考えています: このような手で行う作業はまさに SCM が自動的に処理すべきことだと 思うのです(たとえば、おそらくarch はやろうと思えば一年以上未利用の ブランチをデフォルトで隠すようにできるでしょう)。 Arch はすばらしいキャッシュの仕組みを持っていて、特定のバージョンに ついてのアクセス速度を上げますが、キャッシュは手で作成しなくては なりません(デフォルトではツールは自動的にキャッシュを生成すべき であり、自動的に生成した古いキャッシュを削除する場合もそうです)。 Arch は NFS 上に {arch}ディレクトリがあると遅くなります; Arch は ユーザに意識させずにこの遅さを検出して自動的に別のストーレージを 探しだそうとすべきです。多くの arch 開発者は同じような高レベルの 特殊なスクリプトを作ってこのような処理をしているようです。 しかしここに間違いがあります: 共通の処理を自動化するツールを 自分で書く必要はありません。SCM はそれを含めるべきです。 つまり、自動化と適切なデフォルトオプションによって通常の処理 を"正しく実行すべき"です。 これは良い知らせですが、arch 開発者はこの問題に気づいており修正しなくては ならないと考えています。"rm"(削除)コマンドは id とそれに対応する ファイルの両方を自動的に削除します(別々に削除するかわりに); しかしこれは 2004/2/23 になって初めて追加されたものであり 明らかにこの作業は始まったばかりです。 自動キャッシュ管理機構についてのドキュメントが望まれます; それは まだ書かれていません。ミラーの仕組みは賢いものですが、 ミラーをダウンロードして修正する場合その変更をコミットする ことはできませんし、arch はそれをうまく支援することができません。 undo と redo を使った回避策がありますが、 ミラーからダウンロードした場合でもコミットできるようにすべきです。
Arch は時には許されていないような危険な、あるいは問題のある 動作を許しています。たとえばブランチはコミットベースのブランチ (base-0 以下のすべてのリビジョンがコミットで作成されるようなもの) であるかタグリビジョンブランチ(すべてのリビジョンはタグで作られる) かのどちらかであるべきです; そうしないとマージコマンドがうまく動作しませんが、 ツールはこの制限を強要していません。tla のツールはまだ保留中のマージ拒否ファイル (.rej 拒否ファイル)がまだあるかどうかを確認しないので、commit, update, replay, star-merge は作業領域で交差してしまいます; ユーザは間違いを犯すものであり、 SCM システムはそれからデータを守るように動作する必要があります。
ユーザインターフェースにも問題があります。 悪夢のようですが、"mv" と "move" コマンドは別のことをします: "mv" は id とファイルの両方を移動しますが、"move" は id のみを移動します。 このユーザインターフェースは混乱のもとです: なぜ "move"と"mv"を同じにして"mv-id" を id のみを操作する唯一の コマンドとしないのでしょうか? 多くのコマンドには別名があり、それがドキュメントを不要に複雑な ものにしてしまっています。
arch のドキュメントは貧弱でもっと作業が必要です: これは特に残念なことで、ドキュメントの問題は今日から使ってみようとする 初心者に障害となるからです。しかし、オンライン上で利用できる情報を 注意深く読めば arch の基本的な使い方には十分かも知れません。 ドキュメントの多くは低レベル層の実装の詳細を強調し( たとえば、ローカルファイルシステム中でコマンドがどのように実装される かというような) より高レベル層にはそれほど触れていません。 ドキュメントの一部は別名を強調していますが、これは非常にイライラ します; もし "add" と "add-id" が同じことを意味するなら、単に "add" をドキュメント化すればよいのです(そしてあとで読まなくて良い ような注の中に別名の一覧を書けばよいのです)。 場合によってはドキュメントはソフトウェアが本当にしていることに あわせて更新する必要があります。 The on-line tutorial at the FSF GNU arch website にあるオンラインチュートリアルは、とっかかりとはしては良い場所で、 より詳しい情報を得るには Arch Wiki が非常に良い場所です。
総じて GNU arch は現時点では subversion ほど成熟してはいません。 その実装はもっと噛み砕く必要がありますし、奇妙なファイル名の制約は 修正されるべきで、自動的にやって欲しい最適化を手でやらなくてはならない ような場所があります。すでにのべたように、コマンドはしばしば低レベル のものです; それはさまざまな単純なコマンドであり、デフォルト値あるいは 組み込みのコマンドとして実装すべきものを手で設定しなくてはなりません。 そしてドキュメントをもっと充実させる必要があります。
しかし GNU arch がこのような問題を長期間にわたって持ちつづけるとは 思わないでください。ほとんどのものは短期的なものです。 問題の多くは単に GNU arch が subversion のようなほかのツールほど 成熟する時間をもてないでいるということにすぎません。 私がこのような問題を書いたのは実際 GNU arch はやらなくてはならない ことがたくさんあるからです。 私の意見では GNU arch 開発者は単純さ、デザインのオープン性、その力 (複雑な状況に対処する能力)を強調し、今のところ使いやすさ(特に 単純な状況における使い安さ)にはあまり注意を払っていません。 そのため上に挙げたような問題はあるにせよ、GNU arch は極端に強力で 基本的なコンセプトは実に柔軟です。 より多くの時間とGNU arch 上に構築されるツールがこのような問題を解決して くれるでしょう。 Arch はまた Free Software Foundation (FSF)によって支援され、 その Savannah システムによって直接サポートされています; これは成功を 保証するものではありませんがそのような支援はよくユーザや開発者を プロジェクトに参加されるものであり、それによって成功の可能性も 増すでしょう。 GNU arch ははっきり言って問題に対する非常に面白いアプローチをとって おり、さまざまな問題を解決するでしょう。
すでにおわかりのように、SCMシステムの動作原理には二種類の考え方が あります。ある人たちは SCM システムは集中型リポジトリを制御することが 第一目的であり、集中リポジトリをサポートするツールを設計すべきだと 考えています(CVS や Subversion がそうです)。 他の人たちは SCM は独立した開発者が非同期に作業し、その後、同期をとり お互いに変更点を反映するので、開発ツールは分散アプローチをとるべき だと考えます(GNU arch, monotone, darcs, そして Bitkeeper)。 あるアプローチをサポートするために作られたツールは別のアプローチを サポートするためにも利用することができますが、それでもこの基本 的な違いを理解するのは重要です。
一方でサポートされているツールはしばしば、すくなくともある範囲で もう一方でも利用することができます。概念的に分散アプローチをとると 大きな困難なしに集中型アプローチの完全な実装ができるはずです。 しかし、このような"別のアプローチ"のサポートが、同じ問題をネイティブに やるのと同じくらいツールが良くできているかどうかは私にははっきりしません。 特に集中型システムが分散開発をサポートする場合がそうです。 Subversion には svk という subversion 上に作った分散 SCM システムがあります が、subversion の上の svk の実装は分散 SCM システムを作るには非常に 重たい方法であり、ネイティブの分散 SCM システムを実装するよりずっと 大変です。 GNU arch は簡単にリポジトリが実装されているディレクトリの読み書き アクセス権限を共有する開発者を作ることで集中型リポジトリをサポート することができますが、セキュリティに関する以下の議論を見てください。 (ユーザによってリポジトリを直接制御するため). また、 arch-pqm という ツールがあり、これは私のセキュリティの心配のいくらかを 軽減してくれるものですが、まだ GNU arch に統合されてはいません。 さまざまなプロジェクトの支援者のすべては"自分たちの側" が もう一方のアプローチをサポートするのに十分であると感じているようですが。 別々のプロジェクトが"もう一方の"アプローチをよりうまくサポートする 努力をつづけてもらうことを期待しています。これによって 数年以内にこの違いは本当にささいなものになるかもしれません。
A posting by Bastiaan Veelo at Linux Weekly News は良い要約になっています:
"しかし最も重要なのは Arch と Subversion は異なる基本的な原理の上に あるということだ。Arch は分散型で動作し、Subversion は クライアント/サーバモデルで設計されている。確かに Arch を使えば 最初にサーバにアクセスすることなしにバージョン管理システムを 使ってソースコードを書き始めることができる。しかし コードを主系にマージするのは一人のプロジェクト管理者によって されるだろう...Subversion(そして CVS も)による開発は一つのリポジトリしか存在しない という意味で集中型であると言えるが、実際には社会的な意味では もっと分散している。というのはリポジトリに書き込み権限をもつ 開発者と同じくらいの多くの、コードを統合するための人間がいるからだ。
手短にいって、 Arch はコードの統合する人に関して集中しており、 Subversion(CVSも)はリポジトリに関して集中していると言えるだろう。 どちらが合っているか決定することができる。もし CVS のヘビー ユーザであれば Subversion がぴったりだろう。
すでにのべたように概念的には分散システムは集中アプローチを完全に 実装することができるはずです。 私はGNU arch を使って複数の開発者の集中リポジトリをサポートする ためのおすすめの方法について少し考えました。 いくつかのツールは私の考えを取り入れているようですが、現実的な利用 にはもっと努力が必要です。
GNU arch wiki サイトはどのようにに arch を集中型で利用するかについての 基本的な情報があります。 GNU arch で集中リポジトリを実装するのはやさしいことです: 集中リポジトリ を作るのに共有ファイルシステム(たとえばセキュア ftp)に対してすべての 開発者に読み書きアクセスを許すのが一番簡単な方法です。 "リポジトリ" はある意味ですべての人が書き込むことのできる偽のユーザという ことになります。お互いに保護する必要のあるたくさんのプロジェクトリポジトリを 管理するシステムはこの分離機構を提供するためにユーザとグループを(プロジェクト ごとに)定義する必要があるでしょう。 これはささいな問題に見えるかも知れません(システム管理者や特定のグループ 管理ツールが新しいプロジェクトやプロジェクトに参加する新しい開発者が あらわれるたびに必要になります)し、大きな問題かも知れません( オペレーティングシステム制御を徹底的にテストしアプリケーションレベルの 制御よりもずっと信頼できるものにする必要があるかも知れません)。 １度設定すればこのシナリオには確かに多くの利点があります。 たとえば、複雑なサーバを構成するよりも共有ディレクトリの設定は 簡単であることが多いです。
しかし、arch をこのような方法で使う場合には問題もあると思います。 このアプローチはすべてのクライアントは"完全に動作する" ということを 仮定しているからです; もしたくさんの開発者がいる場合、 古いクライアントを使っている何人かの開発者のものにはバグや意味上 の違いがあるかも知れず、リポジトリ全体を破壊してしまうかも知れません。 もっと重要なことには、開発者と攻撃者、これは一時的に開発者の 特権を手にしたものですが、これを区別することができません。 開発者は共有リポジトリに対して完全な読み書きアクセスを持って いるため、悪意のある開発者(あるいは開発者の認証を奪った攻撃者) は共有の arch リポジトリを傷つけることができ、リポジトリの状態を 期待されるとはまったく別の状態に変更してしまうことができます。 これに対処しなければ悪意のある開発者や、特権を得た攻撃者は 変更点を明らかにしないで悪意あるコードを挿入することができて しまいます。あるいは修復不能な形にデータを消去してしまうかも知れません。 明らかに悪意ある開発者が悪いのですが、SCM システムは常に誰がその 悪意あるコードを挿入したかを特定できるべきであり、SCM の履歴 の完全性を保護すべきですが、それを使えば変更点は簡単に元に戻す ことができるからです(そして必要に応じて再チェックすることもできます)。 今日のような不信の時代にあっては、よく本当には知らない人と共に 作業しなくてはならないので、悪意ある攻撃に対する保護は重要になります。
集中リポジトリ用に推奨される GNU arch の設定はすべてのユーザが ひとつのアカウントを共有するというもので、オペレーティングシステム と arch はログインした人を実際には区別することができません。 ユーザが個別に認証できるように共有ディレクトリのリポジトリを 設定し、それから共有ディレクトリを(グループの仕組みを使って)設定する ことはできますが、それだとユーザは間違って(あるいは意図的に)アクセス ビットを変更してしまうかも知れず、その後別の開発者はそのファイルを 読んだり書いたりすることができなくなってしまうでしょう。 そこで推奨のアプローチはクライアントが間違った振る舞いをすればいろいろな 不具合がおきるか、さもなければ開発者をあまり信じないかです。 でなければ攻撃者は開発者の特権を得てしまうかも知れません。
バックアップを取った後であれば、バックアップとオリジナルを比較することで リポジトリの履歴に対する悪意ある修正を検出することができるかも知れません。 バックアップはまた人々に悪意ある変更を正しいバージョンで置き換えることを 許すでしょう。 しかし、arch は現時点ではこのチェックを自動的にやるようなツールを 含んではいません。(arch のミラー機能をこの用途に利用できるとは 思えません。arch のデータ自身が疑わしいのですから。) それで arch がそのようなツールを追加するまではこのようなことをするには arch の内部をよく理解する必要があります。 このアプローチは犯人が特定の開発者のふりをしてログインすることが求めら れた場合でも誰が悪意ある変更をしたかを特定することはできません。 しかしより重要なことは、悪意ある開発者が悪意ある変更を加えたあと、それが 別の誰かがやったように見せかけることはたやすいということです。 バックアップは追加された点を教えてくれるだけで、その追加が正しいか どうかは教えてくれません。 バックアップは確かに有用ですが、攻撃者はそれを回避することができます。
この問題に対する、また別の部分的な(しかし重要な)解決策は新しい signing archives の機能でこれは arch 1.2 で追加されたものです。 アーカイブを "signed" にするように選択することができ、 変更は暗号学的に署名されます。 これについては少し調べました(サインの仕組みの詳細を理解するのにColin Walters の助けを借りました。 arch が MD5 ハッシュでサインするのは暗号学的には SHA-1 ハッシュよりもずっと 弱いのですが、確かに何もサインがない状態からは一歩踏み出したことになります。 サインつきアーカイブの設定にはより多くの努力が必要になります( たとえばすべての開発者の公開鍵が必要になります)が、セキュリティを 考慮したシステムでは良い方法になるでしょう。 署名は変更点と共にリビジョン番号にもサインするので(それらは両方とも tar ファイル中に埋め込まれているため)攻撃者はパッチ順序を変えることは できず、検知されずにパッチを削除してそれより後のパッチの番号を振りなおすことは できません。 しかし、そのような署名は(少なくとも現在の実装では)、サインされたパッチ 全体を置き換えるのを検知できないように思えます(たとえば以前の セキュリティ修正をセキュリティ修正のないものでこっそり置き換える ような場合)。あるいは誰も利用しない前に"最新"の修正を消してしまうような ことです。 バックアップとは違い、署名は多くの問題を外部の情報と比較すること なしに検出することができ(そのため問題を早期に発見できるでしょう)、 またすでにツールに組みこまれているので、利用される可能性が高いでしょう。 多くの開発者にとってバックアップとサインつきアーカイブは十分です。 しかしこの仕組みは依然としてある種の悪意ある変更を明らかにしません (削除と置き換えのような場合)。本来であれば開発者はこれを知ることが できなければなりません。
Arch-pqm (パッチキューマネージャー) は分散ツール上に集中型リポジトリ を作るための arch の拡張で、コミット要求などをキーに入れてから 自動的に実行します。 Arch-pqm はまず要求中にある GNUPG サインがそのリポジトリに対する 許可された開発者であるかどうかを確認し、そうでなければ要求を拒否します。 これは CVS や subversion のような集中型のツールの動作アプローチと よく似ています。arch-pqm の開発者Colin Waltersとemailで何度か 話しをし、arch-pqm は単にリポジトリの履歴を保護するような操作のみ を認めていることがわかりました。特にarch-pqm は新しい変更をマージする ためのスターマージ、キャッシュ、キャッシュの取り消し、 新しいカテゴリ・ブランチ・バージョンの作成、そしてタグづけのようなもの のみをサポートしています--どの操作もリポジトリの履歴を消すことはありません。
それで現時点では、サインつきアーカイブ、バックアップ、そして arch-pqm の組み合わせによっておそらく私の心配は解決するだろうと思います。 Arch-pqm はリポジトリにアクセスする権限のある任意の開発者が 既に固定されてたリポジトリ内の値を好きかってに書きかえることを 防ぎます。サインつきアーカイブとバックアップとの比較は攻撃者が arch-pqm を攻撃したり回避したりした場合リポジトリに対する悪意ある 変更を検出し、修復することが可能になります。 悪意ある開発者の修正は常に彼らのものとして正しく記録され、あとで 戻すことができます(彼らの変更点に必ずサインすることを約束して おくことによって)。そして少なくともインフラストラクチャが他の方法では できないことを検出するので私の心配はなくなります。(??) 注意: 私はセキュリティの解析を詳細にしたわけではなく arch-pqm は このセキュリティの問題のために最初から特に設計されたものでは ありません。 たとえば、ファイル名を追加するか設定を変更しようとすれば、この保護を 破ることができるかも知れません。 あるいはバッファオーバーフローや、その他このチェックを潜り抜ける方法が あるかも知れません。 それでも基本的なコンセプトは良いものであると思われますし、少なくとも ある種のセキュリティはこの設定で保たれるでしょう。(??) 残念なことに、arch-pqm の利用はまだ arch には組み込まれてはおらず、 バックアップチェックもそうです。それでこのアプローチをとるには 「ちょっとした努力」よりは大きな努力が必要です。またドキュメント はこのような設定の方法について説明していません。
現時点で Arch は署名のサインをサポートしているとは思いません。 言い換えると、もし B が A の作業を受け入れ、C が B の作業を 受け入れた場合(それはAの作業を含んでいるわけですが)、私は A による A 自身の署名を見ることになり、 B のサインは彼らが A の作業を 受け入れたことを示すべきです。公平にいって、ほとんどの SCM では これをサポートしていません。しかし集中システムでは時刻による同等の 機能を持たせることは簡単です; 分散システムはこの種の情報をよりたくさん 記録すべきです。それは信用できる中心になる場所が存在しないから です。
Colin Waltersはまた サーバ機能をサポートする "arch" 用の"スマートサーバ"である "archd" を作っています。 ある意味これは arch-pqm と似たコンセプトです; それは認証されたユーザからの SCM コマンドを自動的に実行するものだからです。 しかし archd は email を利用するかわりにデータ転送用に特別に設計された プロトコルを使っています。 それは同様の保護機能を持ち(実行できるコマンドは制限されています)、もし 正しければ同じことが言えるでしょう。しかしそれは今後のことになります。 現時点ではまだ利用できません。
すべての SCM において、悪意ある開発者について心配するのであれば だれが"フック"を定義できて、実行するときにどのパーミッションで 実行されるかに注意しなくてはなりません。 GNU arch がコマンドを実行するときには常に GNU arch はプログラム~/.arch-params/hook を実行します(存在していれば)。 これによって追加の動作を実行できます("それをフックといいます")。 言い換えるとフックはユーザごとに定義されるものでありプロジェクト単位 にではありません。このデザインはセキュリティの観点からは有利です; フックは通常、管理されているプロジェクト領域の内部にあるわけではない ので、ファイルの編集によって新しいコマンドを実行するように SCM をだます ことはできません。しかし、もし共有リポジトリがあるならこれは欠点に なります。というのは共有リポジトリはあることを強制するようなコマンドを 実行できないからです(たとえば、コンパイラのワーニングがないこと、 後退テストを実行すること、emailによるアナウンス、あるいはチェックインする 前の二人の人間による承認、など)。 これもまた arch-pqm またはスマートサーバによって解決することが できますが、それはサーバが自分自身の環境内でフックを実行できる からです。
Monotone 特に興味深く思われますが、それは分散 SCM とは異なる アプローチを取っているからです。 Shlomi Fish が言うように、 "チェンジセットは預かり所(depot)に入れられ(それはCGIスクリプト、 NNTP ニュースグループやメーリングリストのようなものかも知れませんが) ます。depot とはさまざまな場所からのチェンジセットを集めておく場所 です。その後、開発者ごとに良いと思われるチェンジセットを自分だけの リポジトリにコミットします... Monotone は SHA1 チェックサムを使ってファイルとディレクトリの バージョンを特定します。そのためファイルがコピーあるいは移動された 場合でも、サインが等しければ検出することができ、この両者のコピーを マージすることができます。 またそれは、できる限り CVS をエミュレートしようとするコマンド群が あります。" Monotone は最近特殊なファイル名称を扱うという問題のいくつかを 修正しました(これは SCM システムでは共通の問題です)。 Monotone がセキュリティ、明瞭なコンセプトに重点を置いていることは 他の SCM も考慮すべきかも知れません。 Monotone のアプローチは3方向マージとSHA-1ハッシュに基礎をおいて います。Monotone の人々は Arch のアプローチは Monotone の それよりもいくらか弱いと考えていますが、Monotone はある種の "チェリーピッキング"のサポートについては Arch ほどすぐれてはいません。 ("チェリーピッキング"とは、好きな修正点だけを選択的に取り込む ことです-tez) (Monotone FAQ に、より詳細があります)。 Monotone は GNU arch ほど知られていません(Google のリンク数によれば) が、知るべき価値のあるシステムです。
ほとんど理解していないためいくつかの SCM プログラムを試しては いませんが、他のものも見てみましょう。 Aegis はルートで実行することが必要で、セキュリティ的には非常に 弱く、私はすぐに利用をやめてしまい、インストールが非常に 難しいという報告でそれ以上調査する興味をもてなくなりました。 Vesta は完成度が高いと言われていますが、Vesta を構築するには Vesta 自身しか利用できないので、新しいユーザや開発者をひきつけるのは 難しいだろうと思っています。 RCS はずっと古く(SCCS もそうです); そのロックを基礎とするアプローチは 今日の早い開発サイクルと大きな開発者グループにとってはあまりうまく 動作しません。Bitkeeper は強力ですが、OSS/FS ではないので、この 文章の範囲外としました。
darcs についても少しコメントしようと思います。 見たところ、darcs は現時点では SCM の非常に革新的なアイディアの プロトタイプ以上のものであり、利用可能だとしても大きなプロジェクト用の 有用なツールというよりは、小さなプロジェクト用のツールとして 有効かも知れません。 Darcs は Haskell で書かれており、それは強さと弱さをもっています。 Haskell は高級関数プログラミング言語でおそらく抽象的な概念の上で 開発者が集中できるような助けとなっているかもしれません。 しかし、Haskell は興味深い言語ですが、それによるプログラムは 一般的に処理が遅く、darcs の開発者も darcs のパフォーマンスがあまり 高くないことを認めています(プロジェクト規模が大きくなるとこれは問題 になるかも知れません)。しかし 2004 年 3 月時点で、少し改善されたようです。 関数プログラミングが得意な開発者は非常に少ないので darcs はそれを 拡張しようと言うほかの開発者を得るのが難しいようです。 (貢献する人もいますが、Subversion や GNU arch とは 比べ物になりません)。 Darcs のウェブサイトによればそれは、"豊富な機能がある"とは言えず その"コア部分はまだバグがある"とのことです -- 自分のソースコードを 管理しようとするときに聞きたくなるような言葉ではありません!。 主な開発者はウェブサイトは古いと言っており、プログラムにはもうそれほど 多くのバグはなく、基本的な SCM の処理以上のものをサポートしている (いくつかの機能は欠けているにせよ)とのことです。 しかしdarcs にはいくつかの革新的なアプローチがあり、そのコンセプトの 一部は次世代 SCM システムで利用されるかも知れません。 Darcs は完全にパッチ指向のシステムであり何が変更されたかを示す 入力をユーザに求めます。 たとえば、darcs は"文字列置換パッチ"を理解することができ、 これは変数のすべてのインスタンスを変更するようなパッチ にすることができます。たとえば ``stupidly_named_var''を ``better_var_name''で置き換えるが、``other_stupidly_named_var'' には触れない、といった感じです。 作者によれば、 "このパッチが``stupidly_named_var''を含むような別のどのようなパッチと マージされる場合でも、そのインスタンスは``better_var_name''に 置換されるでしょう。これは、新しい変数のインスタンスの変更に失敗する だけではなく、その変数を含んでいる行を修正するどのようなパッチを マージする場合にも衝突が起こるかも知れないような伝統的なマージの方法 とは対照的です。 プログラマの意図についての追加の情報をもっと利用することによって darcs は本当は簡単な変数名の置換のような処理を実際単純にすることが できるのです..." 有利な点はマージの衝突はすぐに消えてしまうかも知れないことです; 不利な点はこの要求はすでに複雑な問題を抱えている開発者に対してより 多くの対話的な入力を求めます。 このアプローチがウケるかどうかは見てみなくてはわかりません; 私は怪しいと思います、というのはそのような機能を持たないシステム が多くの開発者に受け入れられているように見えるからです。
他にもさまざまな SCM の比較があります。 better SCM initiative は、OSS/FS SCMシステムを改良を働きかけるために設立され、それらに ついて議論し比較しています。 他の情報と共に comparison fileを見てください。 Shlomi Fish's OnLamp.com article compares various CM systems と、彼の Evolution of a Revision Control Userを見てください。 arch の人々は a comparison of arch with Subversion and CVS を書いています( もちろん、arch 寄りです)。 他の arch に肯定的な議論としては Why the Future is Distributed。 subversion に肯定的な議論としては Dispelling Subversion FUD。 Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. A brief overview of SCM systems that can run on Linux is available.
私はバグトラッキングシステム(Bugzillaなど)のような関連した 議論はしませんでした; これはここでのテーマの範囲外です。
http://www.dwheeler.com にある私のホームページには自由にアクセスしてみてください。