5 ms·

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

by pm90 1y ago

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.

com2kid 1y ago
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-compilers-circa-2006 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.
- bsder 1y ago
  > 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?
  - MobiusHorizons 1y ago
    How is that related? I don’t think anyone would suggest ntfs is a better fit for these applications. It worked because it was a feature of the version control software, not because of file system features.
  - yjftsjthsd-h 1y ago
    What would ZFS do for those issues? I guess maybe deduplication, but otherwise I'm not thinking of anything that you can't do with mount --bind and overlays (and I'm not even sure ZFS would replace overlays)
    - bsder 1y ago
      Snapshots seems to be a cheap feature in ZFS but are expensive everywhere else, for example. OverlayFS has had performance issues on Linux for a while (once you start composing a bunch of overlays, the performance drops dramatically as well as you start hitting limits on number of overlays).
      - adrian_b 1y ago
        Nowadays the ZFS advantage for snapshots is no longer true. Other file systems, e.g. the much faster XFS, have equally efficient snapshots.
- klank 1y ago
  Ok, but now tell me your real thoughts on sysgen. ;-)
- o11c 1y ago
  As always, git's answer to the problem is "stop being afraid of `git submodule`." Cross-repo commits are not a problem as long as you understand "it only counts as truly committed if the child repo's commit is referenced from the parent repo".
  - xmprt 1y ago
    > it only counts as truly committed if the child repo's commit is referenced from the parent repo This is a big problem in my experience. Relying on consumers of your dependency to upgrade their submodules isn't realistic.
  - mickeyp 1y ago
    Git submodules are awful. Using subversion's own submodule system should be mandatory for anyone claiming Git's implementation is somehow worthwhile or good.
- tikkabhuna 1y ago
  I never understood the value of directory mapping when we used Perforce. It only seemed to add complexity when one team checked out code in different hierarchies and then some builds worked, some didn’t. Git was wonderful for having a simple layout.
  - senderista 1y ago
    You might feel differently if you worked on just a few directories in a giant repo. Sparse client views were a great feature of SD.
    - int_19h 1y ago
      I'm in exactly this situation with Perforce today, and I still hate it. The same problem OP described applies - you need to know which exact directories to check out to build, run tests etc successfully. You end up with wikis filled with obscure lists of mappings, many of them outdated, some still working but including a lot of cruft because people just copy it around. Sometimes the required directories change over time and your existing workspaces just stop working. Git has sparse client views with VFS these days.
deleted 1y ago
[deleted]
dangus 1y ago
Let’s not forget that Microsoft developed a lot of tools in the first place, as in, they were one of the companies that created things that didn’t really exist before Microsoft created them. Git isn’t even very old, it came out in 2005. Microsoft Office first came out in 1990. Of course Office wasn’t using git.
- dboreham 1y ago
  Some examples would be useful here. Not knocking MS tools in general but are there any that were industry fists? Source code control for example existed at least since SCCS which in turn predates Microsoft itself.
  - pianoben 1y ago
    Of course that's only half the story - Microsoft invents amazing things, and promptly fails to capitalize on them. AJAX, that venerable piece of kit that enabled every dynamic web-app ever, was a Microsoft invention. It didn't really take off, though, until Google made some maps with it.
    - canucker2016 1y ago
      That would segue into a discussion about NetDocs at Microsoft. background - https://en.wikipedia.org/wiki/Ajax_(programming) https://en.wikipedia.org/wiki/Ajax_(programming) - 1998, XMLHttpRequest appears. NetDocs vs Office - https://hardcoresoftware.learningbyshipping.com/p/064-the-start-of-office-v-netdocs https://hardcoresoftware.learningbyshipping.com/p/064-the-st... Resolving NetDocs vs Office [Spoiler Alert - if you don't know about NetDocs, there's a big reason which tells you who "won" this fight] - https://hardcoresoftware.learningbyshipping.com/p/071-resolving-netdocs-v-office https://hardcoresoftware.learningbyshipping.com/p/071-resolv... Aftermath - https://www.eweek.com/development/netdocs-succumbs-to-xp/ https://www.eweek.com/development/netdocs-succumbs-to-xp/
  - noen 1y ago
    Microsoft rarely did or does anything first. They are typically second or third to the post and VC is no different. Most people don’t know or realize that Git is where it is because of Microsoft. About 1/2 of the TFS core team spun out to a foundation where they spent several years doing things like making submodules actually work, writing git-lfs, and generally making git scale. You can look for yourself at the libgit2 repo back in the 2012-2015 timeframe. Nearly the whole thing was rewritten by Microsoft employees as the earliest stages of moving the company off source depot. It was a really cool time that I’m still amazed to have been a small part of.
senderista 1y ago
Google used Perforce for years and I think Piper still has basically the same interface? So no, MSFT wasn’t ridiculously behind the times by using Source Depot for so long.

