Live data from Hacker News

Microsoft Office migration from Source Depot to Git

danielsada.tech

271–280 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#271
post #236

> 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.

Neither SourceSafe nor TFVC were distributed version control systems (DVCS) so I'm not sure what you mean.

Re: Microsoft Office migration from Source Depot to Git

#272
post #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.

I miss CodeFlow everyday. It was such a great tool to use.

CodeFlow lives on and is still held in high regard. It's even made it's way to support the github repos, not just git. https://chromewebstore.google.com/detail/codeflow/aphnoipoco...

Still buried as internal only though.

Re: Microsoft Office migration from Source Depot to Git

#273
post #252

Earlier 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…

> 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!

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

#274

Earlier 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?

I wouldn't know, the choice was made years before I joined the company, and I haven't come across anyone who told me what considerations went in back then.

Re: Microsoft Office migration from Source Depot to Git

#276
post #275

With 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..

I would hope they forked the repo for each new version, to keep the same core but being free to refactor huge parts without affecting previous versions.

Re: Microsoft Office migration from Source Depot to Git

#277
post #151

Earlier 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,…

You missed the point. The point is, a new hire being asked to use a new version control software likely doesn't know whether the tool is more like hg or more like source depot. It takes times to figure out that. So they need to reserve judgement.

Re: Microsoft Office migration from Source Depot to Git

#278
post #223

Earlier 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#?

C# like language compiled to Javascript.

Re: Microsoft Office migration from Source Depot to Git

#280

This 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

Something not touched on by others. The standard Microsoft contract outlawed any moonlighting for years, any code you created was potentially going to be claimed by Microsoft - so you didn't feel safe working on side projects or contributing to open source. Open source code was a pariah - you were warned unless you had an exception to never look at any open source code even vaguely related to your projects, including in personal time, for fear of opening up Microsoft to legal trouble.

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.

Post reply on HN