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

201–210 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#201

Post by masklinn »

nyarlathotep_ wrote: post #148
dgellow wrote: post #111

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?

Assets, textures, design documents, tools, binary dependencies, etc…

And yes, p4 just rolls with it, git lfs is a creacky hack.

Re: Microsoft Office migration from Source Depot to Git

#202

Post by WorldMaker »

foooorsyth wrote: post #163
AdamN wrote: post #102

I feel like we're well into the longtail now. Are there other SCM systems or is it the end of history for source control and git is the one and done solution?

git by itself is often unsuitable for XL codebases. Facebook, Google, and many other companies / projects had to augment git to make it suitable or go with a custom solution. AOSP with 50M LoC uses a manifest-based, depth=1 tool called repo to glue together a repository of repositories. If you’re thinking “why not just use git submodules?”, it’s because git submodules has a rough UX and would require so much wranglin…

It's interesting to point out that almost all of Microsoft's "augmentations" to git have been open source and many of them have made it into git upstream already and come "ready to configure" in git today ("conical" sparse checkouts, a lot of steady improvements to sparse checkouts, git commit-graph, subtle and not-so-subtle packfile improvements, reflog improvements, more). A lot of it is opt-in stuff because of backwards compatibility or extra overhead that small/medium-sized repos won't need, but so much of it is there to be used by anyone, not just the big corporations.

I think it is neat that at least one company with mega-repos is trying to lift all boats, not just their own.

Re: Microsoft Office migration from Source Depot to Git

#203

Post by int_19h »

MBCook wrote: post #160
israrkhan wrote: post #34

Earlier quoted context omitted.

source depot is (was?) essentially a fork of perforce.

The article mentioned something along those lines, but I’ve never used it either. I’ve only ever really used CVS, SVN, and Git.

Perforce is broadly similar to SVN in semantics, and the same branching logic applies to both. Basically if you have the notion of long-lived main branch and feature branches (and possibly an hierarchy in between, e.g. product- or component-specific branches), you need to flow code between them in an organized way. Forward/reverse integration simply describes the direction in which this is done - FI for main -> feature, RI for feature -> main.

Re: Microsoft Office migration from Source Depot to Git

#204

Post by int_19h »

barries11 wrote: post #135
90s_dev wrote: post #14

I actually remember using Perforce back in like 2010 or something. And I can't remember why or for which client or employer. I just remember it was stupid.

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.

Re: Microsoft Office migration from Source Depot to Git

#205

Post by masklinn »

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

Re: Microsoft Office migration from Source Depot to Git

#206

Post by int_19h »

Freak_NL wrote: post #114
shakna wrote: post #83

Earlier quoted context omitted.

That's still two decades. Git is so popular Microsoft bought one of the major forges 7 years ago. To have never touched it in the last decade? You've got a gap in your CV.

I believe it. If you are a die-hard Microsoft person, your view of computing would be radically different from even the average developer today, let alone devs who are used to using FOSS. Turn it around: If I were to apply for a job at Microsoft, they would probably find that my not using Windows for over twenty years is a gap on my CV (not one I would care to fill, mind).

It would very much depend on the team. There's no shortage of those that ship products for macOS and Linux, and sometimes that can even be the dominant platform.

Re: Microsoft Office migration from Source Depot to Git

#207

Post by int_19h »

senderista wrote: post #59
tikkabhuna wrote: post #51

Earlier quoted context omitted.

I never understood the value of directory mapping when we used Perforce. It only seemed to add complexity when one team checked out code in different hierarchies and then some builds worked, some didn’t. Git was wonderful for having a simple layout.

You might feel differently if you worked on just a few directories in a giant repo. Sparse client views were a great feature of SD.

I'm in exactly this situation with Perforce today, and I still hate it. The same problem OP described applies - you need to know which exact directories to check out to build, run tests etc successfully. You end up with wikis filled with obscure lists of mappings, many of them outdated, some still working but including a lot of cruft because people just copy it around. Sometimes the required directories change over time and your existing workspaces just stop working.

Git has sparse client views with VFS these days.

Re: Microsoft Office migration from Source Depot to Git

#208

Post by jjmarr »

swsieber wrote: post #193
2d8a875f-39a2-4 wrote: post #117

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.

It's existed for a while. Partial clones and LFS.

https://git-scm.com/docs/partial-clone

Re: Microsoft Office migration from Source Depot to Git

#209

Post by dh2022 »

masklinn wrote: post #205
dh2022 wrote: post #195

Earlier quoted context omitted.

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

Post reply on HN