by pm90 1y ago

com2kid 1y ago

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-compilers-circa-2006 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.

bsder 1y ago
> 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?
- MobiusHorizons 1y ago
  How is that related? I don’t think anyone would suggest ntfs is a better fit for these applications. It worked because it was a feature of the version control software, not because of file system features.
- yjftsjthsd-h 1y ago
  What would ZFS do for those issues? I guess maybe deduplication, but otherwise I'm not thinking of anything that you can't do with mount --bind and overlays (and I'm not even sure ZFS would replace overlays)
  - bsder 1y ago
    Snapshots seems to be a cheap feature in ZFS but are expensive everywhere else, for example. OverlayFS has had performance issues on Linux for a while (once you start composing a bunch of overlays, the performance drops dramatically as well as you start hitting limits on number of overlays).
    - adrian_b 1y ago
      Nowadays the ZFS advantage for snapshots is no longer true. Other file systems, e.g. the much faster XFS, have equally efficient snapshots.
klank 1y ago
Ok, but now tell me your real thoughts on sysgen. ;-)
o11c 1y ago
As always, git's answer to the problem is "stop being afraid of `git submodule`." Cross-repo commits are not a problem as long as you understand "it only counts as truly committed if the child repo's commit is referenced from the parent repo".
- xmprt 1y ago
  > it only counts as truly committed if the child repo's commit is referenced from the parent repo This is a big problem in my experience. Relying on consumers of your dependency to upgrade their submodules isn't realistic.
- mickeyp 1y ago
  Git submodules are awful. Using subversion's own submodule system should be mandatory for anyone claiming Git's implementation is somehow worthwhile or good.
tikkabhuna 1y ago
I never understood the value of directory mapping when we used Perforce. It only seemed to add complexity when one team checked out code in different hierarchies and then some builds worked, some didn’t. Git was wonderful for having a simple layout.
- senderista 1y ago
  You might feel differently if you worked on just a few directories in a giant repo. Sparse client views were a great feature of SD.
  - int_19h 1y ago
    I'm in exactly this situation with Perforce today, and I still hate it. The same problem OP described applies - you need to know which exact directories to check out to build, run tests etc successfully. You end up with wikis filled with obscure lists of mappings, many of them outdated, some still working but including a lot of cruft because people just copy it around. Sometimes the required directories change over time and your existing workspaces just stop working. Git has sparse client views with VFS these days.

deleted 1y ago

[deleted]

dangus 1y ago

Let’s not forget that Microsoft developed a lot of tools in the first place, as in, they were one of the companies that created things that didn’t really exist before Microsoft created them. Git isn’t even very old, it came out in 2005. Microsoft Office first came out in 1990. Of course Office wasn’t using git.

dboreham 1y ago
Some examples would be useful here. Not knocking MS tools in general but are there any that were industry fists? Source code control for example existed at least since SCCS which in turn predates Microsoft itself.
- pianoben 1y ago
  Of course that's only half the story - Microsoft invents amazing things, and promptly fails to capitalize on them. AJAX, that venerable piece of kit that enabled every dynamic web-app ever, was a Microsoft invention. It didn't really take off, though, until Google made some maps with it.
  - canucker2016 1y ago
    That would segue into a discussion about NetDocs at Microsoft. background - https://en.wikipedia.org/wiki/Ajax_(programming) https://en.wikipedia.org/wiki/Ajax_(programming) - 1998, XMLHttpRequest appears. NetDocs vs Office - https://hardcoresoftware.learningbyshipping.com/p/064-the-start-of-office-v-netdocs https://hardcoresoftware.learningbyshipping.com/p/064-the-st... Resolving NetDocs vs Office [Spoiler Alert - if you don't know about NetDocs, there's a big reason which tells you who "won" this fight] - https://hardcoresoftware.learningbyshipping.com/p/071-resolving-netdocs-v-office https://hardcoresoftware.learningbyshipping.com/p/071-resolv... Aftermath - https://www.eweek.com/development/netdocs-succumbs-to-xp/ https://www.eweek.com/development/netdocs-succumbs-to-xp/
- noen 1y ago
  Microsoft rarely did or does anything first. They are typically second or third to the post and VC is no different. Most people don’t know or realize that Git is where it is because of Microsoft. About 1/2 of the TFS core team spun out to a foundation where they spent several years doing things like making submodules actually work, writing git-lfs, and generally making git scale. You can look for yourself at the libgit2 repo back in the 2012-2015 timeframe. Nearly the whole thing was rewritten by Microsoft employees as the earliest stages of moving the company off source depot. It was a really cool time that I’m still amazed to have been a small part of.

senderista 1y ago

Google used Perforce for years and I think Piper still has basically the same interface? So no, MSFT wasn’t ridiculously behind the times by using Source Depot for so long.