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

Microsoft Office migration from Source Depot to Git

danielsada.tech

Post reply on HN
Print view View original

251–260 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#251

Post by [deleted] »

chokolad wrote: post #242
tom_ wrote: 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…

> 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? It was not. It was literally a fork of perforce with executable renamed to sd.exe from p4. Command line was pretty much identical.

[deleted]

Re: Microsoft Office migration from Source Depot to Git

#252

Post by tom_ »

nyarlathotep_ wrote: post #243
malkia wrote: post #182

Earlier quoted context omitted.

And often binaries: .exe, .dll, even .pdb files.

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 version of Visual Studio and you're good to go. Doesn't matter if you're not on quite the right point revision or haven't got rough to doing the latest update (or had it forced upon you); the project will still build with the compiler and libraries you got from Perforce, same as for everybody else.

Re: Microsoft Office migration from Source Depot to Git

#253

Post by tom_ »

dh2022 wrote: post #227
masklinn wrote: post #212

Earlier quoted context omitted.

Everything is in P4: you checkout the project to work on it, you have everything. You update, you have everything up to date. All the tools are there, so any part of the pipeline can rely on anything that's checked in. You need an older version, you just check that out and off you go. And you have a single repository to maintain. VCS + Nuget: half the things are in the VCS, you checkout the project and then you have…

I have no idea what environment / team you worked on but nuget is pretty much rock solid. There are no scripts running on a prayer that everything is fetched. Version sync is not a crapshot because nuget versions are updated during merges and with proper merge procedures (PR build + tests) nuget versions are always correct on the main branch. One does not forget what nugets are used: VS projects do that bookkeeping f…

But if you have to do this via Visual Studio, it's no good for the people that don't use Visual Studio.

Also, where does nuget get this stuff from? It doesn't build this stuff for you, presumably, and so the binaries must come from somewhere. So, you just got latest from version control to get the info for nuget - and now nuget has to use that info to download that stuff?

And that presumably means that somebody had to commit the info for nuget, and then separately upload the stuff somewhere that nuget can find it. But wait a minute - why not put that stuff in the version control you're using already? Now you don't need nuget at all.

Re: Microsoft Office migration from Source Depot to Git

#254

Post by connicpu »

tough wrote: post #185
connicpu wrote: post #177

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.

sorry for the tangent, how you deal with AI?

External AI are banned, local or otherwise on-prem models are allowed. We're currently experimenting with some kind of llama instance running on one of our servers, but I personally don't use it much.

Re: Microsoft Office migration from Source Depot to Git

#255

Post by RyJones »

anonymars wrote: post #249
RyJones wrote: post #85

Earlier quoted context omitted.

Probably. A lot of people really loved MSMAIL; not so much Exchange. I have more long, boring stories about projects there, but that’s for another day

Ha, maybe my old memory is rusty, but I feel like I recognize this name and you had an old blog with some quotable Raymond Chen -- one bit I remember was something like "How do you write code so that it compiles differently from the IDE vs the command line?" to which the answer was "If you do this your colleagues will burn you in effigy when they try to debug against the local build and it works fine"

Yup, that’s me.

Re: Microsoft Office migration from Source Depot to Git

#257

Post by barries11 »

int_19h wrote: post #204
barries11 wrote: post #135

Earlier quoted context omitted.

I used Perforce a lot in the 90s, when it was simple (just p4, p4d, and p4merge!), super fast, and never crashed or corrupted itself. Way simpler, and easier to train newbies on, than any of the alternatives. Subdirectories-as-branches (like bare repo + workspace-per-branch practices w/git) is so much easier for average computer users to grok, too. Very easy to admin too. No idea what the current "enterprisey" offeri…

I've used CVS, SVN, TFS, Mercurial, and Git in the past, so I have plenty of exposure to different options. I have to deal with Perforce in my current workplace and I have to say that even from this perspective it's honestly pretty bad in terms of how convoluted things are.

