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

181–190 of 245 posts

Re: Scaling Mercurial at Facebook

#181

Post by ahomescu1 »

tonfa wrote: post #169
ahomescu1 wrote: post #139

Earlier quoted context omitted.

Mercurial's branches are server side (learned that the hard way the first time I made a branch), git's are client side.

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.

Re: Scaling Mercurial at Facebook

#182

Post by voidr »

They didn't really scale Mercurial, they basically took it and replaced a lot of it's functionality with remote services.

I understand their reasoning that technology shouldn't dictate the way they develop stuff, however I think splitting the project up and using submodules would have been a cleaner approach. If refactoring everything is something you do all the time, you might be doing it wrong.

Re: Scaling Mercurial at Facebook

#183

Post by krakensden »

thrownaway2424 wrote: post #152
moron4hire wrote: post #130

Earlier quoted context omitted.

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…

The fact that Google is one of the largest, most successful software companies in history and you are arguing on the internet using the handle "moron4hire" just about sums up the merits of your position.

It's not like no one respectable who has ever taken a contrary position:

http://apievangelist.com/2012/01/12/the-secret-to-amazons-su...

Re: Scaling Mercurial at Facebook

#184

Post by masklinn »

fhd2 wrote: post #171
masklinn wrote: post #68

Earlier quoted context omitted.

Mercurial's equivalent to git branches (movable pointer to a commit rather than embedded commit metadata) is bookmarks.

From what I've seen, bookmarks are not "branches" in any sense, really just pointers to commits. I've tried several times to use bookmarks for feature branches (read: branches developed in parallel to each other and the default branch). I thought I just can't figure it out, but it really seems impossible at this point.

> From what I've seen, bookmarks are not "branches" in any sense, really just pointers to commits.

That's exactly what git branches are.

Re: Scaling Mercurial at Facebook

#185

Post by masklinn »

ahomescu1 wrote: post #139
masklinn wrote: post #64

Earlier quoted context omitted.

> Does the standard branch workflow still expect you to have a separate repository and directory per branch? You're probably confusing mercurial with bazaar, mercurial has always had branches (though they're not quite the same as git, mercurial's bookmarks are more closely related to git branches) and anonymous heads (contrary to git, an unnamed head is not stuck in limbo). > I don't care about plugins That's stupid,…

Mercurial's branches are server side (learned that the hard way the first time I made a branch), git's are client side.

This is a description which makes no sense whatsoever, given git and mercurial are both DVCS there's no "client" or "server".

1. Mercurial branches are commit metadata, the branch name lives in the commit. Git branches are pointers to a commit (which move when a new commit is added on top of the existing branch commit), living outside the commit objects.

2. As a separate concern, Git has multiple branch namespaces ("remote" versus "local" branches, where each remote generates a branch namespace, and remote-tracking local branches). Mercurial only has a single namespace.

Re: Scaling Mercurial at Facebook

#186

Post by masklinn »

berdario wrote: post #84
masklinn wrote: post #64

Earlier quoted context omitted.

> Does the standard branch workflow still expect you to have a separate repository and directory per branch? You're probably confusing mercurial with bazaar, mercurial has always had branches (though they're not quite the same as git, mercurial's bookmarks are more closely related to git branches) and anonymous heads (contrary to git, an unnamed head is not stuck in limbo). > I don't care about plugins That's stupid,…

Furthermore, he's probably confusing mercurial with something that don't even exist bazaar expects you to have a separate working copy (directory) for each branch, but you can have multiple branches stored in the same repository without any problem (I just wished that git people actually knew how do other tools work... but, alas! Now it's too late for underdogs like bazaar or darcs to catch up)

> bazaar expects you to have a separate working copy (directory) for each branch, but you can have multiple branches stored in the same repository without any problem

Shared repositories didn't originally exist and IIRC were added to avoid data duplication. Furthermore, they don't fix the multiple working copies problem (you have to use lightweight checkouts or collocated branches for that).

Re: Scaling Mercurial at Facebook

#187

Post by ahomescu1 »

rbehrends wrote: post #165
ahomescu1 wrote: post #141

Earlier quoted context omitted.

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

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

Re: Scaling Mercurial at Facebook

#188

Post by k_bx »

fhd2 wrote: post #170
k_bx wrote: post #21

Earlier quoted context omitted.

Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?

According to #mercurial, branches (even closed ones) begin to noticeably slow down the repository when you reach around 2000. That's not at all impossible to reach with fine-grained feature branches. Bookmarks are really just pointers to commits, no branches in any sense, so they cannot be used for feature branches either. As a result, we simply don't use feature branches in Mercurial. It's literally the only issue I…

Well, if that true, I'd prefer to investigate and make them fast, instead of using "bookmark-as-a-branch" because of all the cool stuff mercurial branches have (like great log-drawing with branch info).

Re: Scaling Mercurial at Facebook

#189

Post by k_bx »

natrius wrote: post #50
k_bx wrote: post #22

Earlier quoted context omitted.

Why not use standard mercurial branches? At least you're able to say in which branch commit was done and draw a clean history for them.

I do use standard Mercurial branches, and I vastly prefer Git's model. I ask because there might be a better way to use them that I've overlooked.

What do you mean by "git model"? Creating branch per feature? But that's exactly what I do in mercurial!

Re: Scaling Mercurial at Facebook

#190

Post by k_bx »

wtetzner wrote: post #47
k_bx wrote: post #21

Earlier quoted context omitted.

Why do you think mercurial branches are not lightweight? Which operation (create, close, push, pull) on branches is noticeably slower than git's?

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.

Well, mercurial branch is just a record in list of branches, so is it then also "conceptually lightweight"? What is "conceptually lightweight" anyway?
Post reply on HN