Kiln が Git (や他の SCM)ではなく Mercurial をサポートする理由

Benjamin Pollack、 2009 年 10 月 24 日、 原文 (original post) はてなブックマークへ追加 はてなブックマーク - Kiln が Git (や他の SCM)ではなく Mercurial をサポートする理由 Bookmark this on Delicious

Kiln が Mercurial を選択した理由を疑問に思うなら、つまり質問は 2 つあるということです。

  1. Kiln が DVCS ベースな理由は?
  2. Kiln があえて Mercurial を選択した理由は?

Kiln が DVCS ベースな理由は?

DVCS が本物のブランチをサポートしているからです。 ご存知のとおり、 Subversion や CVS の様なツールでブランチをマージしようとすると、 まず間違いなくかなりイライラさせられてしまいます。 Subversion 1.5 以前はマージ履歴を全く記録しておらず、 また、最新版でさえそのメタデータを上手く活用できていないため、 マージはいつも途方もない労力を要し、間違いだらけのプロセスで終わるのが落ちだからです。 こうして、ブランチを維持することは技術的に可能であったとしても、 とてつもない苦痛を伴うため、開発者はたいてい全力でブランチを避けるようになるでしょう。 その代わりにどうしているかと言うと、 開発者は仕方なく trunk で常に開発を進め、 ごくたまに「ブランチ」を作ります。 それはポイントリリースのスナップショットにすぎませんが。

Git、 Mercurial、 Bazaar など DAG ベースの現代的な DVCS は全て、 いつどこで最後にマージしたかを正確に覚えています。その履歴には特別な「マージ」オブジェクトがあり、 さらにはマージした履歴も全て維持しているのです。 結果として、 DVCS は Subversion の様なツールがゲロを吐く複雑なマージをさらっと自動的に行うことができ、 また、あなたはいついかなる時点においても、ブランチをマージしたかどうかをさっと確かめることが可能です。

ところで、それがなぜ重要なんでしょう? それは、現実のソフトウェア会社においては、 製品を複数バージョン同時にメンテする必要があるためです。 バージョン 2.0 を出荷したからといって、 (普通は)バージョン 1.0 のサポートを打ちきるわけにはいかないでしょう。 Subversion のような古典的な VCS では、 アクティブなブランチに対してそれぞれ別々にバグ修正をコミットしていました。 両方のバージョン間で同じ修正を明示するような印は一切ないですから、 どの修正がいつマージされたか追跡する方法はありません。ある特定の機能が 実際に取り込まれているか確認するのは困難です。

一方、 DVCS ではこうです。 マージは簡単です。あなたがマージしたいものをツールが知っているんですから。 1.0 のバグ修正が最終的に 2.0 に入っていることを確認するのは、 1.0 のコミットが 2.0 にあることを確かめるぐらいに簡単です。 同時並行に開発を進めることが、突然すごく簡単になりました。

我々が思うに、これが DVCS のいずれをもすごくクールにしている目玉機能で、 Subversion や CVS の様なツールからずば抜けている点です。 そして、 Fog Creek が Kiln を持って DVCS 支持層に打って出ることにした理由でもあります。

Kiln が Git など数ある DVCS の中から Mercurial を選択した理由は?

正直に言います。我々は Git が好きです。 Git はあり得んぐらい高速で、 Ruby コミュニティーに愛され、 Linux カーネルのような大規模なプロジェクトを扱うのに十分パワフルで、 GitHub のようなサイトをベースにすごくクールなコミュニティーがあります。 GitHub は、開発者にとって Facebook のようなものです。

しかし、我々は Mercurial も気に入っています。 Mercurial も Git とほぼ同じぐらい高速で、実に拡張性が高く、 Linux と Windows 用の素晴らしい GUI があり、 Firefox や Java のようなかなり規模の大きいプロジェクトを管理し、 Google Code や Bitbucket を介してすごいコミュニティーがあります。

実のところ、 Mercurial と Git は機能面から見るとかなり近いので、 正直我々はその間の論争を理解していません。どちらも DAG ベースの DVCS です。 いずれもぶっ飛んだマージ機能があり、同じギーク向けの機能[1]を備え、 大きなコミュニティーサポート(Git には Linux、 Ruby、 X が、 Mercurial には Python、 Java、 Google)があり、 いずれもとんでもなく高速です。 結局のところ、個人の好みによるんでしょう。

ですから、どちらのツールも間違いなくクールです。実際、あなたがいずれかを気に入っていれば、 他方も気に入るだろうと我々は確信しています。そして、あなたが Subversion のようなツールを使っているなら、どちらかのツールを使うことはとてつもない改善につながるでしょう。 けれど、 Kiln のベースとして最終的に我々はひとつに絞る必要がありました。 少なくとも最初のリリースには。そしていろいろと考慮した結果、 DVCS 初心者にとって Mercurial の方がちょっとだけ使いやすいと思われました。 そしてそれは Git のパワーを全く犠牲にしません。

我々の立場で重要なことは、 DVCS 革命を導く力になることです。 利用するツールが正確に何であるかは大して重要でありません。 我々はちょっとだけ Mercurial びいきであり、他では Git が少し好まれているというだけです。 DVCS かモノリシックツールかに集中しましょう。あとはそれほどではありません。

[1] ギーク向けの機能とは、例えば、リベース(git rebasehg rebase)、 部分的なコミット(Git の index と hg record)、履歴の修正(git rebase --interactive と Mercurial の超強力な MQ 機能)、署名つきパッチなどです。 本当のところ、どちらかのツールにある機能は概ね全て同等な機能が他方にもあります。

翻訳: 西原 佑哉 、 2010 年 3 月 20 日 、 原文 (original post)