> In the early 2000s, Microsoft faced a dilemma. Windows was growing enormously complex, with millions of lines of code that needed versioning. Git? Didn’t exist. SVN? Barely crawling out of CVS’s shadow. I wonder if Microsoft ever considered using BitKeeper, a commercial product that began development in 1998 and had its public release in 2000. Maybe centralized systems like Perforce were the norm and a DVCS like Bi…
There was SourceSafe (VSS) around that time and TFVC afterwards.
Microsoft Office migration from Source Depot to Git
271–280 of 290 posts
Re: Microsoft Office migration from Source Depot to Git
#272I 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.
I miss CodeFlow everyday. It was such a great tool to use.
Still buried as internal only though.
Re: Microsoft Office migration from Source Depot to Git
#273Earlier quoted context omitted.
Interesting. Seems antithetical to the 'git centered' view of being for source code only (mostly) I think I read somewhere that game dev teams would also check in the actual compiler binary and things of that nature into version control. Usually it's considered "bad practice" when you see, like, and entire sysroot of shared libs in a git repository. I don't even have any feeling one way or another. Even today "vendor…
It's only considered a bad idea because git handles it poorly. You're already putting all your code in version control - why would you not include the compiler binaries and system libraries too? Now everybody that gets the code has the right compiler to build it with as well! The better organised projects I've worked on have done this, and included all relevant SDKs too, so you can just install roughly the right vers…
No arguments here, it makes perfect sense to me as a practice. It's shortsighted to consider only "libraries" (as source, typically) to be "dependencies"--implicitly you're relying on a compatible compiler version/runtime/interpreter (and whatever those depend on) and etc
What was the nature of this project? Was this something related to game development?
That seems to be the only domain where this approach is used (from what I've heard).
Re: Microsoft Office migration from Source Depot to Git
#274Earlier quoted context omitted.
We use BitBucket where I work. Due to certain export regulations it's simpler for us to keep as many services as possible on-prem if they're going to contain any of our intellectual property, so BitBucket Server it is. There are other options of course, but all of the cloud solutions were off the table.
But why not GitLab or GitHub’s on prem servers?
Re: Microsoft Office migration from Source Depot to Git
#275Re: Microsoft Office migration from Source Depot to Git
#276With a product like this that spans many decades would the source repo contain all of these versions and the changes over time. For instance word 97 - 2000 - 2003 - 2007, etc..
Re: Microsoft Office migration from Source Depot to Git
#277Earlier quoted context omitted.
I cannot believe that new hires would be upset by the choice of version control software. They joined a new company after so many hoops and it's on them for having an open mind towards processes and tools in the new company.
> I cannot believe that new hires would be upset by the choice of version control software. I can, if the version control software is just not up to standards. I absolutely didn’t mind using mercurial/hg, even though I literally haven’t touched it until that point and knew nothing about it, because it is actually pretty good. I like it more than git now. Git is a decent option that most people would be familiar with,…
Re: Microsoft Office migration from Source Depot to Git
#278Earlier quoted context omitted.
The problem is that you come to a prestigious place like Microsoft and end up using horrible outdated software. Credit where credit is due at my time at Excel we did improve things a lot (migration from Script# to TypeScript, migration from SourceDepot to git, shorter dev loop and better tooling etc) and a large chunk of development time was spent on developer tooling/happiness. But it does suck to have to go to one…
What's Script#?
Re: Microsoft Office migration from Source Depot to Git
#279I feel like we're well into the longtail now. Are there other SCM systems or is it the end of history for source control and git is the one and done solution?
Re: Microsoft Office migration from Source Depot to Git
#280This article makes out thousands of engineers that are good enough to qualify at Microsoft and work on Office but haven't used git yet? That sounds a bit overplayed tbh, if you haven't used git you must live under a rock. You can't use Source Depot at home. Overall good story though
In the context of this, when and why would the average dev get time to properly use git - no just get a shallow understanding, but use it at the complexity level needed for an large internal mono-repo ported to it.
I've used git Microsoft for years, but using git with Office client is totally different. I believe it's used differently, with very different expecations in Windows.