4 ms·
In the argument of monorepo vs not, the usual argument goes like this: - It's too hard to scale for a large monorepo! - Google does it just fine! - But I don
by jedberg 4y ago
In the argument of monorepo vs not, the usual argument goes like this:
- It's too hard to scale for a large monorepo!
- Google does it just fine!
- But I don't have access to Google's tools!
So kudos to Meta for both solving the problem and making it available to others. It will be interesting to see how useable it is outside of Meta. I know for example that while Netflix open sourced a lot of tools, most of them weren't useable unless you ran all of them together. So far Meta has been good at avoiding that, so hopefully that remains the case.
- jupp0r 4y agoMostly people who have this argument don't have a code base large enough to run into actual limitations of git. They run CI with wonky java implementations of git and/or have giant amounts of binaries in their repos. Actually having Gigabytes of source code is pretty rare.
- pianoben 4y agoOr, they run in to limits with Github and mistake them for git limitations...
- colonwqbang 4y agoIt depends on the size of the company. The Linux kernel has about 1500 active developers. This is a lot, but many companies also exist that reach this size. I think another thing that matters is how you store branches/code under review. In Linux, each team/person has their own repo. The main "Linus" repo has mostly the finished code. In a company it is much more common for everyone to store their unfinished code centrally. Perhaps this also accounts for some increase in size.
- maccard 4y ago> and/or have giant amounts of binaries in their repos. Firstly, it's not "giant amounts of binaries" it's "a very small amount of binaries". A few GB is enough to cause significant problems. Secondly, This _is_ an issue with git. If my project requires binary files, git should handle it. How should we handle logos in a mobile app, branding images on a website, audio files for background? That's before you get to the question of "how does a video game store the source version of a 100GB worth of compressed assets?"
- nicoburns 4y agoIn fairness, there is git LFS, which is a well-maintained solution to do this. It's not fantastic, but it does exist.
- maccard 4y agoGit LFS is a reasonably good example of git being half baked. It is provider dependent, and requires configuring separately on both the server and client. It turns git into a centralised VCS, removing the option of working offline in the process. A bit like submodules, LFS has its own warts that seem to multiply when you add more people to the mix. Working with git LFS has been the _only_ time the solution to my problem has been "nuke and clone again", in almost 15 years using source control. Last time I used git LFS, it didn't support ssh cloning at all, and the issue had been open for years at that time.
- xyzzy_plugh 4y agoBut they haven't done that yet. This is just the CLI, the centralized monorepo bits aren't yet available.
- systemicdanna 4y agoYou could use Phabricator today.
- physicsguy 4y ago"Effective June 1, 2021: Phabricator is no longer actively maintained."
- idoubtit 4y agoMicrosoft uses monorepos, and you have access to Microsoft's tools! They chose to work with Git and amend it when necessary, just like Meta did with Mercurial. A few years ago they had a Virtual File System extension for Git. Now it's a public fork of Git that is intended for large repositories (several hundreds of GB). It adds a `git scalar` command, see https://github.com/microsoft/git/blob/HEAD/contrib/scalar/docs/index.md https://github.com/microsoft/git/blob/HEAD/contrib/scalar/do...