Facebook の Mercurial に対する本気度まとめ

Facebook のエンジニアブログで "Scaling Mercurial at Facebook" と題するエントリが 2014-01-07 に公開され、大きな注目を集めました。

また、このブログエントリについて解説した InfoQ の記事 "Facebook makes Mercurial faster than Git" や、その翻訳 "Facebook、MercurialをGitよりも速くする" も、多くの人がリツイートするなどして話題にしています。

このエントリでは、上記の記事では触れていない、Facebook の Mercurial への本気具合について、まとめてみました。

人的関与

Facebook は Mercurial の主要開発者を何人も雇用しています。最も顕著な例が、Mercurial プロジェクトのリーダーである Matt Mackall 氏その人の雇用でしょうか。

以下、私の把握できている範囲で Facebook が雇用している（＝ "@fb.com" 名義を使用したことのある）主要開発者を何人か紹介します。
ちなみに、Git のメンテナである濱野純氏も現在 Google に勤務していたりします。当代の代表的な大規模サービス提供企業である Google と Facebook が、分散履歴管理ツールプロジェクトのトップを揃って抱え込んでいるというのは、なかなか面白いですね。

● Bryan O'Sullivan

"Real World Haskell" ã‚„ "Mercurial: The Definitive Guide" の執筆でも知られる Bryan O'Sullivan 氏は、以前の勤務先で BitKeeper を使用する必要があったため、コア機能の開発に関与できずにいた時期もありますが、トータルで 600 件近いコミット実績を持つ、最古参の Mercurial コアメンバーの一人です。

Facebook の肩書での約 240 件のコミット実績は、Facebook 社員による 500 件超のコミット実績の、半数近くを占めることになりますね。

● Pierre-Yves David

Pierre-Yves David 氏は、メインリポジトリへのコミット権を持つ Crew メンバーでこそありませんが、obsolete 機能実装の主導や、540 件近いコミット実績など、主要開発者の一人と言って差し支えないでしょう。

Facebook の肩書でのコミット数は 2014-01 以降の数件みたいですので、ひょっとしたら最近になって Facebook に転職したのかもしれません。

コード関与

Facebook 社員（＝ "@fb.com" 名義のユーザ）の手によるパッチの採用状況は、以下の要領で確認することができます。

$ hg log -r "author('@fb.com') and not merge()"

一覧表示するなら、--template "{author|email} {node|short}: {desc|firstline}\n" 指定を追加した方が良いかもしれませんね。

2.9-rc 時点のリポジトリ上では、Facebook 社員による変更件数は 543 件でした（件のブログエントリを公開している Durham Goode 氏のコミットも 64 件ありました）。

Matt Mackall 氏は Facebook に勤務する現在でも "Matt Mackall <[email protected]>" 名義を使用していますので、実質的には件のブログエントリでの "over 500 patches" 以上の関与があることになりますね。

件のブログエントリでは、500以上の修正コードの貢献例として、新しいグラフアルゴリズムã‚„Cによるコードの書き直しを上げていますが、ある程度まとまった量の変更として、以下のような機能追加の貢献もあります。

● 並列 update

Mercurial 2.6 から提供されるようになった並列 update 機能を実現している worker.py は、"Facebook, Inc." の Copyright 付きのコードです。

Facebook 社員による件のブログエントリでは、「status の性能向上」や「clone と pull の性能向上」について言及されていますが、大量のファイルを扱う大規模リポジトリ上の場合、特定リビジョン時点の内容を取り出す update 処理の応答性も、対話的実行におけるユーザ利便性の点では無視できません。

並列 update 対応の Mercurial を、複数の CPU が利用できる環境*1で使用した場合:

1. update によって更新（変更／追加）が必要なファイルの一覧を作成
2. 一覧を利用可能 CPU 数で分割
3. 各 CPU 毎に、担当ファイルの更新作業を並列実行

上記の手順で update 処理が並列化されます。

多くの場合、作業領域全体が同一デバイス上に記録されているでしょうから、並列度合を上げても、性能向上は一定レベルで頭打ちとなる可能性もあります。

しかし昨今では以下のような状況になっていますので、並列 update の効果は、思った以上に大きいかもしれませんね。

• SSD の普及により、ランダムアクセス I/O による性能劣化が、回転媒体ベースの HDD 程ではない
• 大量メモリの搭載により、OS レベルのキャッシュ／遅延書き出しが効くことで、媒体との I/O による性能劣化が低減

ちなみに、Python の履歴管理ツール選定での評価の時点では、git checkout よりも hg update の方が性能面で有利と判定されていますが、それでも桁外れに大量のファイルを扱うリポジトリでは、ちょっとしたことで、ユーザの体感速度は簡単に劣化してしまいます。

並列 update 機能には、利便性向上のための性能改善に対する執念を感じます。

● 同梱版 shelve エクステンション

これまでは、"git stash" 相当の機能を実現するには、サードパーティ製の shelve エクステンションを入手する必要がありましたが、Mercurial 2.8 からは shelve エクステンションが同梱されるようになりました。

この同梱版 shelve エクステンションは、"Facebook, Inc." の Copyright 付きのコードです。

ちなみに、サードパーティ製の shelve と同梱版のそれは、機能の実現方式が全く異なります。両者の差異に関しては別のエントリで解説していますので、そちらを参照してください。

Facebook 由来の shelve が同梱対象に選定されたのは、衝突発生時に 3-way マージによる解消が可能な点が、パッチベースのサードパーティ製 shelve よりも好まれたのだと思われます。

*1:但しUNIX系環境のみ