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

141–150 of 245 posts

Re: Scaling Mercurial at Facebook

#141

Post by ahomescu1 »

mikegioia wrote: post #7
JoshTriplett wrote: post #5

Earlier quoted context omitted.

Does the standard branch workflow still expect you to have a separate repository and directory per branch? I don't care about plugins, here; if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. Likewise, does the standard workflow still intentionally make it painful to rearrange changes in your local repository to construct a series of patches?…

I work in several branches in the same file system directory. Branching in mercurial is as simple as "hg branch branchname", and switching branches is just "hg update branchname". As long as you make sure you commit everything you can easily work in one directory. Merging changes across branches is easy too, as you only need to specify the revision number.

If you push while having open local branches, they get pushed to the remote (or at least that's how it was last time I used them). That's not what you want, in most cases (git branches are local).

Re: Scaling Mercurial at Facebook

#142

Post by zaphar »

barrkel wrote: post #118
zaphar wrote: post #71

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

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

The risk you describe is a real risk. But we mitigate it at google with strong code review and high bars for our our core libraries teams.

All of our core libs are owned by a team and you can't make changes to them without permission and a thorough code review. Our perforce infrastructure allows us to prevent submits that don't meet this criteria so we get the benefits of ownership only we use ACL's instead of seperate repo's. It has so far worked very well for us.

Re: Scaling Mercurial at Facebook

#143

Post by zaphar »

enneff wrote: post #115
X-Istence wrote: post #97

Earlier quoted context omitted.

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.

Not just make the change in one fell swoop but also rollback the change in one fell swoop if it turns out to have broken something.

Re: Scaling Mercurial at Facebook

#144

Post by skj »

moron4hire wrote: post #130
enneff wrote: post #117

Earlier quoted context omitted.

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

Perhaps I don't understand the whole situation here. I hear "all of our code is in one repository" and I think "GMail and Google Maps are in the same repository, in the same repository with GoLang, in the same repository with AdWords." The more I think about it, the more I think your post reveals a lack of maturity in our industry that lends credence to the pro-engineering-licensing argument that I've argued against…

Go is hosted publicly (on googlecode) and adwords is supersecret or some nonsense and non adwords Googlers can't see it.

But gmail and maps...well, they share a lot of code! For instance, they both run on web servers.

Re: Scaling Mercurial at Facebook

#145

Post by vishnugupta »

Crito wrote: post #24

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

Amazon ran into this exact problem with Perforce. They threw hardware at the problem for a while but, fortunately, soon realized that they weren't getting anywhere with that. They were trying to work "with" git i.e., with one repo per service and were in migration phase when I left.

Re: Scaling Mercurial at Facebook

#146

Post by sdesol »

durin42 wrote: post #29
Crito wrote: post #24

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

> An example of building multi-repo infrastructure for large projects with git is Android's repo: http://en.wikipedia.org/wiki/Repo_(script) Repo is just one example though; other, better, solutions are very possible. I'm curious - do you know of any such better examples, or is this merely a theoretical "I feel like we could do better" statement?

My product is a read-only solution, which simplifies my technical requirements, but it basically de-emphasizes the repository, by making branches the focal point. If you have ever worked with UCM ClearCase by IBM, you'll understand that everything works at the stream/branch level. When you create a new UCM project, you construct it by picking points (baselines) from streams/branches, which can come from different pvobs (repositories). And UCM activities, which are like commits, can contain changes from different branches from different pvobs (repositories).

I personally think, if you want to take Git to the next level, you'll have to implement something like UCM ClearCase activities and projects. Commits should not be bound to a single repository and it should be very easy for people to say I want to create a product that uses starting points from branches x, y and z without having to think about what repo they belong to.

I have a couple examples that shows how my product de-emphasizes the repository. In the following example, you can see my Commits Finder tool, which lets you search for commits by branches.

http://ny.testdrive.gitsense.com/index?#pid=13&cid=20&trail=

As you can see, the search results shows commits from 10 different branches from 7 different repositories. My other example is my GitHub Pulls Finder tool which lets you search for pull requests by branches.

http://ny.testdrive.gitsense.com/index?#pid=24&cid=29&trail=

Here you can see pull requests from 6 different branches from 6 different repos.

Since my solution is read-only, it simplified things, but I don't think creating a nice layer on top of sub-modules would be be that technically challenging. And it's the direction I would personally go if I wanted to make Git more enterprise friendly.

Re: Scaling Mercurial at Facebook

#147

Post by ryanobjc »

greatsuccess wrote: post #128

Partitioning is the answer. In a repo that size 99% of the history is useless to anyone. You wouldnt manage a database like this so why force SCM down this path? If they used git with say only the last year of history in it they would be having zero issues.

While true, you only need 1% of the history, the problem is WHICH 1% and when?

Tracking down bugs in the history is a huge deal, and its often absolutely critical. And yes, regressions go past 1 year.

Re: Scaling Mercurial at Facebook

#148

Post by sandGorgon »

zaphar wrote: post #136
igravious wrote: post #94

Earlier quoted context omitted.

What version control system do you use, or is it a secret? Perforce? Git? I've seen Linus's talk that he gave about Git at the GooglePlex so perhaps you use Git. If so, how have you not run into Facebook's scaling issues?

This question is actually really complicated to answer. The short answer is that we run perforce. The long answer is that we run perforce with a bunch of caching servers and custom stuff in front of it and some special client wrappers. In fact there is more than one client wrapper. One of them uses git to manage a local thin client of the relevant section of the repo and sends the changes to perforce. This is the one…

Interesting, has Google made the client parts open source?

It would be great if someone used that to write a high performance git server.

Could they?

Re: Scaling Mercurial at Facebook

#149

Post by dgesang »

novaleaf wrote: post #114
agwa wrote: post #39

For 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.

Don't believe the hype. hg will be around for some time.

Re: Scaling Mercurial at Facebook

#150

Post by dgesang »

ZenoArrow wrote: post #73
VladRussian2 wrote: post #28

Earlier quoted context omitted.

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

And there is also https://rhodecode.com/
Post reply on HN