Live data from Hacker News

Microsoft Office migration from Source Depot to Git

danielsada.tech

191–200 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#191

Earlier quoted context omitted.

We used it. We knew no better. It was different then, you might not hear about alternatives unless you went looking for them. Source Safe was integrated with Visual Studio so was an obvious choice for small teams. Get this; if you wanted to change a file you had to check it out. It was then locked and no-one else could change it. Files were literally read only on your machine unless you checked them out. The 'one at…

I remember a big commercial SCM at the time that had this as an option, when you wanted to make sure you wouldn’t need to merge. Can’t remember what it was called, you could “sync to file system” a bit like dropbox and it required teams of full time admins to build releases and cut branches and stuff . Think it was bought by IBM?

ClearCase?

Re: Microsoft Office migration from Source Depot to Git

#192
post #185

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?

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

Re: Microsoft Office migration from Source Depot to Git

#193

Always nice to read a new retelling of this old story. TFA throws some shade at how "a single get of the office repo took some hours" then elides the fact that such an operation was practically impossible to do on git at all without creating a new file system (VFS). Perforce let users check out just the parts of a repo that they needed, so I assume most SD users did that instead of getting every app in the Office sui…

I'm a bit surprised git doesn't offer a way to checkout only specific parts of the git tree to be honest. It seems like it'd be pretty easy to graft on with an intermediate service that understands object files, etc.

Re: Microsoft Office migration from Source Depot to Git

#194
post #185

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?

Presumably they don't use it.

Re: Microsoft Office migration from Source Depot to Git

#195
post #134
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…

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)

Re: Microsoft Office migration from Source Depot to Git

#196
post #151

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.

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.

Perforce is sufficiently idiosyncratic that it's kinda annoying even when you remember the likes of SVN. Coming to it from Git is a whole world of pain.

Re: Microsoft Office migration from Source Depot to Git

#198
post #131

Earlier quoted context omitted.

Some companies have developed their own technology like VFS for use with Perforce, so you can check out the entire suite of applications but only pull the files when you try to access them in a specific way. This is a lot more important in game development where massive source binary assets are stored along side text files. It uses the same technology that's built into Windows that the remote drive programs (probably…

Doesn’t SVN let you check out and commit any folder or file at any depth of a project you choose? Maybe not the checkouts and commit, but that log history for a single subtree is something I miss from the SVN tooling.

You can indeed. The problem with this strategy is that now you need to maintain the list of directories that needs to be checked out to build each project. And unless this is automated somehow, the documentation will gradually diverge from reality.

Re: Microsoft Office migration from Source Depot to Git

#199

Earlier quoted context omitted.

I doubt most teams ever used it. I spent a couple years at Microsoft and our team used Source Depot because a lot of people thought that our products were special and even Microsoft's own source control (TFS at the time) wasn't good enough. I had used TFS at a previous job and didn't like it much, but I really missed it after having to use Source Depot.

I was surprised that TFS was not mentioned in the story (at least not as far as I have read). It should have existed around the same time and other parts of MS were using it. I think it was released around 2005 but MS probably had it internally earlier.

TFS was used heavily by DevDiv, but as far as I know they never got perf to the point where Windows folk were satisfied with it on their monorepo.

It wasn't too bad for a centralized source control system tbh. Felt a lot like SVN reimagined through the prism of Microsoft's infamous NIH syndrome. I'm honestly not sure why anyone would use it over SVN unless you wanted their deep integration with Visual Studio.

Re: Microsoft Office migration from Source Depot to Git

#200

Earlier quoted context omitted.

Perforce is used in game dev, animation, etc. git is pretty poor at dealing with lots of really large assets

I've heard this about game dev before. My (probably only somewhat correct) understanding is it's more than just source code--are they checking in assets/textures etc? Is perforce more appropriate for this than, say, git lfs?

I'm not sure about the current state of affairs, but I've been told that git-lfs performance was still not on par with Perforce on those kinds of repos a few years ago. Microsoft was investing a lot of effort in making it work for their large repos though so maybe it's different now.

But yeah, it's basically all about having binaries in source control. It's not just game dev, either - hardware folk also like this for their artifacts.

Post reply on HN