Microsoft Office migration from Source Depot to Git • Hacker News Board

Re: Microsoft Office migration from Source Depot to Git

#211

Post by tom_ » Thu, Jun 12, 2025, 5:25 PM UTC

2d8a875f-39a2-4 wrote: post #167

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.

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, they are less in the habit of putting up with the git style of shit.)

Re: Microsoft Office migration from Source Depot to Git

#212

Post by masklinn » Thu, Jun 12, 2025, 5:27 PM UTC

dh2022 wrote: post #209

masklinn wrote: post #205

Earlier quoted context omitted.

Because it’s way easier if you don’t require every level designer to spend 5 hours recompiling everything before they can get to work in the morning, because it’s way easier to just checkin that weird DLL than provide weird instructions to retrieve it, because onboarding is much simpler if all the tools are in the project, … And it’s no sweat off p4’s back.

Hmm, I do not get it.... "The binaries are checked in the repo so that that the designer would not spend 5 hours recompiling" vs "the binaries come from a nuget site so that the designed would not spend 5 hours recompiling". In both cases the designer does not recompile, but in the second case there are no checked in binaries in the repo... I still think nuget / MAVEN would be more appropriate for this task...

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 to hunt down a bunch of packages from a separate thing (or five), when you update the repo you have to update the things, hopefully you don't forget any of the ones you use, scripts run on a prayer that you have fetched the right things or they crash, version sync is a crapshoot, hope you're not working on multiple projects at the same time needing different versions of a utility either. Now you need 15 layers of syncing and version management on top of each project to replicate half of what just checking everything into P4 gives you for free.

Re: Microsoft Office migration from Source Depot to Git

#213

Post by tough » Thu, Jun 12, 2025, 5:34 PM UTC

Kwpolska wrote: post #192

tough wrote: post #185

Earlier quoted context omitted.

sorry for the tangent, how you deal with AI?

Why would you expect them to? It's really easy to live without AI.

nothing prevents them to run a gpu locally or on their own infra.

I was asking because I wonder what the enterprises that want to both use AI on their workflows like LLM's and have air-gap owned 100% data and pipelines are doing rn.

Feels like one of the few areas where to compete with big labs to me, might be wrong

Re: Microsoft Office migration from Source Depot to Git

#214

Post by rwmj » Thu, Jun 12, 2025, 5:55 PM UTC

dh2022 wrote: post #195

rwmj wrote: post #134

Earlier quoted context omitted.

I've been checking in large (10s to 100s MBs) tarballs into one git repo that I use for managing a website archive for a few years, and it can be made to work but it's very painful. I think there are three main issues: 1. Since it's a distributed VCS, everyone must have a whole copy of the entire repo. But that means anyone cloning the repo or pulling significant commits is going to end up downloading vast amounts of…

Why would someone check binaries in a repo? The only time I came across checked binaries in a repo was because that particular dev could not be bothered to learn nuget / MAVEN. (the dev that approved that PR did not understand that either)

Because it's (part of) a website that hosts the tarballs, and we want to keep the whole site under version control. Not saying it's a good reason, but it is a reason.

Re: Microsoft Office migration from Source Depot to Git

#215

Post by danielodievich » Thu, Jun 12, 2025, 6:00 PM UTC

I want to thank dev leads who trained this green-behind-the-ears engineer on mysteries of Source Depot. Once I understood it, it was quite illuminating. I am glad we only had a dependency on WinCE and IE, and so the clone only took 20 minutes instead of days. I don't remember your names but I remember your willingness to step up and help and onboard new person so they could start being productive. I pay this attitude forward with new hires here in my team no matter where I go.

Re: Microsoft Office migration from Source Depot to Git

#216

Post by hpratt4 » Thu, Jun 12, 2025, 6:02 PM UTC

larrywright wrote: post #158

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.

I used VSS in the 90s as well, it was a nightmare when working in a team. As I recall, Microsoft themselves did not use VSS internally, at least not for the majority of things.

That’s correct. Before SD, Microsoft orgs (at least Office and Windows; I assume others too) used an internal tool called SLM (“slime”); Raymond Chen has blogged about it, in passing: https://devblogs.microsoft.com/oldnewthing/20180122-00/?p=97...

Re: Microsoft Office migration from Source Depot to Git

#217

Post by kccqzy » Thu, Jun 12, 2025, 6:15 PM UTC

Marsymars wrote: post #175

kccqzy wrote: 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 feel like I’ve got an open mind towards processes and tools; the problem with a company using anything other than Git at this point is that unless they have a good explanation for it, it’s not going to be an indicator that the company compared the relative merits of VCS systems and chose something other than Git - it’s going to be an indicator that the company doesn’t have the bandwidth or political will to moderni…

Yeah but as a new hire, one doesn't yet know whether there is a good explanation for using a non-git tool. It takes time to figure that out.

A legacy tool might be bad, or it might be very good but just unpopular. A company that devotes political will to modernize for the sake of modernizing is the kind of craziness we get in the JS ecosystem.

Re: Microsoft Office migration from Source Depot to Git

#218

Post by kccqzy » Thu, Jun 12, 2025, 6:17 PM UTC

DanielHB wrote: post #154

kccqzy wrote: 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.

Oh a month is definitely enough time.

Re: Microsoft Office migration from Source Depot to Git

#219

Post by kccqzy » Thu, Jun 12, 2025, 6:18 PM UTC

jayd16 wrote: post #190

kccqzy wrote: 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.

A craftsman appreciates good tools.

Is git a good tool then? Not necessarily. Some still think hg is better. Others think newer tools like jj are even better while being git compatible.

Re: Microsoft Office migration from Source Depot to Git

#220

Post by suriya-ganesh » Thu, Jun 12, 2025, 6:19 PM UTC

rwmj wrote: post #134

qiine wrote: post #128

Earlier quoted context omitted.

why is this still the case ?

I've been checking in large (10s to 100s MBs) tarballs into one git repo that I use for managing a website archive for a few years, and it can be made to work but it's very painful. I think there are three main issues: 1. Since it's a distributed VCS, everyone must have a whole copy of the entire repo. But that means anyone cloning the repo or pulling significant commits is going to end up downloading vast amounts of…

This is a problem that occurs across game development to ML datasets.

We built oxen to solve this problem https://github.com/Oxen-AI/Oxen (I work at Oxen.ai)

Source control for large data. Currently our biggest repository is 17 TB. would love for you to try it out. It's open source, so you can self host as well.