2007年5月に、Linus Torvalds氏がgitについてGoogleでプレゼンテーションして以来、分散バージョン管理システムへの関心や採用が増え続けています。この記事では、git、Mercurial、Bazaarの３つのツールを題材にして、分散バージョン管理システムのコンセプト、使用するタイミング、現在使われているバージョン管理システムよりも優れている理由を紹介します。
・分散バージョン管理システムとは？
バージョン管理システム(VCS、もしくはソフトウェア構成管理：SCM)は、情報の各リビジョンを追跡するシステムです。一般的に、ソフトウェア開発において、ソースコードを管理するために使用されています。1986年、初めてCVSが使われ、その時以来、Subversion (2000年)やPerforce (1995年)、CVSNT (1998年)といった、CVSよりも優れた点を持つ、多くのソフトウェア構成管理が使われてきました。
1999年12月、Linuxカーネルのメインラインのソースコードを管理するため、Linus氏は"その作業を行うためのベストなツール"と評したBitKeeperを採用しました。それまで、Linus氏はパッチの統合を手動で行っていたのです。BitKeeper登場前のバージョン管理システムは、全てクライアント-(中央)サーバモデルでした。一方、BitKeeperは真の分散システムであり、全ての開発者がおのおのマスターコピーを持つことができる、初めてのバージョン管理システムでした。ライセンス上の問題から、BitKeeperの利用は中断され、代わりにgitが採用されました(2005年4月のことです)。Mercurial (2005年4月)、Bazaar (2005年5月)、darcs (2004年11月)、Monotone (2003年4月)も、同様のモデルのバージョン管理システムです。
なぜ分散バージョン管理システムなのか？
または、中央管理のバージョン管理システム(特にSubversion)ではなぜ不十分なのでしょうか？
Subversionはいくつかの点で非難を浴びています。
- 主な理由は、ブランチを作成するのは簡単ですが、マージが困難であるというところです(しかし、ブランチを行えばマージの必要が出てきます)。当然、あなたのプロジェクトでは、開発用やテスト用ブランチを簡単に作れる必要があることでしょう。Subversionでは、ユーザが自らの手で、エラーを発生させる可能性のある、ブランチ間でマージされたリビジョンの追跡を行う必要があります(Subversionにはこのような機能がありません)。
- 中央サーバにコミットする以外、別のユーザに変更を配信する方法がありません。
- Subversionでは、ファイルやディレクトリの名前が変更されていたら、マージが失敗してしまいます。
- trunk、tags、branchesディレクトリを用意するという慣習は、誤解を招く可能性があると考えられています。
- オフラインではコミットできません。
.svnのファイルがローカルディレクトリを汚してしまいます。svn:externalが有害な操作になり得ます。- パフォーマンスに問題があります。
最新の分散バージョン管理システム(DVCS)では、実装の工夫や分散システムであるという事実そのものにより、これらの問題が解決されました。ただ、結論にもあるように、Subversionはまだ廃れてはいません。
どのように"分散"を実現しているのか？
分散化
分散バージョン管理システムはピアツーピアの仕組みを活用しています。クライアント間で通信することができ、中央のサーバやリポジトリを介さずに、ローカルブランチをメンテナンスすることができます。クライアント間で同期することができ、各クライアントが交換する変更セットを決定します。
結果として、分散バージョン管理システムには、中央管理の仕組みに比べ、いくつかの特筆すべき利点や差異があります。
- デフォルトではコードベースの参照コピーが存在せず、ワーキングコピーだけです。
- オフラインでの操作：中央の管理サーバにアクセスする必要がないため、コミット、履歴の閲覧、差分表示、変更取り消しといった一般的な操作が高速です。さらに、もし中央の管理サーバが安定性向上や参照、バックアップの目的で存在していたとしても、"分散"されていれば、中央管理型のバージョン管理システムほどサーバへ問い合わせする必要がありません。
- 各ワーキングコピーはコードベースと変更履歴の効率的なリモートバックアップであり、データ消失の予防になります。
- 実験的なブランチ作成 – ブランチの作成と削除がシンプルかつ高速です。
- クライアント間の連携を容易にします。
分散バージョン管理システムを使った連携についての概要を知りたければ、図解 分散バージョン管理システム入門やBazaarの連携ワークフローを一読してみることをお勧めします。
また、分散バージョン管理システムには、いくつかの不便な点があることも覚えておくべきです。特に、複雑さです。分散管理の視点は中央管理型とは大きく異なり、使いこなせるようになるには、いくらか時間が必要です。ファイルトラッキングの代わりに、変更セットをトラッキングすることもまた、混乱の元になるでしょう。例え、それが非常に強力であり、理論上はファイルからファイルへの移動をトラックすることが可能だとしても。
誰が提供しているのか？
競争激化！ 良い点、悪い点の比較
ここに挙げた良い点、悪い点については、基本的に、ブログで取り上げられていた比較結果や、個人的経験に基づくものです。ただし、現状とあわなくなってしまった、古い情報については、更新してあります。
なお、ここに挙げているのは機能の一部であるということ(例えば、gitには150以上のコマンドがあります)、リストの各項目の重要度が全て同じ訳ではなく、他の項目に比べてずっと重要なものもいくつかある、ということを頭に入れておいてください。
| git | Mercurial | Bzr | |
|---|---|---|---|
 |
 |
 |
