Slide 19 doesn’t load for me.
Windows: A software engineering odyssey (2000)
11–20 of 104 posts
Re: Windows: A software engineering odyssey (2000)
#12Earlier quoted context omitted.
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…
I haven't seen a virtual filesystem overlaid on top of a monorepo before, do you have any examples of what that looks like?
Semi-related, I try to use symlink shenanigans in git to share common files between monorepo projects w/o using 3rd party tooling, but my latest attempt worked on Windows but the symlink fell apart when the repo was pulled down on a Mac!
Not the OS that I thought would have issues. :)
Re: Windows: A software engineering odyssey (2000)
#13Source 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…
Perforce's support for that is not great these days. They don't support it in streams, and honestly if you're not using streams in p4 these days you're doing it wrong.
Re: Windows: A software engineering odyssey (2000)
#14Earlier quoted context omitted.
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…
I haven't seen a virtual filesystem overlaid on top of a monorepo before, do you have any examples of what that looks like? Semi-related, I try to use symlink shenanigans in git to share common files between monorepo projects w/o using 3rd party tooling, but my latest attempt worked on Windows but the symlink fell apart when the repo was pulled down on a Mac! Not the OS that I thought would have issues. :)
> I haven't seen a virtual filesystem overlaid on top of a monorepo before, do you have any examples of what that looks like?
Re: Windows: A software engineering odyssey (2000)
#15Can’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.
I switched from 98 to ME for a week before 2k, and it (2k) was rock solid for years.
Re: Windows: A software engineering odyssey (2000)
#16Earlier quoted context omitted.
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…
The Distributed part is definitely not a waste. Some people have different workflows from yours and depend on it heavily.
Re: Windows: A software engineering odyssey (2000)
#17Source 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
Am still in Microsoft, was part of that transition and can confirm it.
We did move stuff we could to other git repos inside Microsoft.
SourceDepot is still running for some stuff and is still awful but git is working great.
> 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).
I'm not sure I'm privvy to all information but looking at the org chart this part is false. The ads org is much much smaller than E+D.
Re: Windows: A software engineering odyssey (2000)
#18Can’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.
For example, Windows kernel's write watch feature is useful for writing a GC. Linux lacked (and as far as I know, still lacks) this feature, so Microsoft had to rewrite .NET runtime.
https://devblogs.microsoft.com/dotnet/working-through-things...
Re: Windows: A software engineering odyssey (2000)
#19Source 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…
> 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.
We have all that with git in Microsoft though. We don't check out the entire office monorepo - only the parts relevant to what you're working on (Excel in my case).
Also sharing stuff in SourceDepot wasn't the bad part (you get links to changelists and those open in a desktop program). The bad part was the branching model, commits, no real/good CI (we had a commit queue) etc). SourceDepot was just overall a bad scm for us.
Re: Windows: A software engineering odyssey (2000)
#20> Source control system (Windows 2000) > Branch capability sorely needed, tree copies used as substitutes, so merging is a nightmare Ouch, and it looks like they only had version control with branching for the last nine months of development.
Branching is an overstatement. SourceDepot didn't _really_ do branching.
You had patches you'd float with "changelists" on top of enlistments. Each part large enough in thhe org (for example Excel or Word) gets a "branch" and it gets "forward integrated" and "reverse integrated" to the main "branch".
From your perspective the tool used to submit stuff (usubmit usually) you just push to the same branch as everyone else in your org and if your code breaks things it gets "backed out" by an automatic process.
Using git now is so much nicer.