Gitは多くの場面において最良のバージョン管理ソフトウェアと考えられていて，広く採用されているものの，完璧というには程遠い。サードパーティ製のツールで解決できる問題もあるが，リポジトリ全体が開発者のマシンにコピーされるという方法が致命的な場合もある。Microsoftは300GBのリポジトリを社内システムからGitに移行しようとして，この問題の所在に気が付いた。その結果として生み出されたのがGit Virtual File System (GVFS)だ。
物語の始まりは2000年頃に遡る。当時Microsoftでは，社内システムとして，Perforceのフォークである“Source Depot”を中心的に使用していた。時間が経つにつれ，多くのチームがTeam Foundation Server(TFS)独自のバージョン管理システムであるTFVCに移行したが，大規模な開発チームは，作業量の理由からSource Depotからの移行を果たせないでいた。その上，大部分のチームがTFSのパーツを使用してはいたものの，そのパーツもチーム毎にさまざまで，サードパーティや社内開発ツールが入り交じった状態だった。
この複雑な環境を簡素化する取り組みとしてMicorosftは，大部分のチームを対象に，Visual Studio Team Service(クラウド版TFSの別名)関連によって作業計画やビルド自動化，ソース管理を標準化する決定をした。そのソース管理に使用するのが，Gitを使ったVSTSだったのだ。
なぜGitなのか？Microsoftに籍を置くredditユーザのjeremyepling によると，それには3つの理由がある。
GitとGitHub公開リポジトリはOSS開発のデファクトスタンダードです。MicrosoftはOSS開発を多く手掛けているので，TFSやTeam Servicesといった自社のDevOpsツールを，これらのワークフローと親和性を持ったものにしたいと考えています。
私たちは，Microsoft全体で使用する統一的なバージョン管理システムを求めています。標準化することで，メンバがプロジェクト間を容易に移動できるようになると同時に，専門知識を深めることが可能になるからです。OSSはGitに結び付いていて，私たちはOSS開発を多く手掛けているのですから，最初に候補となるのはGitです。
私たちはコミュニティと当社ユーザの方向性を認識し，それをサポートしたいと思っています。Gitが現在のバージョン管理システムの代表的存在であることは疑いありません。
しかしBrian Harry氏が説明するように，それにはいくつかの問題がある。
Gitの選択に反対する意見はたくさんありましたが，最も具体的なものはスケールでした。当社ほど大規模なコードベースを持つ企業は多くありません。WindowsとOfficeは特に大規模で(他にもありますが)，数千人のエンジニア，数百万のファイル，数千台のビルドマシンが常に稼働しています – 率直に言って，気が遠くなります。ここで明確にしておきますが，この記事でWindowsと言う場合，実際には非常に広い範囲 – PC用，モバイル用，サーバ用，HoloLens用，Xbox用などを指しています。Gitは分散型のバージョン管理システム(DVCS)なので，リポジトリ全体とヒストリのすべてをローカルマシンにコピーします。Windowsのソースでそれをするのは冗談のような話です(私たちはたくさん笑わせてもらいました)。 TFVCとSource Depotは，どちらも大規模なコードベースとチームを考慮して，綿密な最適化が行われています。Gitはこれまで，これほどの規模で(あるいは多分，これよりも小さな規模でも)適用されたことは「一度も」ありませんし，多くの人たちが「絶対に」うまく行かないだろうと断言しています。
RedditユーザのRuud-v-Aが参考情報をいくつか提供している。
Linuxカーネルのリポジトリは1.2GBで，ほぼ12年分のヒストリと57,000のファイルがあります。2005年の最初のコミットには，インポートされたヒストリ全体は3.2GBだと記されています。57,000ファイルの合計が4.4GBですから，350万ファイルならば270GBになる計算です。
Chromiumのリポジトリ(2001年以降のWebkitのヒストリを含む)のサイズは11GBで，ファイルの数は246,000です。これを20年間と350万ファイルに換算すれば196GBということになります。
Windowsリポジトリを適当なサブリポジトリに分割する方法は，実際には実現不可能だった。最初からそのように計画してあれば可能だっただろうが，コードベースのサイズと歴史が積み重ねられた今となっては，元に戻って分割するという作業はとても耐えられるものではないのだ。Harry氏は続ける。
そのために私たちは，数百万のファイル，数百ギガバイト，数千人の開発者が使用するコードベースで動作するように，Gitスケールアップせざるを得なくなりました。参考までに言うと，Source DepotでもWindowsコードベース全体までスケールアップすることはできなかったため，スケールアウトできるように40以上のデポに分割した上で，その上にひとつのレイヤを設けて，大部分のユースケースでひとつとして扱えるようにしていました。この抽象化は完全ではなく，いくつかの軋轢を起こしていたことは否めません。
なぜヒストリをダンプした上で，最初からやり直さなかったのだろう？SuperImaginativeNameがその理由を説明する。
NTカーネルとそのドライバ，サブシステム，API，ハードウェアドライバ，Win32 API，これらはすべてユーザを含む他システムによって参照されています。30年以上たったアプリケーションが変わらずWindows上で動作するのはなぜだと思いますか？ヒストリがなければ，例えば15年前，ISAにユーザのアプリケーションの正常実行を阻害するようなシリコンバグがあったために，特定のCPUに対してある特定のフラグをセットしていたことについて，カーネルチームが記憶しているはずがありません。ヒストリを削除したが最後，蓄積された膨大な量の知識が失われてしまうのです。 すべての開発者に対して，あるシステムがどのように動作しているのか記憶していると期待することはできません。正しくないように見えて，実際にはファイルの破損を防いでいるという，不可解なコードに気付いた場合を想像してみてください。ヒストリがないがために，“変なバグを修正，これまで誰も気付かなかったのが不思議だ”，というコミットが新たに加えられたとすれば，災難以外の何でもありません。コードのヒストリと比較して初めて，実はそれが正しい，ということが分かるのです。Windowsは単なるバイト列ではなく，すべてが監査されているのです。
Gitのサブモジュールの利用などで何度かの失敗を重ねた後，MicrosoftはGit Virtual File Systemの開発に着手した。
私たちはGitを“仮想化”するアプローチを試しました。Gitは通常，クローン時に“すべて”をダウンロードします。ですが，もしもそれをしなかったら？ストレージをGitの下で仮想化して，必要なものだけをダウンロードするようにしたらどうでしょう？300GBの巨大リポジトリのクローンがずっと速くなるはずです。Gitコマンドやワークファイルの読み込み/書き込みを実行すると，システムがクラウドからコンテンツをシームレスにフェッチします(同時にローカルに保存して，以降のアクセスはすべてローカルで行われるようにします)。この方法の欠点は，オフラインサポートが失われることです。それが必要であれば，すべてのファイルに“タッチ”して，ローカルに確保しておく必要がありますが，それ以外に失うものはありません – 依然として100%忠実なGitエクスペリエンスを手にすることができるのです。私たちの巨大なコードベースに関しては，まったく問題ありませんでした。
Saeed Noursalehiがこれに付け加える。
GVFSを使うということは，はるかに管理の容易なGitエクスペリエンスが手に入るという意味でもあります – cloneの時間は12時間以上から数分に，checkoutは2～3時間から30秒に，statusは10分から4～5秒になります。私たちはこれらの数字をもっとよくすることに取り組んでいます(当然ながらそのトレードオフとして，ビルドに使用するファイルをダウンロードしなくてはならない最初のビルド時間は多少長くなります。ただし2回目以降については，通常より遅いことはありません)。
MicrosoftのGitへの投資
これが正しく動作するためには，Gitのファイルアクセス方法を改善する必要があった。ローカルに保持するリポジトリでは通常問題にはならないが，以前のバージョンのGitは，厳密に必要である以上のファイルをスキャンすることがあった。Microsoftが昨年，Git OSSプロジェクトにパフォーマンス強化を提案したことをご存知ならば，これがその理由だ。
Jeremyeplingは次のように書いている。
私たち – Microsoft Gitチーム – は事実，linux，mac，windows上でのパフォーマンスを改善するために，git/gitおよびgit-for-windowsに多数のコントリビューションを提供しています。git 2.10では，インタラクティブなrebaseを高速化するために，多くの作業を行ないました。最終的にインタラクティブなrebaseは，Gitのソースコードに含まれるベンチマークによると，Windows上で最大5倍，MacOSXで最大4倍，LInuxでも最大3倍，高速に動作します。
Gitの機能強化の一部を以下に示す。
- sha1: mingwのopenssl sha1ルーチンを使用 https://github.com/git-for-windows/git/pull/915
- preload-index: アイテムのskip-worktree時のlstat実行を防止する https://github.com/git-for-windows/git/pull/955
- memihashのパフォーマンス向上 https://github.com/git-for-windows/git/pull/964
- add: preload-index とfscacheによるパフォーマンス向上 https://github.com/git-for-windows/git/pull/971
- read-cache: verify_hdr()をバックグラウンドスレッドで実行 https://github.com/git-for-windows/git/pull/978
- read-cache: チェックアウト時のadd_index_entryの速度向上 https://github.com/git-for-windows/git/pull/988
- string-list: string_listの再割り当てにALLOC_GROWを使用 https://github.com/git-for-windows/git/pull/991
- diffcore-rename: register_rename_srcの速度向上 https://github.com/git-for-windows/git/pull/996
- fscache: not-foundディレクトリキャッシュをfscacheに追加 https://github.com/git-for-windows/git/pull/994
Git Virtual File System
Git Virtual File System (GVFS)のプロトタイプはクライアント側で，ファイルシステムドライバとGVFS対応バージョンのgitとして実装されている。実行には“Windows 10 Anniversary Update”以降が必要だ。GitリポジトリがGVFSでセットアップされた後は，一般的なgitコマンドが通常通り動作する。GVFSサブシステムはファイルシステムの下に位置し，必要なファイルをバックグラウンドでサーバからダウンロードする。
GVFSクライアントはオープンソースなので，Windowsで仮想ファイルシステムがドライバとしてどのように実装されているかを知る，よい機会でもある。
サーバ側は，何らかの形でGVFSプロトコルを実装する必要がある。現時点でそれはVisual Studio Team Servicesを意味するが，プロトコルはオープンソースなので，他のベンダが同じ機能を提供することは可能だ。GVFSプロトコル自体は４つのREST風エンドポイントからなる，非常にシンプルなものだ。
この記事を評価
- 編集者評
- 編集長アクション