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

131–140 of 290 posts

Re: Microsoft Office migration from Source Depot to Git

#131

Post by daemin »

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…

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

Personally I kind of still want some sort of server based VCS which can store your entire companies set of source without needing to keep the entire history locally when you check out something. But unfortunately git is still good enough to use on an ad-hoc basis between machines for me that I don't feel the need to set up a central server and CI/CD pipeline yet.

Also being able to stash, stage hunks, and interactively rebase commits are features that I like and work well with the way I work.

Re: Microsoft Office migration from Source Depot to Git

#132

Post by daemin »

dazzawazza wrote: post #97
bob1029 wrote: post #92

Earlier quoted context omitted.

Perforce is really nice if you need to source control 16k textures next to code without thinking too much about it. Git LFS absolutely works but it's more complicated and has less support in industry tooling. Perforce also makes it easier to purge (obliterate) old revisions of files without breaking history for everyone. This can be invaluable if your p4 server starts to run out of disk space. The ability to lock fil…

I agree with everything you say except git-lfs works. For modern game dev (where a full checkout is around 1TB of data) git-lfs is too slow, too error prone and too wasteful of disk space. Perforce is a complete PITA to work with, too expensive and is outdated/flawed for modern dev BUT for binary files it's really the only game in town (closely followed by svn but people have forgotten how good svn was and only remem…

Sounds like the filesystem filter is required for the files in the repository and not just the metadata in the .git folder.

Re: Microsoft Office migration from Source Depot to Git

#133

Post by robin_reala »

namdnay wrote: post #120
codeulike wrote: post #108

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?

I guess you’re talking about Rational Rose? I had the misfortune of using that at my first industry job (fintech in 2004).

Re: Microsoft Office migration from Source Depot to Git

#134

Post by rwmj »

qiine wrote: post #128
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

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 binaries. If you can directly copy the .git dir to the other machine first instead of using git's normal cloning mechanism then it's not as bad, but you're still fundamentally copying everything:

  $ du -sh .git
  55G .git
2. git doesn't "know" that something is a binary (although it seems to in some circumstances), so some common operations try to search them or operate on them in other ways as if they were text. (I just ran git log -S on that repo and git ran out of memory and crashed, on a machine with 64GB of RAM).

3. The cure for this (git lfs) is worse than the disease. LFS is so bad/strange that I stopped using it and went back to putting the tarballs in git.

Re: Microsoft Office migration from Source Depot to Git

#135

Post by barries11 »

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" offering is like, though.

For corporate teams, it was a game changer. So much better than any alternative at the time.

We're all so used to git that we've become used to it's terribleness and see every other system as deficient. Training and supporting a bunch of SWE-adjacent users (hw eng, ee, quality, managers, etc) is a really, really good reality check on how horrible the git UX and datamodel is (e.g. obliterating secrets--security, trade, or PII/PHI--that get accidentally checked in is a stop-the-world moment).

For the record, I happily use git, jj, and Gitea all day every day now (and selected them for my current $employer). However, also FTR, I've used SCCS, CVS, SVN, VSS, TFS and MKS SI professionally, each for years at a time.

All of the comments dismissing tools that are significantly better for most use cases other than distributed OSS, but lost the popularity contest, is shortsighted.

Git has a loooong way to go before it's as good in other ways as many of its "competitors". Learning about their benefits is very enlightening.

And, IIRC, p4 now integrates with git, though I've never used it.

Re: Microsoft Office migration from Source Depot to Git

#136

Post by School-Cotton »

rswail wrote: post #121
codeulike wrote: post #108

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…

Which is exactly how CVS (and its predecessors RCS and SCCS) worked. They were file based revision control, not repository based. SVN added folders like trunk/branches/tags that overlaid the file based versioning by basically creating copies of the files under each folder. Which is why branch creation/merging was such a complicated process, because if any of the files didn't merge, you had a half merged branch source…

I am quite sure that you can edit files in an svn repo to your heart’s content regardless of whether anyone else is editing them on their machine at the same time.

Re: Microsoft Office migration from Source Depot to Git

#137

Post by RyJones »

canucker2016 wrote: post #123
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

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.

Re: Microsoft Office migration from Source Depot to Git

#139

Post by tamlin »

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.

Yes, I used VSS as a solo developer in the 90s. It was a revelation at the time. I met other VCS systems at grad school (RCS, CVS).

I started a job at MSFT in 2004 and I recall someone explaining that VSS was unsafe and prone to corruption. No idea if that was true, or just lore, but it wasn't an option for work anyway.

Re: Microsoft Office migration from Source Depot to Git

#140

Post by airstrike »

> 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 a ragtag team of hungry devs.

Post reply on HN