Hacker News Reader

Comment by jeffbee | Hacker News Reader

Anyone know if they're still on Mercurial?

“Yes”, but with custom server, custom virtual filesystem layer, and heavily-tweaked client — https://github.com/facebookexperimental/eden

They also stopped participating in upstream mercurial development, google is pretty much the only major corporate contributor and steward of the project at this point.

I can't say for sure, but I'd be incredibly surprised if they weren't. What else would they be on? (Don't say Git, they tried to make Git scale for their monorepo and it would have required a lot of changes that the Git community wasn't interested in.)

Perforce is still popular.

I think FB and Google both surpassed Perforce's scale a long time ago.

I've heard all these stories about build servers or source control servers where, for the longest time, the solution to scalability problems was to throw larger machines at it. At some point the machines have well into the TBs of RAM, each, and it becomes a major priority to make the system distributed.

Perforce scales the best of the bunch.

It doesn't matter if you're the best if you're not good enough.

That's why neither Google nor Facebook use Perforce for most of their code. The repos are just too large.

True, but the terminal scale of Perforce at Google was very impressive, and shows that it can handle pretty much anything that 99.9% of companies would need.

Sure, but Facebook is absolutely in that 0.1%.

What makes you say it's not?

Personal conversations with people who used to run Perforce at Google.

Back when Google was still at Perforce, I used to go to perforce.com to read about how your engineers would never ever wait for Perforce, while waiting for Perforce.

The Perforce servers were… large. And backed by large, extremely expensive SANs that worked with RAM as backing store. Yet, it was slow as molasses at Google's scale.

Perforce at Google scale in 2010 was "slow" in that it was orders of magnitude faster than git is on much smaller repos today. The only thing that git is really faster for is branching, which is something I almost never wanted to do with Perforce anyway. Git feels fast because it either front-loads all the pain (with checkouts) or defers it (with unexpected runs of git gc) but it doesn't really scale. That's why git users are so vocally opposed to monorepos.

As a committed monorepo opponent, that's not why. "Why" is that it's not possible for a monorepo to have meaningful history. If you don't want to have meaningful history, you're crippling yourself, but you also shouldn't use Git; there are better tools for version control with bad history.

Ah so I guess it's "not possible" that Google has a meaningful history of their source code and I guess their project, arguably among largest and most profitable of all time, is "crippled". Weird. I wonder how they get anything done over there.

Google is very unimpressive; the only way I can think of in which they are even tangentially associated with good engineering practices is, well, employing Junio Hamano to, basically, curate the meaningful history of Git.

Google talked about Piper (its home-built Perforce replacement) in 2015. See:

- https://www.youtube.com/watch?v=W71BTkUbdqE

- https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...

Microsoft uses git for all its Windows development, which is a pretty big scale (the repo was 300GB back in 2017)

Yep, and they've had to add support for several features that Facebook added to Mercurial years earlier.

From what I understand, Microsoft "took Git and ran with it" the same way that Facebook did with Mercurial, or that Google did with Perforce. The command-line front-end tools are recognizably Git, but the underlying system is radically different.

Google's main repo was 86TB in January 2015.

Is this 86TB of files at that time? Or 86TB of files cumulatively over time + metadata?

> it would have required a lot of changes that the Git community wasn't interested in

Can you expand on this? I've thought partial checkouts are accepted and the user facing part even has been released with 1.7?

This goes back to 10 years ago now. It’s nice to see some improvement, but 10 years ago there was very little interest in these sorts of problems. The literal response to FB performance tests was “you’re doing it wrong, don’t use a monorepo.”

It shouldn’t be a surprise that FB decided to go elsewhere.

Fair point, years ago the situation was different. Nowadays really large scale git repos like Windows exist, and work by Jonathan Tan and others has made git more compatible with monorepos.

Reply on news.ycombinator.com