Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows: A software engineering odyssey (2000)

usenix.org

Post reply on HN
Print view View original

1–10 of 104 posts

Re: Windows: A software engineering odyssey (2000)

#6

Post by gigel82 »

Source Depot was still a thing in Office as of last year when they finally transitioned to Git. Windows started transitioning to Git 5 years ago.

Also, they have about 10k people working on Windows (and devices) and about 10k people working on ads nowadays (that paints a good story of priorities).

Source: 2nd hand from MS friends

Re: Windows: A software engineering odyssey (2000)

#7

Post by com2kid »

gigel82 wrote: post #6

Source Depot was still a thing in Office as of last year when they finally transitioned to Git. Windows started transitioning to Git 5 years ago. Also, they have about 10k people working on Windows (and devices) and about 10k people working on ads nowadays (that paints a good story of priorities). Source: 2nd hand from MS friends

Source Depot's largest disadvantage VS git how hard it is to share changes with others.

But I miss the ability to only pull down a portion of a monorepo, and the ability to remap where folders are at, or to pull down a single folder into multiple locations.

So much bullshit in with monorepos in Git land exists because Git doesn't support things that Source Depot (and Perforce I presume) supported decades ago.

As an aside for those who don't know what I am talking about, when pulling down a repo in source depot you can specify which directories to pull down locally, and you can also remap directories to a different path. This is super useful for header files, or any other sort of shared dependency. Instead of making the build system get all funky and fancy, the source control system handled putting files into expected locations.

So imagine a large monorepo for a company and you can have some shared CSS styles that exist and they always end up in every projects `styles` folder or what have you.

Or the repo keeps all shared styles in a single place, and you can then import them into your project, but instead of build system bullshit you just go to your mappings and tell it to pull the proper files put them into a sub-directory of your project.

It is a really damn nice to have feature. (That also got misused a ton...)

Re: Windows: A software engineering odyssey (2000)

#8

Post by muricula »

LispSporks22 wrote: post #5

Can’t imagine how these Windows engineers feel about the enshitification of their baby. So much time invested into it - must be hard to see it taking this current trajectory.

A few years ago when I was there, there were still remnants of that same Dave Cutler NT culture, especially around the folks who worked on minkernel/.

I agree there are definitely shitty chunks Windows, but there are still some very solid foundations there to this day.

Re: Windows: A software engineering odyssey (2000)

#10

Post by forrestthewoods »

com2kid wrote: post #7
gigel82 wrote: post #6

Source Depot was still a thing in Office as of last year when they finally transitioned to Git. Windows started transitioning to Git 5 years ago. Also, they have about 10k people working on Windows (and devices) and about 10k people working on ads nowadays (that paints a good story of priorities). Source: 2nd hand from MS friends

Source Depot's largest disadvantage VS git how hard it is to share changes with others. But I miss the ability to only pull down a portion of a monorepo, and the ability to remap where folders are at, or to pull down a single folder into multiple locations. So much bullshit in with monorepos in Git land exists because Git doesn't support things that Source Depot (and Perforce I presume) supported decades ago. As an a…

Ehhh can’t say I’m a fan of folder remapping. It gets a little too auto-magical and since all tools access the file system directly different users can see different things. That’s just begging for bugs and “works on my machine”.

I’m moderately confident the correct path is monorepo + centralization + virtual filesystem. Not every tool plays nice with VFS but at this point most do.

The D in DVCS is almost entirely a waste. Source control systems should, imho, trivially support petabytes of history and terabyte scale clones.

Post reply on HN