Microsoft Officeが長年使ったSource DepotからGitへ移行！開発現場に変化が
引用元：https://news.ycombinator.com/item?id=44253212
この記事はOfficeのGit移行っていう古い話の新しい語り直しだね。GitはVFSがないとOfficeみたいなリポジトリをgetするのに何時間もかかったって悪く言ってるけど、そんな操作はVFS（VFS for Git）で新しいファイルシステム作らないと実質不可能だったって事実をすっ飛ばしてるよ。Perforceは必要な部分だけチェックアウトできたから、SDのユーザーもOfficeスイート全部じゃなくて必要なアプリだけ取ってたと思う。VFSは「必要な時だけオブジェクトをダウンロードする」って感じで、その差を埋めてるね。PerforceやSDは当時の集中型VCSとしては素晴らしかったけど、時代は変わったってことかな。
ウチの会社もまだ Perforce 使ってるけど、この時点でもう誰も好きじゃないって感じだね。世の中 Git なのにウチは違うって言うと、新卒の子たちの目が死ぬのがわかるよ。
新卒がバージョン管理ソフトの選択でイライラするなんて信じられないなぁ。たくさんのハードルを超えて新しい会社に入ったんだから、そこのやり方やツールに対してオープンマインドでいるのは当然でしょ。
Discordはコミュニティとかネットワーク効果を考えればわかるけど、Bitbucket？コストを節約したいCTO以外でBitbucketを好む理由が全く分からないんだけど。
ウチの職場はBitBucketを使ってるよ。特定の輸出規制があって、知財を含むサービスはできるだけオンプレミスにしたいから、BitBucket Serverなんだ。他にも選択肢はあるけど、クラウドのソリューションは全部無理だったんだ。
やり方やツールに対してはオープンマインドなつもりなんだけど、今の時代Git以外のツールを使ってる会社は、よっぽどちゃんとした理由がない限り、VCSシステムを比較検討してGit以外を選んだんじゃなくて、レガシーなプロセスを最新化するパワーや政治的な意思がないってことの表れに感じちゃうんだよね。
うん、確かに新卒の開発者にとっては問題だね。記事でも「業界で使えるスキルが増えて多くの人がスッキリした。オンボーディング時間も半分になった」って言ってるしね。
一部の会社はPerforce用にVFSみたいな独自技術を開発してるんだ。Office全体をチェックアウトしても、特定のアクセスを試みる時にだけファイルを引っ張ってくる方式。これはテキストファイルと一緒に巨大なバイナリ資産を置くゲーム開発ですごく重要なんだ。Windowsに内蔵されてるリモートドライブのプログラムが使ってる技術と同じだよ。個人的には履歴を全部ローカルに持たなくていいサーバーベースのVCSもちょっと欲しいけど、でもGitのstashとかstage hunksとかinteractive rebaseとかの機能が、自分の作業スタイルに合ってて手放せないんだよね。
オンボーディングにそんなに時間がかかったのが意外だね。
Source Depotが特別変だったのか、Microsoftの使い方がすごく複雑にしてたのかも。
Perforceは使うのが難しいと感じたことないし、プログラマーは全然困ってないみたい。
アーティストやデザイナーも結構すぐに慣れてたよ。（Gitの面倒なやり方（git style of shit）に我慢する習慣がない点で、プログラマーとは大違いだけどね。）
SVNって、プロジェクトの好きな深さのフォルダやファイルだけチェックアウトしてコミットできたっけ？
チェックアウトやコミットはともかく、特定のサブツリーのログ履歴が見れたのはSVNのツールで懐かしいな。
初めての職場で6ヶ月経ってからSVNからGitに移行した時、嬉しくて泣きそうになったよ。
最初の数週間は気にしないだろうけど、1ヶ月もすればその辛さがわかるはず。
「git style of shit」ってフレーズが分からないな。
もっと詳しく説明してくれる？
GitがGitツリーの特定の場所だけチェックアウトする方法を提供してないのは、ちょっと驚きだな。
オブジェクトファイルを理解する中間サービスを使えば結構簡単にできそうな気がするんだけど。
Perforceは使ったことないから何も言えないけど、職場でGitの代わりにGoogleのPiperが欲しいな。
左の睾丸と引き換えにしてもいいくらい！
Microsoftみたいな有名な場所に来て、ひどく時代遅れのソフトを使う羽目になるのは問題だね。
Excelにいた時は、Script＃からTypeScriptへの移行、SourceDepotからGitへの移行、短い開発サイクル、良いツールなど、かなり改善したことに拍手を送りたい。
開発時間の大部分は開発者向けのツールや満足度に使われたよ。
でも、古い場所にまた行ってSourceDepotや「変更を行う」ツールであるosubmitを使うのは本当に最悪だったね。
ハッピーパスでもパッチをレビューのために提出するのに16回もポップアップが出たりさ。
（変なWindows GUIレビューツールでもやってたし）
Gitはかなりの改善だったよ！:D
「新入社員がバージョン管理ソフトの選択に腹を立てるなんて信じられない」って？
腹を立てるよ、もしバージョン管理ソフトが基準に達してないならね。
Mercurial/hgを使ったことがなくても全然気にしなかったし、むしろ今ではGitより好きだよ、実際すごく良いから。
Gitもほとんどの人が慣れてる decentな選択肢だし、これで腹を立てることもないでしょ。
その一方で、Source Depotはひどかったね。
ずっと戦ってる感じだったよ。
慣れてきたら、余計嫌いになったんだ。
新しい人が入ってきたとき、そのツールがhgとかSource Depotに似てるか分かんないんだよ。
だから判断は保留すべきだね。
git log my/subfolder/でサブフォルダのログ履歴って見れるんじゃない？
TortoiseGitみたいなツールなら右クリックで見れるよ。
それ、前からあるじゃん。
Partial clonesとかLFSだよ。
https://git-scm.com/docs/partial-clone
SVNからgitになった時、嬉し泣きしたって話、マジ懐かしい！
RCS/CVSからSVN、そしてGitへって経験、すごく分かるよ。
Gitのコマンドは変だけど、昔よりずっとマシになった。
Gitに貢献した人たち、本当にありがとう！
Bazelはバージョン管理ツールじゃないからね。
なんでGitLabとかGitHubのオンプレサーバー使わないの？
新しい人だと、Gitじゃないツールを使う理由があるか分かんないんだよね。
レガシーでもいいツールもあるかもだし。
モダン化のためにモダン化するのはJSの世界みたいでちょっと変だよ。
Gitって典型的なUnixツールだけど、使いにくいよね。
コマンド分かりにくいし、内部を知らないとダメ。
エラーも多い。
GUIもあるけど、使うと文句言われるし、絵とかマージできないファイルは苦手。
プログラマー以外にはもっと大変だよ。
でも、それらってすごくお金かかるんだよ！
職人っていい道具をありがたがるよね。
2016年のMicrosoftインターン中、Source Depotが何かも分からず automated code reviewer にSource Depot対応を追加するのに一週間近くかけたよ（https://austinhenley.com/blog/featurestheywanted.html）。
当時でもまだかなり多くの開発者が使ってたんだ。
もう全部gitに移行したのかな。
いやいや、まだいっぱいsdで動いてるって！！
あのsdコマンドとか設定とか、マジでゾッとするね！！
CodeFlowが毎日恋しいな。
あれは本当に最高のツールだったのに。
CodeFlowはまだ生きてるし、評価高いよ。
GitHubリポジトリもサポートしてるんだ、gitだけじゃなくてね。
https://chromewebstore.google.com/detail/codeflow/aphnoipoco…
ただ、まだ社内向けとして buried されてるけどね。
もっとコメントを表示（1）
今は日々のほとんどはgitでやってるよ。
90年代にvssを使ったことあるから、全然言及されてないのが意外だったよ。
VSS（Visual SourceSafe）はMicrosoft独自のバージョン管理システムだったけど、Source DepotはPerforceからライセンスされてたんだよね。
VSSはRaleighのOne Tree Software買収で手に入れたんだ。
彼らの製品がSourceSafeで、Visualって部分は他の開発ツールと一緒にバンドルされた時に付いたんだって。
その前はMicrosoft Deltaってクソ高くて酷くてNTに対応してないバージョン管理製品を売ってた。
買収でMicrosoftに入った一人にBrian Harryがいて、彼がTFVC（Team Foundation Serverの一部）の開発を率いたんだ。
あれはストレージにSQL Serverを使ってて、VSSより管理も信頼性も格段に向上した。
Brianはもう引退したと思うけど。
VSS使ってた頃、SMB経由のネットワークファイルロックが破損の大きな原因だった気がするな。
ネットワークがちょっと不安定だとリポジトリを修復しなきゃいけなかったんだ。
朝には使えるように、夜間に修復バッチジョブを走らせてたよ。
＞ …SMB経由のネットワークファイルロックが破損の大きな原因だった気がする…
SMBで共有データベースファイル（どんな種類でも）とか…ゾッとする。
あの頃は本当に酷かった。
いくら願っても、smb sharesとaccess databasesはロックと同時ユーザーに関する昔と同じ酷い問題を抱えたまま生き残ってるんだよな。
へ〜、TIL！記事に加えてくれてサンキュー。俺のVSS経験もひどかったし、ファイル壊れたりもしたよ。
90年代にVSS使ったけど、チーム開発じゃ悪夢だったわ。MS自身は内部でほとんど使ってなかったはずだよ。
その通り。SDの前はMSの部署（OfficeとかWindowsとか）はSLMって内部ツール使ってたんだって。Raymond Chenがブログで書いてるよ：https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97…
90年代にソロでVSS使ったらすごかった。大学院ではRCSとかCVSも知った。2004年にMS入って、VSSは安全じゃなくて腐敗しやすいって聞いたよ。本当か噂か分かんないけど、仕事では使えなかったな。
Sourcesafeとのツール連携は当時かなり良かったね。他にはああいうレベルなかった。でもVSSはマジ不安定で、理由なくランダムに壊れた。職場じゃ毎日バックアップから戻してたよ。PVCSに変えたらそれはなかった。VSSはローカルならマシだったかも。ネットワークだとすぐダメに。新しいバージョンほどひどくなった。GUIは分かりやすくて教えやすかったけど、チェックアウト／インモデルは分かりやすい反面、他のブランチシステムは最初分かりにくいよね。
90年代後半の大学の授業でVSSを使わなきゃいけなくて、たった一つの授業、一つのプロジェクトなのに、それでも壊しちゃったよ。
〉 No idea if that was true
それ、とんでもない控えめな言い方だよ。本気でVSS使っててファイルが壊れるのを見なかった人は、コード履歴を見なかった人だけ！
90年代後半から2000年代初めまでVSSを数年使ったよ。無いよりはマシ、ってレベル。すごく遅くて、ネットワーク負荷も高かったし（MS Accessみたい）、マージ機能も超貧弱（ファイルチェックアウトしたら他の誰も変更できない）。あと、そう、めちゃくちゃ壊れやすかった。何回か履歴捨ててやり直すしかなかったもん。
SourceSafeには素晴らしいビジュアルマージツールがあったね。複数チェックアウトもできたんだ。VSSにはたくさん問題あったけど、複数チェックアウトを有効にしないのは会社が自分で苦しめただけだよ。SourceSafeのマージツールは今でもたまに懐かしくなるな。
Visual Studioのgit連携使ったことある？（注：マージ作業自体は他のとこでやって、VSで競合の管理したり、外からコミットしてもいいんだけどさ。）
Visual Source Unsafeって呼んでたよ。
いっつもリポジトリが壊れてたからね。
たしか、特定の操作中にディスク容量なくなると、静かに壊れる問題があったんだ。
終わるまでどんだけ容量使うか分かんなくて、気づきもしなかったよ。
Microsoftにいた時、Source Depotは使ったVCの中でマシな方だったかな。もう一つのSource Library Managerはもっとひどかった。
そうそう、Visual Source Shredって呼んでた気がするな。
自分だけの経験じゃなかったって知れてちょっと嬉しいよ。
記憶が曖昧だけど、VSSはクライアントのタイムスタンプを信用してて、誰かのクロックがズレると全部壊れた気がする。
2000年代前半のWindowsじゃNTPがちゃんと動かなかったから、しょっちゅう起きたんだよ。
MicrosoftでXNSからTCP/IPへの移行を担当したチームにいたけど、あれは今回のより大変じゃなかったな。でも似たような学びはあったよ。
MSMAILからExchangeへの移行は、あれはキツかった！
それって、「Exchange: The Most Feared and Loathed Team in Microsoft」っていうライセンスプレートフレームの元ネタ？
ちょっと wording 違うかも。20年近く見てないからね。
多分そうだよ。
MSMAILを本当に愛してた人も多かったんだ。Exchangeはそうでもなかったな。
もっと長くて退屈なプロジェクトの話もあるけど、それはまた今度ね。
たまにMSMAILを愛した理由が変なこともあったな…
MSMAILはWin3.x用に設計されてて、アプリにマルチスレッドがなかったんだ。メールポンプっていう見えないアプリがアイドル中にメールの送受信をチェックしてた。だからユーザーは送信ボタン押しても数秒待てば、気が変わって送信取り消しできたんだ。それでキャリアが終わるのを回避できた。
Exchangeはクライアントサーバー方式だから、送信押すとほぼ瞬時にサーバーが気づいて送っちゃう。ユーザーはまばたきする間に取り消せない。速すぎるって文句言うユーザーもいたんだよ。
MSPAGERって聞いてニューロンが反応してるけど、romeoとjulietは知らないな。それはいいことだね。
だってインフラ知ってても実装に関わってないなら、なんでその「ソーセージの作り方」を知ってるかには大抵ヤバい理由があるから！
あと、Bedlam DL3は生き残ったよ（Tシャツはもらえなかったけど）。
Bedlamの話の説明はここ見て→https://techcommunity.microsoft.com/blog/exchange/me-too/610…
昔MSMAILを使っててMSPAGERをccに入れてた場合、そのスレッドにいるPager持ってる人全員にPagerが飛んでたんだって。
＞Exchangeが速すぎると文句を言うユーザーが何人かいた
それは実際よくあることで、“benevolent deception”って呼ばれてるんだ。HNでも数年前に議論されてたな[1]。[1] https://news.ycombinator.com/item?id=16289380
Mail Pumpの遅いメール処理も、Exchangeの速いメール処理も、“benevolent deception”とは言えないな。
MSMail/Exchange Client/Outlookでは、Outboxにメールがあるってことは送信待ちだけど、まだ処理されてないってことなんだ。
MSMailがExchangeよりメール送信が遅かったのは、ソフトウェアアーキテクチャによるリーキーアブストラクションなんだ。
Win3.xはマルチスレッドアプリをサポートしてなくて、協調的マルチタスクシステムを使ってた。だからアプリが何か重い処理をしてると、ユーザーはシステムに触れなくなってたんだ。ユーザーインターフェースのイベントが処理されないからね。
だからMail Pumpはシステムがアイドルかチェックしてた。ユーザーが操作してる最中なのにアイドルだって宣言したくないから、このヒューリスティクスは速くないんだ。なのでMail Pumpは辛抱強く待つ必要があった。つまりメールがOutboxに1秒以上留まることもあったってこと。
Exchange Serverは別の箱で動くサーバープロセスだった。メールクライアントがExchange Serverにメールを送るって通知したら、Exchange Serverはユーザーの操作をブロックする心配がないから、ほとんどすぐにメールを処理できたんだ。
でも、この問題には良い解決策があったんだ。Exchange Serverは意図的に遅延を追加しなかった。
誰かアーキテクトかプログラムマネージャーが、メールメッセージのサポートプロパティリストに「送信/処理前の遅延」プロパティを追加してたんだ。Exchange/Win95/Caponeクライアントはこのプロパティを使ってなかった。でも開発者はメール拡張機能を書くことができて、ユーザーが送信メールごとのデフォルト遅延を指定できるようにして、メール送信時にこの「送信/処理前の遅延」プロパティを設定すれば、Exchange Serverは指定された遅延時間だけ待ってからメッセージを処理するようにできたんだ。
送信メールの処理を遅くしたいユーザーは、このクライアント拡張機能をインストールして、希望の遅延時間を指定できたわけ。
Outlookは数年後にこのプロパティのサポートを追加したよ。
Gmailも送信済みメールの取り消しを有効にするための遅延サポートを追加したのに気づいてるよ。
ハハ、昔の記憶が錆びついてるかもだけど、この名前には見覚えがあるな。Raymond Chenの引用があった古いブログを書いてた人じゃない？一つ覚えてるのは「IDEとコマンドラインでコンパイル結果が違うコードをどうやって書くの？」ってやつで、答えが「そんなことしたら、ローカルビルドでデバッグしようとした同僚にお焚き上げされるぞ」みたいなのだったんだ。
＞Authenticity mattered more than production value.
この本音のストーリー共有してくれてありがとう！私は元MSFTで、比較的小規模な製品ラインにいたんだけど、私が辞める直前の2015年にSourceDepotからGitへの移行を始めたばかりだったんだ。君たちがやった仕事がいかに素晴らしいか、心から共感するよ！
ありがとう！そういえば、Windows NTのリリースまでの道のりを書いた“Showstopper”って本思い出すよ。すごくおすすめ！
もっとコメントを表示（2）
ついでに、そのジャンルが好きなら私のお気に入りの本の一つにインターネット開発の話の“where wizards stay up late”ってのがあるよ。
Source Depotから移行させるのに結構時間かかったし、しばらくは危なかったよ。でも、その努力は報われたから、ありがとう！
MicrosoftがVisual SourceSafeから社内的に移行したのはいつなのか知りたいな…。あれは一般の人が使い続けないように回収すべきだったんじゃないか。
使ってたよ。当時は他に良い方法を知らなかったんだ。Visual Studioと統合されてたから、小さいチームには分かりやすい選択肢だったね。
ファイルを変えたい時はチェックアウトしないといけなくて、そうすると他の人は変更できなくなるんだ。文字通り、チェックアウトしないとファイルは読み取り専用だった。「一人ずつどうぞ」っていうバージョン管理のアプローチだったね（もう一つは「マージは後で考えよう」っていうアプローチ）。
君はラッキーだよ。僕が使う羽目になったツールの中でも間違いなく最悪の一つだった。変な理由でその上に何か作っちゃう人がいて、さらにひどくなってたんだ。
ほとんどのチームはSource Depot使ってなかったと思うな。僕はMicrosoftで数年働いたけど、うちのチームはSource Depotを使ってたよ。たくさんの人が、うちの製品は特別だからMicrosoft自身のSource Control（当時はTFS）じゃ不十分だって考えてたんだ。
前の職場でTFSを使ったことがあって、あまり好きじゃなかったけど、Source Depotを使わなきゃならなくなってTFSが恋しくなったよ。
それはCVS（とその前身のRCSとかSCCS）と全く同じ仕組みだね。ファイルベースのリビジョン管理で、リポジトリベースじゃなかったんだ。
SVNはtrunk／branches／tagsみたいなフォルダを追加して、ファイルベースのバージョン管理に重ねただけだったんだ。だからブランチ作成やマージがすごく複雑だったんだよね。どのファイルもマージできなかったら、途中の状態のブランチ元とブランチ先が残って、ロールバックしなきゃいけなかったから。
マージがいらないようにするオプションがあった、当時大きな商用SCMツールを思い出したよ。Dropboxみたいにファイルシステムに”sync”できて、リリースやブランチを切るために専任の管理チームが必要だったんだ。IBMが買収したんだっけ？
TFSが記事で全く言及されてないのが意外だったな（僕が読んだ限りではね）。同時期には存在してたはずだし、Microsoftの他の部署では使ってたはずだよ。2005年にリリースされたと思うけど、社内ではもっと前からあっただろうに。
それってRational Roseのことかな？僕は2004年に最初の仕事（フィンテック）で、あれを使うハメになったよ。
Source Safeは少なくともCVSよりはちょっとマシだったかな。でも、当時SVNもあったのに、Source Safeを使ってる会社の考え方が全然理解できなかったんだよね。
CVSが“concurrent version system”と呼ばれたのは、チェックアウト時にファイルをロックしなかったからだよ。SVNもそう。Perforceはロックする方式だね。
ロック方式はIC設計で今でも使われてるみたい。CadenceとかSynopsisの、マージできないバイナリデータファイル用とかね。詳しいことは知らないけど、社内の他の部署から聞いた話だよ。
CVSよりちょっとマシ？それはかなり議論の余地ありだね。CVSのUIはひどかったけど、すぐ壊れることもなかったし、デフォルトでファイルロックも必要なかった（担当者が休んでファイルがチェックアウトされたままになったら、管理者呼んでロック解除しないといけなかった）。あと、Source SafeはSMB共有への書き込みアクセスが必要で、それがよく壊れる原因の一つだったんだよ。
TFSはDevDivでかなり使われてたけど、Windowsの巨大なリポジトリではパフォーマンス的に満足いくレベルにはならなかったらしい。集中型ソース管理システムとしてはそんなに悪くなかったけど、SVNをマイクロソフト流に作り直した感じだったね。Visual Studioとの連携がすごく深い以外に、なんでSVNじゃなくてこれを使う必要があるのかよくわからなかったな。
ホントそれ。Source Safeって自分のデータストアもよく壊れる変な癖があったよね。ソース管理システムとしてはまさに最悪！
でも、ぶっちゃけSource Safe使わないよりは、何も使わない方がもっとひどいけどね。
SVNのリポジトリでは、他の人が同じファイルを編集してても、自分のマシンで自由に編集できるはずだよ。
ファイルロック機能は面白かったね。担当者がロック解除忘れて休んじゃったりするとね。それに、ファイルが理由もなくランダムに消えるブラックホール機能も忘れちゃダメだ。あれは今まで使ったソフトウェアの中で一番ひどいものだったかも。
Source Safeは社内で大規模に使われてたかは分からないな。少なくとも主要なものには使われてないだろう。もし使ってたなら、あんな状態のまま売らなかっただろうし…
TFSは説明つかないな。あれは社内でも社外でもゴミだったよ。
