Live data from Hacker News

Microsoft Office migration from Source Depot to Git

danielsada.tech

1–10 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#5
Its oddly fascinating that Microsoft has managed to survive for so long with ancient/bad tools for software engineering. Almost like “life finds a way” but for software dev. From the outside it seems like they are doing better now after embracing OSS/generic dev tools.

Re: Microsoft Office migration from Source Depot to Git

#6

[flagged]

> Microsoft had to collaborate with GitHub to invent the Virtual File System for Git (VFS for Git) just to make this migration possible. Without VFS, a fresh clone of the Office repository (a shallow git clone would take 200 GB of disk space) would take days and consume hundreds of gigabytes.

Re: Microsoft Office migration from Source Depot to Git

#7
I spent nearly a week of my Microsoft internship in 2016 adding support for Source Depot to the automated code reviewer that I was building (https://austinhenley.com/blog/featurestheywanted.html) despite having no idea what Source Depot was!

Quite a few devs were still using it even then. I wonder if everything has been migrated to git yet.

Re: Microsoft Office migration from Source Depot to Git

#8
post #5

Its oddly fascinating that Microsoft has managed to survive for so long with ancient/bad tools for software engineering. Almost like “life finds a way” but for software dev. From the outside it seems like they are doing better now after embracing OSS/generic dev tools.

At one point source depot was Toincredibly advanced, and there are still features that it had that git doesn't. Directory mapping being a stand out feature! Being able to only pull down certain directories from a depot and also remap where they are locally, and even have the same file be in multiple places. Makes sharing dependencies across multiple projects really easy, and a lot of complicated tooling around "monorepos" wouldn't need to exist if git supported directory mapping.

(You can get 80% of the way there with symlinks but in my experience they eventually break in git when too many different platforms making commits)

Also at one point I maintained an obscenely advanced test tool at MS, it pounded through millions of test cases across a slew of CPU architectures, intermingling emulators and physical machines that were connected to dev boxes hosting test code over a network controlled USB switch. (See: https://meanderingthoughts.hashnode.dev/how-microsoft-tested... for more details!)

Microsoft had some of the first code coverage tools for C/C++, spun out of a project from Microsoft Research.

Their debuggers are still some of the best in the world. NodeJS debugging in 2025 is dog shit compared to C# debugging in 2005.

Re: Microsoft Office migration from Source Depot to Git

#9
post #8
post #5

Its oddly fascinating that Microsoft has managed to survive for so long with ancient/bad tools for software engineering. Almost like “life finds a way” but for software dev. From the outside it seems like they are doing better now after embracing OSS/generic dev tools.

At one point source depot was Toincredibly advanced, and there are still features that it had that git doesn't. Directory mapping being a stand out feature! Being able to only pull down certain directories from a depot and also remap where they are locally, and even have the same file be in multiple places. Makes sharing dependencies across multiple projects really easy, and a lot of complicated tooling around "monor…

> git supported directory mapping.

Is this a "git" failure or a "Linux filesystems suck" failure?

It seems like "Linux fileystems" are starting to creak under several directions (Nix needing binary patching, atomic desktops having poor deduplication, containers being unable to do smart things with home directories or too many overlays).

Would Linux simply sucking it up and adopting ZFS solve this or am I missing something?

Re: Microsoft Office migration from Source Depot to Git

#10

  We communicated the same information through multiple channels: weekly emails, Teams, wiki docs, team presentations, and office hours. The rule: if something was important, people heard it at least 3 times through different mediums.
If only this were standard. Last week I received the only notification that a bunch of internal systems were being deleted in two weeks. No scream test, no archiving, just straight deletion. Sucks to be you if you missed the email for any reason.
Post reply on HN