Live data from Hacker News

Microsoft Office migration from Source Depot to Git

danielsada.tech

261–270 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#261

Earlier quoted context omitted.

And sometimes they loved MSMAIL for the weirdest reasons... MSMAIL was designed for Win3.x. Apps didn't have multiple threads. The MSMAIL client app that everyone used would create the email to be sent and store the email file on the system. An invisible app, the Mail Pump, would check for email to be sent and received during idle time (N.B. Other apps could create/send emails via APIs, so you couldn't have the email…

I re-wrote MSPAGER for Exchange. Hoo boy what a hack that was! A VB3 app running as a service, essentially. I don't know if you remember romeo and juliet; those were PCs pulled from pc-recycle by a co-worker to serve install images.

My neurons are firing on "MSPAGER" in recognition, but romeo and juliet draw blanks - which is a good thing. Because if you know the infrastructure, but you weren't involved in the implementation, then there's typically a bad reason why you know how the sausage is getting made. :)

Also, I survived Bedlam DL3 (but I didn't get the t-shirt).

see https://techcommunity.microsoft.com/blog/exchange/me-too/610... for the explanation for the Bedlam reference.

Re: Microsoft Office migration from Source Depot to Git

#262
post #223
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.

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

#263

Earlier quoted context omitted.

I re-wrote MSPAGER for Exchange. Hoo boy what a hack that was! A VB3 app running as a service, essentially. I don't know if you remember romeo and juliet; those were PCs pulled from pc-recycle by a co-worker to serve install images.

My neurons are firing on "MSPAGER" in recognition, but romeo and juliet draw blanks - which is a good thing. Because if you know the infrastructure, but you weren't involved in the implementation, then there's typically a bad reason why you know how the sausage is getting made. :) Also, I survived Bedlam DL3 (but I didn't get the t-shirt). see https://techcommunity.microsoft.com/blog/exchange/me-too/610... for the ex…

if you had a thread in MSMAIL, and cc: MSPAGER, anyone on the thread with a pager would get a page from the thread.

Re: Microsoft Office migration from Source Depot to Git

#264

Earlier quoted context omitted.

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.

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.

That would segue into a discussion about NetDocs at Microsoft.

background - https://en.wikipedia.org/wiki/Ajax_(programming) - 1998, XMLHttpRequest appears.

NetDocs vs Office - 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-resolv...

Aftermath - https://www.eweek.com/development/netdocs-succumbs-to-xp/

Re: Microsoft Office migration from Source Depot to Git

#265

Earlier quoted context omitted.

It was at least a little better than CVS, but with SVN available at the same time, never understood the mentality of the offices that I worked at using Source Safe instead of SVN.

> It was at least a little better than CVS Highly debatable. CVS has a horrendous UI, but didn’t have a tendency to corrupt itself at the drop of a hat and didn’t require locking files to edit them by default (and then require a repository admin to come in and unlock files when a colleague went on holidays with files checked out). Also didn’t require shared write access to an SMB share (one of the reasons it corrupte…

Uhh, CVS definitely regularly corrupted itself. I nearly lost my senior research thesis in undergrad because of it. The only thing that saved me was understanding professors and the fact that I could drive back home to my parents' house and get back to my review in 30 minutes, where I had a good copy of my code I could put on an Iomega Zip disk from my desktop instead of the corrupted copy we couldn't pull from CVS in the CS lab.

Re: Microsoft Office migration from Source Depot to Git

#266

> Today, as I type these words, I work at Snowflake. Snowflake has around ~2,000 engineers. When I was in Office, Office alone was around ~4,000 engineers. I'm sorry, what?! 4,000 engineers doing what, exactly? Excel turns 40 this year and has changed very little in those four decades. I can't imagine you need 4,000 engineers just to keep it backwards compatible. In the meantime we've seen entire companies built with…

The author mentions the list of products that were impacted with this migration

> Word, Excel, Powerpoint, Sway, Publisher, Access, Project, OneNote, Shared Services (OSI), Shared UX, + everything in the web

Re: Microsoft Office migration from Source Depot to Git

#267
post #211

Earlier quoted context omitted.

Yeah it's an issue for new devs for sure. TFA even makes the point, "A lot of people felt refreshed by having better transferable skills to the industry. Our onboarding times were slashed by half".

Interesting to hear it was so much of a problem in terms of onboarding time. Maybe Source Depot was particularly weird, and/or MS were using it in a way that made things particularly complicated? Perforce has never felt especially difficult to use to me, and programmers never seem to have any difficulty with it. Artists and designers seem to pick it up quite quickly too. (By and large, in contrast to programmers, the…

    > git style of shit
I don't understand this phrase. Can you explain more?

Re: Microsoft Office migration from Source Depot to Git

#268
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 almost cried of happiness when we moved to git from SVN on my first job after being there for 6 months They might not be upset on the first few weeks but after a month or so they will be familiar with the pain.

    > cried of happiness when we moved to git from SVN
You bring back some real memories with this phrase.

I recall moving from RCS and CVS and thinking: "Oh, this is a real improvement." (Forgive me; I was young.)

Then, I moved from CVS to SVN and thought: "This is revolutionary. I can rename and merge." (Again, please withhold throwing your tomatoes until the end of the story!)

Later, projects grew large enough, that SVN became horrible because of how I/O worked on my PCs/networks (file by file, long before 1G network to developer PCs and horribly slow spinning disks).

The upgrade to Git was epic. Sure, the commands are weird and complex. More than 10 years later, I still need to lookup a command once a month, but it beats the pants off anything before. Hat tip to all the people (Hamano-san, et al) who have contributed to Git in the last 20 years. My life as a developer is so much better for it.

Re: Microsoft Office migration from Source Depot to Git

#269

Earlier quoted context omitted.

Discord I get, at least from a community or network effect, but Bitbucket? I can’t figure out why anyone but a CTO looking to save a buck would prefer Bitbucket.

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

#270
post #211

Earlier quoted context omitted.

Interesting to hear it was so much of a problem in terms of onboarding time. Maybe Source Depot was particularly weird, and/or MS were using it in a way that made things particularly complicated? Perforce has never felt especially difficult to use to me, and programmers never seem to have any difficulty with it. Artists and designers seem to pick it up quite quickly too. (By and large, in contrast to programmers, the…

> git style of shit I don't understand this phrase. Can you explain more?

It's a fairly typical Unix tool, but: worse! It's got a rather cryptic and unhelpful command line UI that's often fiddly to use, rather requires you to understand its internals in order to work with it, and has lots of perplexing failure modes. There are GUIs for it, which do help, but people moan at you if you use them, and/because they're often opinionated and oriented towards some specific workflow or other. And they don't really stop it being fiddly to use, you still need to bear in mind how it works internally to use it, and the perplexing failure modes remain.

It's a generalisation, but, by and large, artists and designers don't enjoy using these sorts of tools. Also, they are more likely to be working with unmergeable files, something that git isn't really designed to work with.

(Programmers often don't like these sorts of tools either, but - again, a generalisation - they're harder to avoid if you're a programmer, so the average one is typically a bit more practised at putting up with this crap.)

Post reply on HN