Facebook's git repo is 54GB

Post by efraim » Fri, Apr 25, 2014, 8:46 PM UTC

kahoon wrote: post #91

rl3 wrote: post #83

Although this is large for a company that deals mostly in web-based projects, it's nothing compared to repository sizes in game development. Usually game assets are in one repository (including compiled binaries) and code in another. The repository containing the game itself can grow to hundreds of gigabytes in size due to tracking revision history on art assets (models, movies, textures, animation data, etc). I woul…

But they surely don't use git for that, right? In scenarios like this a versioning system that does not track all history locally would be a better fit.

Post by Theodores » Fri, Apr 25, 2014, 8:50 PM UTC

slig wrote: post #63

TD-Linux wrote: post #50

Earlier quoted context omitted.

Yes, and an intern would be subject to a code review before pushing to master - no way would they have write access to the "master" repo.

Yes, but the new intern would be able to read all the source and "secret sauces". I doubt that an intern on Google would've access to the search codebase. I'd wager that only a handful of trusted employees have access to that codebase.

Post by lbrandy » Fri, Apr 25, 2014, 8:55 PM UTC

runT1ME wrote: post #94

general_failure wrote: post #39

The worrying point here is the checkout of 8GB as opposed to the history size itself (46GB). If git is fast enough with SSD, this is hardly anything to worry about. I actually prefer monolithic repos (I realize that the slide posted might be in jest). I have seen projects struggle with submodules and splitting up modules into separate repos. People change something in their module. They don't test any upstream module…

>People change something in their module. They don't test any upstream modules because it's not their problem anymore. If you use any sort of versioning this shouldn't ever cause a problem.

Post by Strom » Fri, Apr 25, 2014, 8:58 PM UTC

ProAm wrote: post #87

rl3 wrote: post #69

Earlier quoted context omitted.

It should be possible to restrict each employee's access to specific parts of the repository. However, I can't really see Facebook doing that. Everyone having access to everything must be worth the security trade-off. On the other hand, I suppose it's debatable whether it would be a trade-off at all.

>Everyone having access to everything must be worth the security trade-off. I would find this extremely hard to believe, especially at Facebook. At any software company, your code base is what defines you as a company; there is no way they'd let the good stuff sneak out like that.

Post by im3w1l » Fri, Apr 25, 2014, 8:59 PM UTC

ProAm wrote: post #87

rl3 wrote: post #69

Earlier quoted context omitted.

It should be possible to restrict each employee's access to specific parts of the repository. However, I can't really see Facebook doing that. Everyone having access to everything must be worth the security trade-off. On the other hand, I suppose it's debatable whether it would be a trade-off at all.

>Everyone having access to everything must be worth the security trade-off. I would find this extremely hard to believe, especially at Facebook. At any software company, your code base is what defines you as a company; there is no way they'd let the good stuff sneak out like that.