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

191–200 of 245 posts

Re: Scaling Mercurial at Facebook

#191

Post by tonfa »

ahomescu1 wrote: post #181
tonfa wrote: post #169

Earlier quoted context omitted.

I think you are confused, git and hg branches are very similar (I'd try to help but I'm not sure what the confusion is).

It's simple: I created a local branch, worked on it, then tried the git workflow: 1. Switch to the default branch 2. Cherry-pick (with the equivalent hg command) my changes from my own branch into default 3. Push the changes to the remote repo What happened was that my local branch got pushed to the server, along with the default one. With git this wouldn't happen, it would push the local master to the remote master.

Yes, by default all branches are pushed, (you would have to use --force if it creates new heads, and --new-branch to push new named branches). But I really don't see how it makes anything "server" or "client" side.

(and you could in any case decide to push just default: hg push -r default)

Re: Scaling Mercurial at Facebook

#192

Post by k_bx »

JoshTriplett wrote: post #124
wtetzner wrote: post #47

Earlier quoted context omitted.

I don't think he was talking about performance. I think he meant lightweight in the sense that a branch (in git) is just a pointer to a commit. It's conceptually lightweight.

Both: it's conceptually lightweight, and because of that "pointer to a commit" structure it's also effectively free to create and move around branches.

Why is mercurial branches ineffective to move around branches? If I'm not mistaken, if you want to move commits from one branch to another you do absolutely the same rebase.

Re: Scaling Mercurial at Facebook

#193

Post by rbehrends »

ahomescu1 wrote: post #187
rbehrends wrote: post #165

Earlier quoted context omitted.

Mercurial won't push new branches unless you specify -f or --new-branch. You can selectively push only the branches you want with hg push -r branch_or_revision ( hg push -r . for the current revision). You can also hide branches using phases, so they won't be pushed even with -f or --new-branch.

The guide from [1] confirms it works the way I saw it (it pushes all branches): Mercurial will push/pull all branches by default, while git will push/pull only the current branch. Did this behavior change in recent versions of hg? 1 - http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

Mercurial will attempt to push all branches. It will then immediately stop with an error message unless you specify -f or --new-branch if you're trying to push a branch that does not already exist in the remote repository (or even to create a new head in an existing branch). In order to get rid of the error message you need to either (1) explicitly tell Mercurial to push all branches, (2) specify which existing branch(es)/revision(s) you want to push (they must already exist remotely), or (3) hide the branch with hg phase secret -f. This means that your local branches will not leak into the remote repository unless you specifically instruct Mercurial to do so.

Of these, only the phase approach is new (2.1+). The rest hasn't changed.

Re: Scaling Mercurial at Facebook

#194

Post by novaleaf »

randartie wrote: post #156
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...

The discussion appears deleted on that thread

fyi, it was working about 8hrs ago. broken now. guess someone didn't like the inuendo ;)

Re: Scaling Mercurial at Facebook

#196

Post by r0muald »

weland wrote: post #175
ibrahima wrote: post #155

Earlier quoted context omitted.

I get this impression every time I see a "look what neat scalability thing we did" post from Facebook Engineering. It's great that they're able to achieve such technical feats, but they refuse to acknowledge that maybe they're using the technology wrong. I'm reminded of the time they hacked the Dalvik VM on Android because apparently they had too many method names for the Dalvik VM to handle. http://jaxenter.com/face…

I don't know if this is Facebook's case, but when I've seen stuff like that happening, it was because a bunch of (otherwise smart) developers were far too arrogant about the quality of their own work, too derogatory and, to some degree, too superficial about the quality of other programmers' work, and -- perhaps fatally -- too driven by the can-do-no-matter-what attitude that is so obnoxiously prevalent in today's co…

Like building the entire system in PHP, then throwing HipHop at it? Seems to work though.

Re: Scaling Mercurial at Facebook

#197

Post by maggit »

JoshTriplett wrote: post #17
jordigh wrote: post #8

Earlier quoted context omitted.

> if the standard workflow doesn't include incredibly lightweight branches, I'll stick with a version control system that does. There is no real standard workflow. There are tools in place to build whatever you want. This is old, but remarkably still relevant: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... If you want git-like branches, Mercurial bookmarks are close, but not quite the same. They have…

That post helped, and bookmarks might get the job done, but the mercurial culture doesn't seem to encourage them compared to branches. As a result, you tend to find a lot more separate mercurial repositories than single repos with bookmarks, and a lot more named branches with hard-to-eliminate commits as well (since even "closing" a branch doesn't really get rid of it). > hg commit --amend, hg histedit, hg record (bu…

> Those commands aren't available by default because the culture doesn't encourage that workflow

That's not the reason. The reason is that they want to keep the standard interface to hg minimal. Unfortunately, I cannot find a citation for that right now.

That said, I, too, would appreciate having more standard extensions enabled by default. But direct your disagreement to the idea that hg should have a minimal standard interface instead of making up reasons :)

Re: Scaling Mercurial at Facebook

#198

Post by mseebach »

r0muald wrote: post #196
weland wrote: post #175

Earlier quoted context omitted.

I don't know if this is Facebook's case, but when I've seen stuff like that happening, it was because a bunch of (otherwise smart) developers were far too arrogant about the quality of their own work, too derogatory and, to some degree, too superficial about the quality of other programmers' work, and -- perhaps fatally -- too driven by the can-do-no-matter-what attitude that is so obnoxiously prevalent in today's co…

Like building the entire system in PHP, then throwing HipHop at it? Seems to work though.

I'm not convinced that HipHop is an example of that. As I understand it, HipHop allowed Facebook to increase performance hugely with a very modest investment, and very low risk. Rewriting all the critical bits of Facebook in a different language to realize the same speed-up would likely have required a lot more resources and been orders of magnitude more risky.

Re: Scaling Mercurial at Facebook

#199

Post by exDM69 »

cool-RR wrote: post #195

I wonder whether putting all the code on a ramdisk (with backup of course) is feasible. If so it might be a very cheap solution.

No, using a ramdisk these days usually makes things worse, not better. The reason is that the operating system already holds as much of the filesystem in caches (in RAM) as possible. So as long as you have enough RAM in your system, files will be cached and the result is better than using a ramdisk.

Re: Scaling Mercurial at Facebook

#200

Post by exDM69 »

yonran wrote: post #41
Touche wrote: post #9

> 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. Pray tell?

I worked at Google (in a team using Perforce) and now work at a different company that uses multiple interdependent projects using Maven. Using a single monolithic codebase along with a build tool that statically builds everything at trunk has its advantages: * You immediately get improvements from upstream projects without having to get them manually. * You can unambiguously answer the question, What code am I using…

> * You can unambiguously answer the question, What code am I using? with a single number. With multiple repositories, you have to list all the versions of each project that you are using.

Git submodules may have a number of problems of its own, but it solves this one. There's always an unambiguous version number, which is the commit hash of the top repo. Every subrepository's commit hash is stored in the top repo and the top repo's version is an unambiguous version number of the entire code base.

I wish that more effort would be put in Git submodules, it's pretty much an afterthought addition but I've heard that there have been recent improvements and future improvements may be coming...

Post reply on HN