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

Facebook hit git performance issue on large repository

thread.gmane.org

Post reply on HN
Print view View original

181–190 of 217 posts

Re: Facebook hit git performance issue on large repository

#181

Post by mariusmg »

marginalboy wrote: post #45
losvedir wrote: post #28

Huh, fascinating. git was initially created for the Linux kernel development, and I haven't heard of any issues there. Offhand I would have said, as a codebase, the Linux kernel would be larger and more complex than facebook, but I don't have a great sense of everything involved in both cases. So what's the story here: kernel developers put up with longer git times, the kernel is better organized, the scope of facebo…

It isn't surprising if Facebook has a large, highly coupled code base. Given their reputation for tight timelines and maverick-advocacy, I'm continually surprised the thing works at all.

The FB mobile auth workflow breaks at least once a month.

Re: Facebook hit git performance issue on large repository

#182

Post by Robin_Message »

jrockway wrote: post #134
Splines wrote: post #80

Earlier quoted context omitted.

At Google, everything is in Perforce, but since I personally need only four or five projects from Perforce for my work, I mirror that to git and interact with git on a day-to-day basis. At MS we also use Perforce (aka Source Depot), and I've toyed with the idea of doing something similar. Have you found any guides for "gotchas" or care to share what you've learned going this route?

I used git-p4 at my last job, and the only thing that ever got weird was p4 branches. At Google we have an internal tool that's similar to git-p4, and it always works perfectly for me. Enough developers are using it such that most of the internal tools understand that a working copy could be a git repository instead of a p4 client. So if you're planning on doing this at your own company, my advice is to write your ow…

Eric Raymond talks about the problems of converting svn repos to git and is promising a new release of reposurgeon soon that handles svn well. http://esr.ibiblio.org/?p=4071

Re: Facebook hit git performance issue on large repository

#183

Post by adgar »

ori_b wrote: post #159
robfig wrote: post #154

Earlier quoted context omitted.

In violent agreement here. Git and HG: 1. Require you to be sync'ed to tip before pushing. 2. Cannot selectively check out files. The former means that in any reasonably sized team, you will be forced to sync 30 times a day, even if you are the only one editing your section of the source tree. The latter means that Joe who is checking in the libraries for (huge open source project) for some testing increases everyone…

Git is not used for their main repo. Git is used as a local cache for perforce where a branch roughly corresponds to a CL. Only subtrees of interest are checked out.

> Git is used as a local cache for perforce where a branch roughly corresponds to a CL. Only subtrees of interest are checked out.

That's a common use for git at Google, but not the only one (I'm a SWE). When I do use perforce I've got enough rhythm that it doesn't get in my way, but I really like git at Google for local branches on rapidly-changing subtrees. A lot of time I'll work on a branch to submit as a CL, but then realize I should do something else that depends on it. Perforce is a mess at this situation if the tree is changing much, and git is perfect if you just make a new branch.

Re: Facebook hit git performance issue on large repository

#184

Post by exDM69 »

joelthelion wrote: post #179
exDM69 wrote: post #176

Earlier quoted context omitted.

> Looks like it's worth taking a serious look at this repo script, as it's been used in production for Android. Might allow splitting into multiple git repositories for performance while still retaining some of the benefits of a single repository. Stay away from Repo and Gerrit. I use them at work, and they make my life miserable. Repo was written years ago when Git did not have submodules, a feature where you can pu…

What about gerrit?

Compared to the code review facilities in GitHub, Gerrit is pretty crappy. Gets the job done, but the UI and the work flow it forces is a bit annoying.

The worst part in repo + gerrit is that their default work flow is based on cherry-picking and they introduce a new concept called Change-Id. The Change-Id basically yet another unique identifier for changes that is stored in the commit message. The intent is that you make a change (a single commit patch), a post-commit hook adds the Change-Id to the commit message and then you upload it for review. When you make additions to your change, the previous change gets overwritten. Gerrit tries to maintain some kind of branching (called dependencies), but they mess things up when there's more than one person working on a few changes at the same time.

In comparison with GitHub-style work flow where you make a branch with multiple commits, submit a pull request, get review, add commits, squash and merge, the repo + gerrit model is awfully constraining.

