Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling Mercurial at Facebook

code.facebook.com

Post reply on HN
Print view View original

71–80 of 245 posts

Re: Scaling Mercurial at Facebook

#71

Post by zaphar »

danielrhodes wrote: post #33

"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 everywhere run all the tests for the entire codebase and then submit the changes thus accomplishing an API change safely in weeks that might take months otherwise with higher risk.

Keep in mind that the API change equals real money in networking cost so time to ship is a very real factor.

It sounds like facebook also has a very real time to ship need for even core libraries.

Re: Scaling Mercurial at Facebook

#72

Post by ngoldbaum »

VladRussian2 wrote: post #61
Crito wrote: post #56

Earlier quoted context omitted.

That is certain. If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. The problem is "how do you grow even further ?" There isn't a perfect solution to that (yet), but I think the only existing workable (although absolutely imperfect) solution is splitting your codebase into many small repos. Thankfully very few companies need to worry about this prob…

> If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. that is the problem - single logical repo in Perforce/Mercurial does mean single physical repo. Which obviously causes issues at very large scale. Even at normal enterprise scale :) Git solves it through kind of distributed scaling where many operations can be performed on local physical repos wit…

Mercurial is a DVCS, just like git. It has no concept of a central server.

Re: Scaling Mercurial at Facebook

#73

Post by ZenoArrow »

VladRussian2 wrote: post #28
LukeHoersten wrote: post #3

I love the Mercurial community. We use Mercurial at work and I'm able to get instant support in IRC for any issue we have with an awesome signal/noise ratio. I'm glad Facebook is contributing back so much as well. My suspicion is that open source projects tend towards Git because of GitHub but I think a lot of companies who don't have the option of external code hosting lean towards Mercurial. All anecdotal observati…

>My suspicion is that open source projects tend towards Git because of GitHub but I think a lot of companies who don't have the option of external code hosting lean towards Mercurial. GitHub is a consequence not the cause (ponder for a moment why there is no MercurialHub...) It is about ability to choose best source control tool for multi-versioned distributed concurrent development. Open source devs have such choice…

There is a well used "MercurialHub", it's called BitBucket: https://bitbucket.org/

It supports Git now as well, but it was only for Mercurial use when it started.

Re: Scaling Mercurial at Facebook

#74

Post by Maarten88 »

boyter wrote: post #63
mindjiver wrote: post #38

Earlier quoted context omitted.

I read somewhere(?) that they where running Perforce with some internal tooling built on top of it.

I saw/heard that as well (hopefully someone can come up with the link). Things like Windows/Office apparently are in a custom perforce. I believe that they do use TFS on a lot of the internal projects though and that Visual Studio is now done in TFS.

Here is a link about TFS use inside Microsoft: http://blogs.msdn.com/b/visualstudioalm/archive/2013/08/20/t...

Apparently they use several large TFS instances.

Re: Scaling Mercurial at Facebook

#76

Post by charlesma »

VladRussian2 wrote: post #61
Crito wrote: post #56

Earlier quoted context omitted.

That is certain. If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. The problem is "how do you grow even further ?" There isn't a perfect solution to that (yet), but I think the only existing workable (although absolutely imperfect) solution is splitting your codebase into many small repos. Thankfully very few companies need to worry about this prob…

> If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. that is the problem - single logical repo in Perforce/Mercurial does mean single physical repo. Which obviously causes issues at very large scale. Even at normal enterprise scale :) Git solves it through kind of distributed scaling where many operations can be performed on local physical repos wit…

> With centralized solutions, like Perforce, Mercurial, etc...

I think you're incorrectly putting mercurial and perforce in the same bucket. Mercurial is a lot more like Git than perforce in that it's a DVCS. Facebook made it scale by using a lot of centralized caching, but most operations (diff, looking through history, branching, etc) can be done locally.

Re: Scaling Mercurial at Facebook

#77

Post by garenp »

markcampbell wrote: post #35
georgemcbay wrote: post #25

Earlier quoted context omitted.

I know nothing of the code Facebook is hosting, but one fairly obvious general benefit of having things in a single repository is that you can use relative paths to link dependent projects, like if you have a directory structure such as: libs libs/mylib apps apps/myapp then myapp can reference library mylib via ../../libs/mylib If all of these things are in separate repositories, all bets are off about how their path…

There's a solution to this. Git submodules.

Sometimes the cure is worse than the disease.

Re: Scaling Mercurial at Facebook

#78

Post by ZenoArrow »

moron4hire wrote: post #27

> "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…

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 of the Facebook code base.

Re: Scaling Mercurial at Facebook

#79

Post by durin42 »

gecko wrote: post #58
Uchikoma wrote: post #43

Earlier quoted context omitted.

Let me translate: "if this tool is not exactly like Git, I will not use it".

That sentiment comprises a truly mindblowing number of "bug" reports that hit the Mercurial mailing list every month. I honestly wonder sometimes if I'm simply forgetting how CVS users did the same thing when Subversion shipped and I forgot about it/missed it, or what.

svn was designed to be "CVS done right," which informed a lot of the design and workflow to the point that some CVS misfeatures only got carried through by virtue of that mandate.

(Source of this assertion is prolonged discussions with sussman, one of the early svn authors.)

Re: Scaling Mercurial at Facebook

#80

Post by VladRussian2 »

ngoldbaum wrote: post #72
VladRussian2 wrote: post #61

Earlier quoted context omitted.

> If you are trying to run at a very large scale with a single repo, Perforce (or apparently Mercurial) is the way to go. that is the problem - single logical repo in Perforce/Mercurial does mean single physical repo. Which obviously causes issues at very large scale. Even at normal enterprise scale :) Git solves it through kind of distributed scaling where many operations can be performed on local physical repos wit…

Mercurial is a DVCS, just like git. It has no concept of a central server.

>Mercurial is a DVCS

my bad. 5+ years since i worked with Mercurial. Digging deep into painful memories, my Mercurial PTSD from that time is absence of in-repo branching - need to clone which is a killer for very large repo we had and no partial commits - again a killer aggravated by the above mentioned absence of in-repo branches. Both issues made working with large repo unreasonably and unnecessary hard.

Post reply on HN