161–170 of 245 posts
Earlier quoted context omitted.
Yeah, doing it this way they can never make API incompatible changes without also fixing everything downstream... which effectively means once a library is popular enough it is locked at it's current API forever.
Or you bump an API version. And the fixes are gradual everywhere.
Earlier quoted context omitted.
Facebook tends to throw engineer time at the problem, though. I know one Facebook DevCon I went to they presented how they completely wrote their own build system because Ant was too slow for them.
They built their own build system because once you are dealing with top engineers NIH sets in quickly and you write your own everything.
Earlier quoted context omitted.
8 GB is still a lot. Would be interesting to know how much of it is actual code and how much is just images and so on.
The big .git directory is probably binary revisions? Is there any good way around that in git?
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.
I wonder, if this is the way a majority of big businesses do things, how come we don't see more leaks of entire codebases? It'd be trivial to put something up on TPB and just share all the code, but I don't see things like that happening. I also doubt that every single employee with access to the code has the moral standards not to do this. There must be something else keeping them from doing it.
Earlier quoted context omitted.
8 GB is still a lot. Would be interesting to know how much of it is actual code and how much is just images and so on.
8GB would be at least 100 million lines of code (upper bound with 80 characters per each line). For comparison Linux has 15+ million lines of code, PHP 2+M.
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…
Most big tech companies use a service-oriented architecture. The website is composed of many small services which communicate with each other over HTTP or RPC protocols. Each service has its own version control repo and is maintained by a different team. That's generally the best way of scaling up.
They might have since modularized and cleaned it up but it seems unlikely they'd fully SOA-ize the Facebook web app.
Earlier quoted context omitted.
The big .git directory is probably binary revisions? Is there any good way around that in git?
I'm a bit confused. Whenever I've used git on my projects, I'd make sure the binaries were excluded, using .gitignore Don't other people do that, too? What's the benefit of having binaries stored? I've never needed that; I've never worked on any huge projects, so I might be missing something crucial.
(jk)
Someone recently told me that Facebook had a torrent file that went around the company that people could use to download the entire codebase using a BitTorrent client. Is there any truth in this? I mean, the same guy that told me this, also said that the codebase size was about 50 times less than the one reported in this slide, so it may all be pure speculation.
Earlier quoted context omitted.
The big .git directory is probably binary revisions? Is there any good way around that in git?
FWIW: Every time you modify a file in git, it adds a completely new copy of the file. 100mb text file, 100mb binary file - makes no difference. Modify one line, it's a new 100mb entry in your git repo.