|
| プロジェクト | |||
| メンテナ | Junio C Hamano氏 | Matt Mackall氏 | Canonical Ltd. (GNUプロジェクトになりました) |
| 並列モデル | マージ | マージ | マージ |
| ライセンス | GPL | GPL | GPL |
| サポートしているプラットフォーム | POSIX、Windows、Mac OS X | Unix系、Windows、Mac OS X | Unix系、Windows、Mac OS X |
| コスト | 無料 | 無料 | 無料 |
| 成熟度 | |||
| バージョン |  > 1.0 (1.5.5) |
> 1.0 (1.0) |
> 1.0 (1.3.1) |
| プロジェクト開始時期 | 2005年4月 | 2005年4月 | 2005年5月 |
| 実装 | |||
| コードの割合(テスト以外) |  |
 |
 |
| コード行数 | 130550 | 38172 | 79864 |
| テスト | ソースのうち約20% |
ソースのうち約25% |
ソースのうち約50% |
| 履歴モデル | スナップショット | 変更セット | スナップショット |
| リポジトリの増大率 | O(パッチ) | O(パッチ) | O(パッチ) |
| ネットワークプロトコル | HTTP、FTP、Eメール、カスタムプロトコル、ssh、rsync | HTTP、ssh、Eメール | HTTP、SFTP、FTP、ssh、カスタムプロトコル、Eメール |
| 基本機能 | |||
| アトミックなコミット | |
|
|
| ファイル名変更 | 暗黙的 |
|
|
| ファイル名変更のマージ | |
|
|
| シンボリックリンク | |
|
|
| プレ／ポストイベントのフック | |
|
|
| 署名付きリビジョン | |
|
 部分検証／手動検証 |
| トラッキングのマージ | |
|
|
| 改行コード変換 | |
|
 計画済み(1.6) |
