Hacker News Reader

Comment by kccqzy | Hacker News Reader

It's a shame that Dropbox abandoned Mercurial for Git. With both Facebook and Google contributing to better support for monorepos in Mercurial, Mercurial seems like a better choice for big monorepos.

View on HN

Huh? I don’t know about Facebook but Google for sure does not use Mercurial as monorepo backend (nor does it use Git). There are Git and Mercurial-alike clients to interface with the in-house backend which is a Perforce like thing. Neither Git nor Mercurial would be fun to use at Google scale. Dropbox has a much smaller monorepo hence they can clone the whole Git thing on developer machines. I assume doing the same with Mercurial is impractical as no one has patience for something that slow.

Google has a mercurial front-end to their "Perforce-ish" like server

Yes, that’s what I said in the above comment. They have a git frontend as well. I’m sure someone at Google has made one-off front ends for other random stuff as well. Point is, the monorepo isn’t Mercurial nor git, whereas for Dropbox it is git (and likely Mercurial doesn’t scale for that use case), which was the point (“shame it’s not mercurial”) in the original comment I was responding to.

At least two years ago, Google seemed to be driving an effort to move away from Piper and to Mercurial - not just a frontend (https://groups.google.com/forum/#!topic/mozilla.dev.version-...). They would need to build a bunch of custom extensions for that to work, and they've open sourced some.

But I have no idea what came of that effort.

I should clarify my comment by saying monorepo-related Mercurial improvements benefit not just those monorepos backed by Mercurial, but also where Mercurial is "just" a front end to a different system. I mean just think about it, what does a front end in this case really mean? When you run a command like `hg log` how much of the original Mercurial code are you running? Do you design an entirely different system that happens to share the same command-line syntax as the original Mercurial, or do you emulate the .hg folder format and run the original Mercurial code, or somewhere in between? Thinking about this problem would shed more light on why Google's work on Mercurial benefits everyone else with a big monorepo even though Google is "just" using Mercurial as a front end.

And both Facebook and Google have contributed to Mercurial on this front, though admittedly Facebook did more work than Google did. I know the tree manifest feature (https://www.mercurial-scm.org/wiki/TreeManifestPlan) is done by Google and upstreamed, and it benefits every repo with millions of files. (Just clone the hg repository and search for commits with a google.com author email and see what kind of commits they are.)

Sure, but still in Google/Facebook case there’s a centralized backend that does the day to day operations that you invoke from your laptop. In Dropbox case, it is just a local git repo that you push to server only when you want to land a change; just like whatever one does with GitHub, but quite a big one, so the use case is quite different from F/G, which is what I was getting at. In principle maybe you could do it, that’d require quite a big investment in effectively rebuilding mercurial though.

Facebook has a Mercurial clone named EdenSCM[1], which includes a scalable backend named Mononoke[2].

[1] https://github.com/facebookexperimental/eden

[2] https://github.com/facebookexperimental/eden#mononoke

Reply on news.ycombinator.com