I don't disagree at all--p4 was kick-ass back in the day but the world, and our expectations, have moved on. Plus, they went all high-street enterprisey.

What makes it convoluted? Where did it lose the beat?

Re: Microsoft Office migration from Source Depot to Git

#258

Post by 0points »

chiph wrote: post #237
0points wrote: post #130

Having used vss in the 90s myself, it surprised me it wasn't even mentioned. VSS (Visual SourceSafe) being Microsoft's own source versioning protocol, unlike Source Depot which was licensed from Perforce.

VSS was picked up via the acquisition of One Tree Software in Raleigh. Their product was SourceSafe, and the "Visual" part was added when it was bundled with their other developer tools (Visual C, Visual Basic, etc). Prior to that Microsoft sold a version control product called "Microsoft Delta" which was expensive and awful and wasn't supported on NT. One of the people who joined Microsoft via the acquisition was Br…

Oh, TIL! Thanks for adding that to the story.

Indeed my experiences of vss was also not amazing and certainly got corrupted files too.

Re: Microsoft Office migration from Source Depot to Git

#259

Post by Arainach »

Degorath wrote: post #238
noitpmeder wrote: post #150

Earlier quoted context omitted.

My firm still uses perforce and I can't say anyone likes it at this point. You can almost see the light leaves the eyes of new hires when you tell them we don't use git like the rest of the world.

Can't say anything about perforce as I've never used it, but I'd give my left nut to get Google's Piper instead of git at work :)

Piper's syntax is Perforce syntax.

I moved to Google from Microsoft and back when employee orientation involved going to Mountain View and going into labs to learn the basics, it was amusing to see fresh college hires confused at not-git while I sat down and said "It's Source Depot, I know this!"[1]

[1] https://www.youtube.com/watch?v=dFUlAQZB9Ng

Re: Microsoft Office migration from Source Depot to Git

#260

Post by canucker2016 »

mschuster91 wrote: post #141
canucker2016 wrote: post #123

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…

> A few users complained that Exchange, in essence, was too fast. That is something that's actually pretty common and called "benevolent deception" - it has been discussed on HN some years past, too [1]. [1] https://news.ycombinator.com/item?id=16289380

I wouldn't call either Mail Pump's slow email processing a "benevolent deception", nor Exchange's quick email processing an attempt to be perceived as a fast email server.

In MSMail/Exchange Client/Outlook, the presence of email in the Outbox folder signifies that an email is to be sent, but that the code for sending the email hasn't processed that particular email.

MSMail being slower than Exchange to send email is a leaky abstraction due to software architecture.

Win3.x doesn't support multithreaded apps, using a cooperative multitasking system. Any app doing real work would prevent the user from accessing the system since no user interface events would be processed.

So the Mail Pump would check to see if the system was idle. There are no public or secret/private Windows APIs (despite all the MS detractors) for code to determine if the system is idle - you, the developer, had to fall back to using heuristics. These heuristics aren't fast - you didn't want to declare that the system was idle only to discover the user was in the middle of an operation. So the Mail Pump had to be patient. That meant the email could sit in the outbox for more than a second.

Exchange Server was a server process running on a separate box. When an email client notified the Exchange Server that an email was to be sent (whether via RPC or SMTP command), Exchange Server didn't have to wait in case it would block the user's interaction with the computer. Exchange Server could process the email almost immediately.

But there was a happy resolution to the conundrum - no, the Exchange Server didn't add a delay.

Some architect/program manager had added a "delay before sending/processing" property to the list of supported properties of an email message. The Exchange/Win95/Capone email client didn't use/set this property. But a developer could write an email extension, allow the user to specify a default delay for each outgoing email and the extension could get notified when an email was sent and set this "delay before sending/processing" property, such that Exchange Server would wait at least the specified delay time before processing the email message.

The user who desired an extended delay before their sent email was processed by the Exchange Server, could install this client extension, and specify a desired delay interval.

Outlook eventually added support for this property a few years later.

I notice that Gmail has added support for a delay to enable the user to undo sent emails.

Post reply on HN