| タグ | |
|
|
| 国際化のサポート | |
計画済み |
|
| 部分チェックアウト | 代わりにサブモジュールを使用 |
計画済み |
計画済み |
| モデル／アーキテクチャ | |||
| ファイル | トップレベルの.gitディレクトリ(1つだけ) |
トップレベルの.hgディレクトリ(1つだけ) |
トップレベルの.bzrディレクトリ(1つだけ) |
| モデル | 単純なブランチモデル(クローン＝ブランチ) | 単純なブランチモデル(クローン＝ブランチ) | |
| リポジトリの特異性 | ブランチ間でリビジョンを共有するための共有リポジトリ より優れたストレージモデルだと考えられています |
||
| ディレクトリのバージョンニング可能性 | |
|
|
| サブモジュール | git-submoduleコマンドでサブモジュールをサポート |
Forest拡張(OpenJDKで利用されている)でサブモジュールをサポート |
サードパーティ製のツールConfigManagerを使えば可能 |
| ファイル単位のコミット | アーキテクチャに反する |
アーキテクチャに反する |
アーキテクチャに反する |
| リベース／キュー | rebaseコマンド |
Mercurialキュー |
Rebaseプラグイン, Loomプラグイン(Quiltと互換性あり) |
| Webアクセス | |||
| メモ：リポジトリ内のファイルは、HTTP経由でもアクセスできます(読み取りのみ)。 |
メモ：リポジトリ内のファイルは、HTTP経由でもアクセスできます(読み取りのみ)。 |
他の2つに劣っておらず、Smart Serverで高速にアクセス可能。 |
|
| gitweb、wit、cgit | hgweb(単一リポジトリ)、hgwebdir(複数リポジトリ) | webserve、trac、Loggerhead | |
| 統合 | |||
| 統合用の機能 | gitはAPI経由での統合よりもスクリプトが適しています(例え、Ruby/GitのようなフロントエンドAPIがあるとしても)。 |
|
リッチAPI |
| 移行 | グッド。git-svnは、SubversionとGitの間の橋渡しを行う、非常に強力で簡単なコマンドです。既存のSubversionリポジトリ上で、Gitを使えるようになります。 |
グッド。ただ、hgsvnはgit-svnコマンドほど洗練されていません。 |
機能は十分ですが低速です。 |
| 課題管理ツールとの統合 | Tracのバージョン管理システムバックエンドプラグインが利用可能です。Bugzillaは代替方法がありますが、JIRAプラグインはありません。 |
Tracのバージョン管理システムバックエンドプラグインが利用可能ですし、Bugzilla、JIRAとも統合できます。 |
Tracのバージョン管理システムバックエンドプラグインが利用可能です。Bugzillaとも統合できますが、JIRAプラグインはありません。 |
| IDEプラグイン | 開発バージョンあり：Idea、Eclipse、NetBeans。 |
開発バージョンあり：Idea、Eclipse、NetBeans。 |
開発バージョンあり：Idea、Eclipse。プラグインなし：NetBeans。 |
| プラグイン | Emacs／Vim／... |
Emacs／Vim／... |
Emacs／Vim／... |
| パフォーマンス | |||
| gitはこれまで、常に他のツールより高速でした。 |
bzrはこれまで3つのツールの中で最も低速でした。 |
||
| 高度な機能 | |||
| 150以上のコマンドがあり、常に思い描いていたような素晴らしいコマンドがきっと見つかるでしょう(例え、これが複雑さを増大させるとしても)。 |
|||
| 複雑さ | |||
| コラボレーションワークフローの相違や、チーム内のワークフローの進化に適応できますが、Bzrはきれいなユーザインターフェースを保つことで、複雑さを隠そうとしています。 | |||
| リビジョンのネーミング | GitのリビジョンはSHA-1です。2つのリビジョン間の差分をとる時に、あまりユーザフレンドリーではありませんが、安全性の保証やデータの統合、マージの際の衝突を避ける、といった目的のために採用されました。 |
シンプルなネーミング。 |
r1、r2、... といった、シンプルなリビジョンIDでネーミング。 |
| コマンド | 使いやすいです。renameのような特異なコマンドにより、(後方互換性確保のため変更ができない)他のソフトウェア構成管理システムから一線を画しています。利用可能な全てのコマンドとオプションを加味すると、マスターするのが困難ではありますが、コマンドの観点からgitは最も進歩したソフトウェア構成管理システムです。 実際、Gitがきわめて複雑であることを考慮し、Easy Gitのようなツールがあります。 |
使いやすいです(Subversionとそれほど違いがありません)。 |
使いやすいです。 |
| ユーザ基盤 | |||
| 巨大なユーザ基盤／多数の(そして大きな)プロジェクトがgitを使っています(ユーザフィードバックも参照)。 |
巨大なユーザ基盤／多数の(そして大きな)プロジェクトがhgを使っています。 |
マーケットのシェアは最小：Ubuntu、Launchpadといった標準プロジェクトを除き、大きなプロジェクトではまだ使われておらず、まだ有名ではありません。 |
|
| Linux kernel、Cairo、Wine、X.Org、Rails、Rubinius、Compiz Fusion | Xine、OpenJDK、OpenSolaris、NetBeans、Mozillaの一部 | Ubuntuの一部、Launchpad | |
| ドキュメント | ドキュメントは充実しており、manページも優れている(多くの例が含まれています)。 |
ドキュメントは充実しています。 |
ドキュメントは充実しています。 |
| プラットフォーム | |||
| Windowsのサポートが貧弱 |
クロスプラットフォーム |
クロスプラットフォーム |
|
| その他の利点 |
|||
| gitはプラグイン可能というよりもスクリプト可能であり、そこが良いところでも悪いところでもあります(簡単に初められますが、全てのテストをbashスクリプトで行わなければなりません)。 高度な管理のための、非常に柔軟なチューニング：ステージングエリア、遊離オブジェクト、デタッチされたヘッドリビジョン、低レベルなコマンドと高レベルのコマンド、参照ログ。 ローカルブランチ。 |
堅牢なリネーム。 | 堅牢なリネーム。 履歴なしの、軽量なチェックアウトのサポート。 限定ブランチ。 ローカルブランチ。 パッチキューマネージャ(マージを行っているいくつかのブランチを管理します)。 |
|
| 素晴らしいコマンドや拡張機能 |
git-stashコマンド(別のプロジェクトのクイックバグフィックスを保留します)、git-cherry-pickコマンド(完全にブランチするのではなく、あるコミットだけを取り出す)、git-rebaseコマンド(ローカルコミットを前方に移植します。Mercurial QueuesのようなQuiltライクな変更セットです。)。git add -iコマンド(MercurialのRecordExtensionと同等).その他、欲しいと思うようなコマンドのほとんどはgitにあるでしょう。 |
RecordExtension(作業ディレクトリの変更の中から、コミットしたいものを選ぶことができます)。 Hg Shelve Extension(git-stashと同じ：脇に置いておきたい変更を対話的に選ぶことができます。 |
Shelfプラグイン(git-stashと同じように、他のプロジェクトでのクイックバグフィックスを一旦保留します。2007年1月に最新版がリリースされました)。 bzr-dbus (フックやリビジョンのブロードキャスティング用)。 |
| その他の欠点 |
|||
| 名前変更をbzrほどうまく扱えません (テストケース). 読み取り専用のスタティックHTTPのセットアップが少し愚鈍(--bareとupdate-server-info)。 Unicode(UTF-16でエンコードされた)ファイルの取り扱い。 ストレージモデル。Gitは圧縮された差分を単一ファイルに詰め込めるように、新しく作成されたオブジェクトを別のファイルとして保存するため、定期的にパッキング用コマンドを実行することを強制します。 C、Perl、bashスクリプトの混合。他のシステムへの移植性が明らかに乏しい。 |
ローカルブランチができず、代わりにクローンを使わなければいけません。 ディスクスペースの浪費を避けるため、Hgはプルする際にハードリンクを使用します(Windowsでも)。 Forest拡張(サブモジュール)はネイティブでなく、ドキュメントも未整備です。 |
||
| Gui | |||
| Windows | |
TortoiseHg |
込み入っています。TortoiseBzr(2007年8月以来launchpadプロジェクトへの投稿がないですが、プロジェクトは継続しています)、WildcatBZR。 |
| Linux | gitkやgit-gui、tigなど |
TortoiseHg、Hgtk、hgct |
bzr-gtkなど |
| インストール | |||
| cygwinやGit on MSysのようなgitの代替が必要になるでしょう。 |
|
|
|
| 無料のホスティング環境 | |||
| GitHub、gitorious | FreeHg | Launchpad |
 |
| いくつかの統計(2007年のGit調査より) |
この調査では、習熟している言語の選択肢にRubyが入っていませんでした。2008年の調査で追加されるのが楽しみですね。
約1/3の人々が、自分だけ、もしくは他の1人だけとの共同作業のために、分散バージョン管理システムを使っているのも、興味深い点です。
Guis
 |
 |
 |
| gitk(Linux) | TortoiseHg(Windows) | OliveGtk(Linux) |
各GUIはgitkとほぼ同じような機能を持っています。TortoiseHgでフォルダを見る場合、Mozillaのような巨大なリポジトリでは非常に遅くなりました。
パフォーマンスについての限定的な見解
gitはパフォーマンス競争の首位に立っていますが、HgやBzrはこの1年で大きくパフォーマンスを改善してきています。
Mercurialはリポジトリ内のファイル数が2倍になることを覚えておいてください(履歴は.hg/store/data内にファイル毎に保持されます)。NTFSでフォーマットしたWindowsシステム上で使うには、良い選択とは言えないでしょう。
コマンド実行時、gitがシステムコールを活用するのも興味深いところです。HgやBzrはシステムコールにほとんど時間を使っていませんが、Gitはシステムコールに10から40%のCPU時間を使っています。よって、Linuxで使っているパフォーマンス向上のトリックと同様のことができないWindowsシステムで、どうやって実行するのかという疑問が沸いてきます。
単独のマージやマージキューもベンチマークテストすべきです。
ベンチマークはWindowsでも行うべきです。なぜなら
- サーバが*nixでも、多くの開発者はWindows環境で作業しており、処理のほとんどは開発者の環境で行われます。
- パフォーマンスは、Windowsマシンではおそらく全く異なるでしょう。
分散バージョン管理システムをいつ使うか？
体験談
私は、SunのKelly O'Hair氏に、OpenJDKの開発にHgを選択した件について、質問する機会を得ました。
Sebastien Auvray(著者)：TeamWareからMercurialに移行した理由を拝見しましたが、いくつか伺いたいことがあります。単純にOpenSolarisの選択に追随したのですか？
Kelly O'Hair氏：いくつかの点ではイエスです。OpenSolarisの選択は、ツールを変えなければならないSunソフトウェアチームにとって、Sun全体の選択にもなりました。OpenSolarisの調査はとても徹底的でした。そして、彼らには厳しい要件がありました。我々は、OpenJDKで使っているツールを変える必要がありました。なぜなら、TeamWareはオープンソースプロジェクトで使えなかったのです。そこで、Mercurialを使うことにしました。
ツールの比較を行い、他の分散バージョン管理システム(例えばgit)を試してみましたか？
時間の無駄に思えたので、我々は詳細の再調査をしませんでした。私の考えでは、考えられる選択肢としてはgitがありますが、gitは我々が必要としているWindowsへの対応が、まだ十分ではありません。例え再調査したとしても、結果は同じだったでしょう。
OpenSolarisの報告は2006年4月(2年前)のものですが？
わかっていました。gitは進化していたでしょうが、Mercurialもまた進化していましたから。
移行の際、何かトラブルはありましたか？
NFSやUFSファイルシステム経由でリポジトリを共有する際、ファイルのパーミッションと所有者が問題になりました。そこで、我々は最終的に、共有リポジトリを処理するサーバを準備し、簡単にできるようになりました。
他にも、ロールバックのフックや、誰かがうっかりロールバックされた変更をプルしてしまわないよう、プッシュのフィルタを使う時に問題が起こりました。これに対処するため、フック後に自動的に同期する、プッシュ用とプル用のリポジトリのペアを使わなければなりませんでした。
Forest拡張の導入も問題でした。Forestのプッシュは個々のプッシュの集合なのですが、もしあるプッシュが失敗すると、他の全てのプッシュがロールバックして欲しいところですが、そうはなりません。もしForestに属するリポジトリが全く独立していたら、これは大した問題ではないですが。
日々利用するツールとしてはどうですか？
現時点ではまだ分かりません。この種の変更は、ある人にとっては簡単でも、他の人にとっては難しいものです。時間があれば、ほとんどの人は適応し、好きになっていけると私は思います。
"作業セットファイル"('hg update'を行わなければならない)の概念や、ファイルではなく変更セットのマージしなければならないという点は、人々を混乱させています。また、ファイルではなく変更セットをプッシュするという発想は、"なぜこのファイルだけを持ってくることができないのだろう？"とうい疑問を人々に抱かせます。
TeamWareよりも良い点は？
TeamWareに比べて非常に早いです。統合領域のミラーを持つ必要がなくなるので、中国やロシアのチームは、完全に展開されることを心待ちにしています。リフレッシュ(プッシュ)は低速な回線でも、非常に高速で動作します。
部分的なワークスペースを許容するTeamWareと違い、Mercurialのリポジトリの状態は明確です。TeamWareはソースコード管理された個々のファイルを入れるルーズバッグのようなものでした。
TeamWareには、全リポジトリのよく知られたシンプルな状態(シンプルな変更セットID)の概念とともに、変更セットの概念が欠けていました。
TeamWareから移行したことで、使えなくなってしまったものはありますか？
Eメール通知機能とトランザクション履歴のプットバック／ブリングオーバー機能です。しかし、変更セットはそれらの多くを提供してくれます。
リポジトリトランザクション履歴がなくなってしまいましたが、これもMercurialイベントのEメールアーカイブで代用できました。
HgはSunの内部プロジェクトでもバージョン管理システムとして使われているのですか？それとも、オープンなプロジェクトだけで使っているのですか？
理にかなっていれば、内部プロジェクトでも外部プロジェクトでもHgに変更しています。
内部プロジェクトからもかなり注目されているようです。
また、gitについての意見を得るため、VLCのPierre d'Herbemont氏との意見交換を行いました。
Sebastien Auvray(著者)：Gitを使う前に使っていたバージョン管理システムは何ですか？
Pierre d'Herbemont氏：SVNとgit-svnミラーです。
いつ移行したのですか？
VLCがGoogle Summer of Codeのプロジェクトにしやすくなるよう、我々はSVNツリーのgitミラーを公開し、2008年3月の1日と2日で完全にgitに移行しました。
なぜ他のバージョン管理システムではなくGitを選んだのですか？
- SVNよりも優れている点：Gitは高速。ブランチ作成が容易。アトミックなコミット。他のツリーのトップのリベース。
- 他の分散バージョン管理システムより優れている点：実績のあるユーザ基盤(Linuxカーネル)。Wineで使って成功した経験がありました。コアな開発者の数名がGitを利用した経験があり、一方Mercurialなどの経験者はいませんでした。優れているといっても、技術的なことではなく、このような理由です。
移行で何か問題が発生しましたか？日々利用するツールとしてどうですか？
Tracやbuildbotと連携する際に、いくつかトラブルが発生しました。それらのリリースバージョンは、最小限しかGitをサポートしていません。我々は、Buildbotの最新のtrunkをチェックアウトしてくる必要がありました。Tracについては、不十分なGitプラグインを使いました。Trac GitプラグインはTrac 0.11でなければなりませんが、Trac 0.11は安定しておらず、メモリリークすることが知られており、これが0.11への乗り換えを阻んでいます。そのような事情から、我々はそれらが修正されるのを待っています。
コミッタの一部は、Gitに慣れるのにいくらか時間がかかりました。しかし、2日もすれば慣れるようです。今では、Git初心者だった人たちも、Gitを使いこなしています。
結局どうすればよいのか？
分散バージョン管理システムと中央管理型バージョン管理システムの選択は、決して容易ではありません。分散バージョン管理システムは当然、我々利用者に仕事やコラボレーションの方法の変更を迫ります。有力な中央管理型バージョン管理システムのひとつであるSubversionでは、パフォーマンスと機能の戦いがまだ終わっておらず、バージョン1.5でよい妥協点を見つけ出すべきです。Subversionの既存のユーザ基盤や(いくらか犠牲を払わないといけないところはあるが)シンプルさは頼りになります。巨大なバイナリファイルを扱うようなケースでは、分散バージョン管理システムよりも、クライアント側のディスクスペース消費量が一定であるSubversionの方が適しています。部分チェックアウトを多用する場合も、svnが適しています(ただ、大量に使うと、モジュール設定の問題にさらされます)。
一旦分散管理か中央集中管理かを選択しても、実装やコマンドの観点から競合製品を比較するのは困難ですし、パフォーマンスも大きな違いがあります。さらに、一般的な操作の本当に正しいベンチマークはありません。
この激しい戦いの中、最初の頃パフォーマンスが悪かったため、Bazaarは周囲に影響を与える多くの早期採用者(MozillaやSolaris、OpenJDK)を失いました。また、競合製品との違いについて正しくない情報を公開したり、競合製品とのディスクスペースの効率のベンチマークの比較だけを公開し、日常的に使用するdiffやaddなどの処理時間に関するベンチマークの比較が公開されていないことなどから、BazaarのWebサイトは非常にマーケット指向だとも言われています。
今回取り上げた3つのプロジェクトは、ほぼ同時期に始まりましたが、bzrは開発初期段階で非常に多くのパフォーマンスや設計の問題に直面しました。そのため、現在のところ、競合製品に比べて成熟していないように私は感じます。
また、バージョン管理システムの選択はコミュニティで使われている言語に依存しているようです。JavaやSun関連の開発はMercurialを使う傾向があり、C、Linux、Ruby、Rails関連のプロジェクトはgitを使う傾向があるように思います。
あなたの経験やこの記事についてのフィードバックは、常に歓迎しています。
クレジット
インタビューを快く受けてくれた人々：Kelly O'Hair氏、Pierre d'Herbemont氏
Ian Clatworthy氏。MozillaがHgからBzrに変更したことについて教えてもらいました。
Freenode IRCの#git、#mercurial、#bzr。Mozilla IRCの#mozilla。
Antonio Juezが投稿した写真。
無作為な引用
Linus Torvald氏："Subversionは最も無意味なプロジェクトです。" "もしCVSを使うのが好きなら、精神病院かどこかに入るべきです。"
Mark Shuttleworth氏(Ubuntu / Canonical Ltd.)： "マージはソフトウェア開発者間のコラボレーションの鍵。"
Ian Clatworthy氏(Canonical / Bazaar)："2011年から2012年には、この技術は広く受け入れられ、多くのチームはかつてこれなしでどうやって管理していたのか、不思議に思うほどになるだろうと予測しています。"
趣味と実益のためのGitフォークのAssaf Arkin氏："Apacheは多くの努力を費やし、SVN周りの素晴らしいインフラを構築しました。最初、私はそれで全てが片付くような気がしましたが、SVNよりソーシャルなGitを理解してからは、そう思わなくなりました。"
この記事へのコメントや、Ian Clatworthy氏とreedit氏からの意見により、2008年5月12日にこの記事を更新しました
- BzrプラグインとWindows GUIを追加：rebaseプラグインなどと、Wildcat BZRなど。
- Hg Shelveを追加。
- Hgのコード行数を更新 (HTMLドキュメントもカウントされていた)。
- gitのリポジトリサイズを、適切にrepackコマンドを実行(サイズが一定になるまで
git repack -a -f -d --window=100 --depth=100を実行)した後の値に更新。
お詫び
darcsやMonotoneは、今回の比較では取り上げませんでした。この記事で取り上げた分散バージョン管理システムについての情報を集め、これらの３つの分散バージョン管理システムの比較テストをするだけでも大変な作業だったからです。奇妙なことに、darcsやMonotoneは最古の分散バージョン管理システムですが、私がここでレビューしたものの方がより注目されています(ですが、darcs、Monotoneのユーザや開発者がコメントや宣伝をここに投稿してくれることを歓迎しています！)。
参照
GitについてのWikipediaのページ(非常に多くの情報を網羅しています)。
Wikipediaの分散リビジョン管理に関するページ。
Wikipediaのリビジョン管理ソフトウェアの比較に関するページ。
分散バージョン管理 - なぜ？どうやって？(Ian Clatworthy氏、Canonical (Bazaar))。
図解 分散バージョン管理入門(Kalid Azad氏)。
分散バージョン管理システム(Dave Dribin氏、彼は最終的にMercurialを選択したようです)。
なぜ分散バージョン管理か(Wincent Colaiuta氏)。
OpenSolarisのソースコード管理、OpenSolarisのソフトウェア構成管理の歴史(2005)。
OpenJDKへのMercurialについての質問(Kelly O'Hair氏、Sun）。
私がgitを選んだ理由(Aristotle Pagaltzis氏)。
分散ソフトウェア構成管理(Gnomeプロジェクトチーム)。
FreeBSDのソフトウェア構成管理要件。
Open Officeの要件。
Mozillaのバージョン管理システム要件。
Mercurialを使おう！(Ian Dees氏)。
分散バージョン管理システムが与えてくれるもの(Bill de hÓra氏)。
MercurialとGitの違い。
この記事では、ここで挙げたURLを全て参考にさせていただきました。
チートシート
Gitチートシート
Mercurialチートシート
Bazaarクイックスタートガイド
ベンチマークの条件。
ベンチマークテストはプロセッサがADM Athlon(tm) 64 3500+、メモリが1GB RAMのマシンで行いました。OSはLinux Kubuntu 6.10 Edgy x86_64、ファイルシステムはext3です。
各コマンドは8回実行しました(そして、最も良かったものと最も悪かったものを除外しました)。なお、コマンドはファイルシステム経由でローカルに実行しました(ネットワーク通信の実装が適切でなければ、パフォーマンスを低下させるので、たとえ分散バージョン管理システムが中央サーバと連携していなくても、他のプロトコルテストは当然行うべきです)。
使用したバージョン
- 2008年3月24日にリリースされたMercurial 1.0(Edgy用のIssue 1050パッチを適用)
- 2008年4月8日にリリースされたGit 1.5.5
- 2008年4月10日にリリースされたBazaar 1.3.1
リポジトリにはMozillaリポジトリの約30000ファイルからなる、12456の変更セットのスナップショットが存在しています(2008年3月3日の、hgリポジトリから取り出した70853のリビジョン)。もともとはhgフォーマットだったので、hg-fast-export.shを使ってgitフォーマットに、hg-fast-export.shとbazaarのfast-importプラグインを使ってbazaarフォーマットに変換しました。
デフォルトのファイルフォーマットを使い、gitリポジトリのサイズはgit-gcを実行したままにしました。1年半前にJst氏が行ったベンチマークテストと同じように、１つのファイル(dom/src/base/nsDOMClassInfo.cpp)を修正しました。
著者について
Sébastien Auvrayはシニアソフトウェアデザイナであり、技術狂です。CVSやsvnを使わされ、今は仕事で日々Perforceを使わなければいけないことに苦痛を感じています。SébastienはInfoQのRuby関連の編集者の一人でもあります。