According to this page, Mercurial project leader is currently working for Facebook: http://mercurial.selenic.com/wiki/mpm
Facebook took the Mercurial path about 2 year ago, they hired some core devs one year later to secure and speed up development.
Scaling Mercurial at Facebook
111–120 of 245 posts
Re: Scaling Mercurial at Facebook
#112Earlier quoted context omitted.
To be honest, whilst we have no way to accurately determine whether the code is a mess without a chance to see it, the most surprising line of this article (in my opinion) was that the code base was larger than the Linux kernel. I'm not seeing anything on the front end that would warrant such complexity, guessing a large chunk of the code base is server code. Would be interested in reading a summary of the components…
This rather surprised me as well. I tend to think of the Linux kernel as one of the larger single code-bases out there. Am I wrong?
It's one of the largest open source projects perhaps. But when you get into a large company like facebook who creates a hell of a lot of different things the numbers are way higher.
Re: Scaling Mercurial at Facebook
#113Earlier quoted context omitted.
I am sure Mercurial has always had (named) in-repo branches, so you were using Mercurial in strange manner.
There was a time when the developers advised using parallel clones rather than named branches, though. I never really understood why. These days, the standard practice is probably to use bookmarks, which are more or less like Git branches.
These days, the standard practice is probably to use bookmarks, which are more or less like Git branches.
No. You have the choice to use either named branches or bookmarks, and which one you choose is a matter of your workflow. Note that even a Git-like workflow does not necessarily require the use of bookmarks.
Mercurial is still designed under the assumption that people will use named branches and the Git-like aspects of bookmarks exist to ease transition from Git: http://www.selenic.com/pipermail/mercurial/2014-January/0464...
Personally, I use Fossil-like private branches [1] in order to facilitate local work that I may still want to reorganize before pushing it to a shared server; I use bookmarks solely for local tags.
[1] Emulated by putting a named branch in the secret phase. I actually have a simple extension to automatically make all branches that start with a dot (e.g, ".tempstuff") secret.
Re: Scaling Mercurial at Facebook
#114For some context of why Facebook choose Hg over Git, here's the mailing list thread where Facebook initially reached out to the Git developers: http://thread.gmane.org/gmane.comp.version-control.git/18977...
I personally love mercurial (simpler than git), and have been a bit nervious over the last year or so with the mindshare shift to git.
So hearing about this (FB all in with hg) ensures that hg won't be falling behind... at least in the nearterm.
Re: Scaling Mercurial at Facebook
#115Earlier quoted context omitted.
We use one repository at google. We've found that "Removing the ability to make large scale changes easy and thus increasing reliability." isn't actually correct. As an example, most of your codebase uses an RPC library. You discover an issue with that library that requires an API change which will reduce network usage fleetwide by an order of magnitude. With a single repo it's easy to automate the API change everywh…
You don't need a single repo to be able to run tests across all existing tools. If you have proper dependency management set up, you make the change, push it and a CI server goes off and builds it, then all dependent projects get rebuilt and tested...
No, but you do need a single repo if you want to make the API change and update all the dependencies in one fell swoop.
Re: Scaling Mercurial at Facebook
#116"We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, t…
We use one repository at google. We've found that "Removing the ability to make large scale changes easy and thus increasing reliability." isn't actually correct. As an example, most of your codebase uses an RPC library. You discover an issue with that library that requires an API change which will reduce network usage fleetwide by an order of magnitude. With a single repo it's easy to automate the API change everywh…
thanks for this remark. i've been struggling with the choice of splitting into multi-repos, but have similar thoughts to what you just confirmed.
Re: Scaling Mercurial at Facebook
#117> "Our code base has grown organically and its internal dependencies are very complex." That's a polite way of saying "we write shitty code without any sort of plan." > "Splitting it up would make large, atomic refactorings more difficult" Actually, it's the other way around. Modularity tends to obviate the need for large, atomic refactorings. And what, exactly, is the meaning of these graphs? This is leading me to b…
> Modularity tends to obviate the need for large, atomic refactorings.
"Tends to".
But when you're dealing with code at Facebook's scale, things that "tend not to happen" actually happen quite a lot. In fact, you must plan for them as a matter of course.
So yes, modularity is great, and I because I'm a nice guy I assume Facebook aren't a pack of idiots and that they're writing nice modular code. But even if that's the case, in an organization of Facebook's size you still need to make widespread, atomic refactorings on a regular basis.
I know this from experience, because I work at Google (much larger codebase than Facebook) on a low-level piece of our software stack. We face these issues regularly and while working in a single repo has its drawbacks, it also has real advantages.
Re: Scaling Mercurial at Facebook
#118"We could have spent a lot of time making it more modular in a way that would be friendly to a source control tool, but there are a number of benefits to using a single repository. Even at our current scale, we often make large changes throughout our code base, and having a single repository is useful for continuous modernization. Splitting it up would make large, atomic refactorings more difficult. On top of that, t…
We use one repository at google. We've found that "Removing the ability to make large scale changes easy and thus increasing reliability." isn't actually correct. As an example, most of your codebase uses an RPC library. You discover an issue with that library that requires an API change which will reduce network usage fleetwide by an order of magnitude. With a single repo it's easy to automate the API change everywh…
What you've got here is a different kind of tradeoff.
Normally, libraries are written under the assumption that clients cannot be modified or updated when the library changes. This brings in the concept of a breaking change, and a set of design constraints for versioning. For example, modifying interfaces becomes verboten, final methods start becoming preferable to virtual methods, implementation detail classes require decreased visibility, etc.
The advantage is that library producers are decoupled from consumers. Ideally the library is developed with care, breaking changes between major versions are minimized, and breakage due to implementation changes are minimal owing to lack of scope (literally) for clients to depend on implementation details.
But under the model you describe, you're leveraging the Theory of the Firm as much as possible - specifically, reducing the transaction costs of potentially updating clients of libraries simultaneously with the library itself.
The downside is the risk of unnecessary coupling between clients and libraries - the costs of a breaking change aren't so severe, so the incentive to avoid them is lessened, and so the abstraction boundaries between libraries is weakened. If the quality of engineers isn't kept high, or they don't know enough about how and why to minimize coupling, there's a risk of a kind of sclerosis that increases costs of change anyway.
Re: Scaling Mercurial at Facebook
#119Earlier quoted context omitted.
I suspect that the kernel is one of the only things running on Facebook's servers that they didn't write from scratch. Alexandrescu has mentioned that a 1% speedup to HHVM saves FB about $100k per year, and at that sort of scale it's pretty easy for reinventing every wheel to make sense.
right, so why can't projects like that exiat in their own repository? what keeps HHVM and Facebook tightly coupled?
Some of them are.
> We already have some of the easily separable projects in separate repositories, like HPHP
http://article.gmane.org/gmane.comp.version-control.git/1897...
Presumably some parts aren't so isolated.
Re: Scaling Mercurial at Facebook
#120I wrote a comment about the scaling of repositories (and specifically Facebook's issues) a few days ago that was wiped out by the HN crash, but I've managed to recover it from HNSearch: Facebook's problem is that they were trying to scale with Git improperly. With conventional CVS[sic] systems like Perforce, you can scale a single repo nearly as large as any company will need. Emphasis on that nearly. At a certain po…
I think they just want to modify Git and don't have any solid C developers that can make such things. So they turned to a python solution which is perfectly fine.
But webkit, and chromium, as well as other GIANT projects which as far as I know are larger then Facebook seem to work fine on Git.