Team Foundation バージョン管理から Git に移行するための旅路 (3)
免責事項
この文書は技術文書ではない。私の思い出話や蘊蓄を多分に含んだ内容であり、とても冗長である。 また、正確性にも欠ける点があるかもしれないし、この資料を作るために時間を掛けて検証したりなどはしていない。 読者は、そういう文章であるという点を十分理解した上で、読んでほしい。
本ドキュメントは読者の参考になればと思って書いてはいるが、本文書の内容によって生じた一切について責任を負わない。 すべて "At your own risk" である。
はじめに
今回は Team Foundation バージョン管理のワークスペースについて話す。
これは完全に私の私感であるが、Team Foundation Server 2012 Update 2 で Git をサポートした当時、Team Foundation Server の開発チームは現在のデファクト スタンダードの状態まで Git がなるとは思わなかったのではないか、と想像している。
というのも、Git がリリースされた当時、製品責任者である Brian Harry によって 「Git と Team Foundation バージョン管理 (TFVC) は同様に扱う」 とアナウンスされていたからだ。
が、その後状況は変わる。世の中は急激に Git にシフトし、開発者は GitHub を OSS 開発の基盤として利用し、マイクロソフトは GitHub をマイクロソフト ファミリーの一部にした。最終的に、Visual Studio の次期バージョン開発では "Git first" として、Git 前提の機能が増えて行くのである。
実は、Team Foundation Server 2012 では Team Foundation バージョン管理に対して、Git のトレンドを見て導入した新機能が追加されている。 それが今回話す「ローカル ワークスペース」である。
（他にも .gitignore から影響をうけた .tfignore もあるが、今回は含まない）
ローカル ワークスペースとサーバー ワークスペース
ローカル ワークスペースは、Team Foundation Server 2012 で追加された機能である。 私の偏見が大分入っていると思って聞いてほしいが、Git のような分散バージョン管理のトレンドを Team Foundation バージョン管理を使うユーザーにも提供しようという思惑から実装された機能と思われる。
実は、Team Foundation Server 2012 の既定ではローカル ワークスペースとなっており、知らぬうちにローカル ワークスペースを使っていた、ということもよくある。
まずは、この Team Foundation Server 2012 で追加されたローカル ワークスペースと、それ以前から存在しているサーバー ワークスペースの違いについて話そう。
サーバー ワークスペース
サーバー ワークスペースは、各クライアントのワークスペースをサーバー側で保持する、という方式である。ワークスペースには、マシン、ユーザー、マッピングするフォルダー（サーバーのどのパスをローカルのどこに保持するか）といった情報が管理されており、内部的にはどのファイルをいつ取得したのか、といった情報まで記録されている。
一方、これにはいくつかの問題があった。当時、言われていた問題は下記のようなモノがある。
- パフォーマンスが悪い
- オフライン時に開発ができない
前者は、サーバー側で管理をするため、ファイル数が膨大になると処理時間がかかるというもの。後者は、何かをする度にサーバーアクセスが必須となるため、オフライン時に開発作業ができなくなるというものである。
ローカル ワークスペース
ローカル ワークスペースは、これまでサーバー側で管理してきたワークスペース情報の一部をローカル側で保持する方式である。 たとえば、サーバー ワークスペースの場合、ローカルファイルを編集したい場合は、サーバーに対してチェックアウト要求を行い修正を開始する。また、ファイルを元に戻すのにもサーバーのアクセスを必要とする。
一方、ローカル ワークスペースの場合は、チェックアウト時にサーバーへの要求は不要で、未変更時のファイルをキャッシュとして内部保持するため、変更前に戻す、変更前との比較もサーバーアクセスなしに実現できるのである。
また、オフラインモードにも対応しており、飛行機による移動中などインターネット アクセスが難しい場所であっても、ローカル ワークスペースに保持されている情報の範囲で編集作業が続行できる。
とても便利な機能であり、だからこそ既定になっているのだが、実はローカル ワークスペースによって失われた重大な機能がある。 それが、「チェックアウト ロック」である。
チェックアウト ロック
チェックアウト ロックは、特に Visaul Source Safe ユーザーから愛された機能であり、この機能があったからこそ Subversion などの他のバージョン管理ではなく、Team Foundation Server に移行した、という人もいたことだろう。
実は、Team Foundation バージョン管理では、ロックに２種類が存在し、一つが「チェックアウト ロック（悲観的ロック）」、もう一つが「チェックイン ロック（楽観的ロック）」である。
悲観的ロックと言われているチェックアウト ロックのイメージは「私が編集している間に他の人がファイルを触ると怖いので、誰もチェックアウトさせないぞ！」というものである。一方、楽観的ロックであるチェックイン ロックは「私が編集している間に触られても良いけど、私が先にチェックインするよ！（競合するのはそっちだぞ）まぁ、競合したときは、そのときで！」という感じである。
さて、お気づきだろうか？チェックアウト ロックを実現するためには、ファイルが編集されようとする（チェックアウトする）度に、サーバーにアクセスし、ロックされているかどうかを検証する必要がある。
つまり、ローカル ワークスペースのように、ローカル内のファイル修正時にサーバー アクセスが行われないケースでは、チェックアウト ロックは動作しないのである。 実際、これはローカル ワークスペースの制限事項になっており、一部のユーザーはこの機能のためにサーバー ワークスペースを現在も使っているという人もいると思う。
おわりに
さて、長くなってきたので今回はここで終わりにしたい。 ワークスペースの動きの違いから、チェックアウト ロックの話をしたところで、きっとあなたはこう思ったハズだ。「仕組みの話からして、Git ではチェックアウト ロックは使えないんですよね」と。実は方法が無いわけではない（二重否定）。
というわけで次回は、Git を機能拡張する話をしよう。 では、また次回。
(おまけ)
実は、記事をためておいて、時間投稿機能を使って段階的に公開させるはずが、設定ミスで全部公開してしまった。（1, 1.5, 2 が同時公開されたのはそれが理由である） 今後は定期的 (?) に投稿されるはずなので、焦らず待ってほしい。