We might be using an old version of repo and/or gerrit and some of the issues I've encountered may be improved. However, I think that repo+gerrit is a mess beyond repair and trying to "fix" it only makes things worse.

Unless you work on Android and are forced to use repo+gerrit because Google does so, stay out of it.

Re: Facebook hit git performance issue on large repository

#185

Post by mise »

mise wrote: post #64
joelhaasnoot wrote: post #62

Earlier quoted context omitted.

While it may not be, I do find it an every day battle to keep my PHP wel 'styled'. Sure, PHP is the first language I learnt, and I do use a framework, but sometimes a long method is easier in the short run than writing good model functions. And I have models, but mostly for the ORM and they're all completely interconnected. PHP makes me lazy, fast

It's for this type of thinking that I've been looking at Rails recently.

If downvoting me, I would appreciate at least if you explain yourself :)

Re: Facebook hit git performance issue on large repository

#186

Post by jomar »

sateesh wrote: post #128
forrestthewoods wrote: post #90

Earlier quoted context omitted.

It's called Perforce and anyone dealing with binary files has been using it for years.

And also there is 'Rational Clearcase', another centralized version control system.

If you have used ClearCase, you will know that while it's a great solution to a "what shall we do with our buckets of cash" problem, it's not something that anyone encountering performance problems would reach for.

Re: Facebook hit git performance issue on large repository

#187

Post by echaozh »

fragsworth wrote: post #48
sek wrote: post #19

http://thread.gmane.org/gmane.comp.version-control.git/18977... They keep every project in a single repo, mystery solved. Edit: > We already have some of the easily separable projects in separate repositories, like HPHP. Yeah, because it makes no sense, it's C++. They probably use for everything PHP i assume then. Is there no good build management tool for it?

> They keep every project in a single repo, mystery solved. This kind of "Duh, look what you're doing" response isn't really justified. Sure, splitting up your repository would make things faster, but having to maintain multiple repositories is a major headache for the end-users of git. If it's possible, why not fix its scalability so that you don't have to worry about it?

I agree. Users are always right, even for open source software. Requiring the users to change their way is an easy way to lose them. A major player like Facebook willing to use Git is a good thing, as it may help spread the software in companies like Facebook. Git should try its best to please its user, rather than the other way round.

Re: Facebook hit git performance issue on large repository

#188

Post by r15habh »

r15habh wrote: post #168

Does Facebook really believe that because they have the most users, they should also have the biggest git repo? Amazon and Google have already solved this problem, and the solution is to reorganize things into smaller manageable packages.

What I mean is, even if they manage to solve this problem with some tweaks, they will again hit the bottleneck in an year or two, so they should rethink their source code management

Re: Facebook hit git performance issue on large repository

#189

Post by kaib »

chubot wrote: post #111
forrestthewoods wrote: post #90

Earlier quoted context omitted.

It's called Perforce and anyone dealing with binary files has been using it for years.

And also paying Perforce fistfuls of cash in licensing fees. I hear that Perforce is a quite a small company, and the founder wrote the lion's share of the code a couple decades ago. I think they are probably on par with craigslist in profits per employee (i.e. much higher than Google or Facebook. Interestingly I think Facebook has about 1/10 the employees of Google with 1/10 the profits -- off the top of my head fee…

Perforce just raised their limit on the free version to 20 users and 20 workspaces, it used to be 2 users. We use it at Tinkercad and have been very happy, I used it at Google previously. The price (free) is acceptable for almost any small development organization.

Re: Facebook hit git performance issue on large repository

#190

Post by Tobu »

exDM69 wrote: post #184
joelthelion wrote: post #179

Earlier quoted context omitted.

What about gerrit?

Compared to the code review facilities in GitHub, Gerrit is pretty crappy. Gets the job done, but the UI and the work flow it forces is a bit annoying. The worst part in repo + gerrit is that their default work flow is based on cherry-picking and they introduce a new concept called Change-Id. The Change-Id basically yet another unique identifier for changes that is stored in the commit message. The intent is that you…

I'm using it, the workflow isn't so bad. In fact it is similar to the way kernel patches are iterated and reviewed, except centralised instead of e-mail based.
Post reply on HN