5 ms·
Why split it into separate modules? Seeing that big companies are very successful with monorepos (Google, Facebook, Microsoft), has made me reconsider if reposi
by arjie 9y ago
Why split it into separate modules? Seeing that big companies are very successful with monorepos (Google, Facebook, Microsoft), has made me reconsider if repository modularization is actually worth it. There are a host of advantages to not modularizing repos, and I'm beginning to believe they outweigh those of modular repos.
- komali2 9y agoWait so like, at google, Inbox and Android are in the same repo as ChromeOS and oh I dunno, Google Search? That doesn't make any sense at all...
- andreasklinger 9y agoUnsure if all their clients are in the same repo as well but even if… Why doesn't this make sense. I personally think of a repo as of an index not a filesystem. You checkout what you need but there is one global constant state - which can eg be used for continuous integration tests
- TylerE 9y agoIt makes total sense when the expectation is that any engineer in the company can build any part of the stack at any time with a minimum of drama.
- bitJericho 9y agoThis just blew my mind. I'm gonna go home and see about combining all my projects. That seems very useful!
- bronson 9y agoYou don't have the same requirements as Google.
- bitJericho 9y agoWhat are my requirements such that this wouldn't work for me?
- mkj 9y agoIt makes things tricky if you want to opensource just one of your projects.
- rleigh 9y agoWell, there's always "git filter-branch". Not that I'd want to run it on such a mega-repository; it takes long enough running it on an average one with a decade of history.
- therealdrag0 9y agoIt makes sense to have separate repos for things that don't interact. But when your modules or services do. Having them together cuts out some overhead.
- dvdcxn 9y agoWhat's dramatic about copy and pasting a clone uri into a command?
- TylerE 9y agoA url? Not much. 100 urls? That's getting a bit annoying.
- jvolkman 9y agoAndroid and Chrome are different, but most of Google's code lives in a single repository. https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
- sbuttgereit 9y agoSome of the rationale.... https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor...
- c8g 9y agoAndroid is in a separate repo.
- uiri 9y agoYes, Inbox, Maps, Search, etc. are all in one repo in a specialized version control system. Android, Chromium, and Linux (among others, I'm sure) are different in that they use git for version control so they are in their own separate repos.
- je42 9y agomono repo only works if you have tooling. google's and facebook's tools are not opensource. also, ms tooling is windows only. so for most of us the only reasonable path is to split into multiple repositories. it is also easier to create tools that deal with many repositories. than it is to create a tool that virtualizes a single large repo.
- riffraff 9y agobut google's and facebook's repos are also orders of magnitude larger than what most people deal with, normal tools might work just fine in most cases.
- ethomson 9y agoMicrosoft's tooling is Windows only _today_. GVFS is open source _and_ we are actively hiring filesystem hackers for Linux/macOS.
- amptorn 9y ago> Why split it into separate modules? Well, because of the unbelievable amount of engineering work involved in trying to get Git to operate at such insane scale? To say nothing of the risk involved in the alternative. This project in particular could easily have been a catastrophe.
- a-priori 9y agoMicrosoft has about 50k developers. When you're dealing with an engineering organization of this size, you're looking at a run rate of $5B a year, or about $20M a day. It's a no-brainer to spend tens or even hundreds of millions of dollars on projects like this if you're going to get even a few percentage points of productivity. It can be hard to understand this as an individual engineer, but large tech companies are incredible engineering machines with vast, nearly infinite, capacity at their disposal. At this scale, all that matters is that the organization is moving towards the right goals. It doesn't matter what's in the way; all the implementation details that engineers worry about day-to-day are meaningless at this scale. The organization just paves over over any obstacles in pursuit of its goal. In this case Microsoft decided that Git was the way to go for source control, that it's fundamentally a good fit for their needs. There was just implementation details in the way. So they just... did it. At their scale, this was not an incredible amount of work. It's just the cost of doing business.
- amptorn 9y agoYou haven't said anything at all about the risk.
- a-priori 9y agoIf there's one thing large organizations are good at, it's managing risk. And if you read their post, they've done this. They're running both source control systems in parallel, switching developers in blocks, and monitoring commit activity and feedback to watch for major issues. In the worst case, if GVFS failed or developers hated it, they could roll back to their old system. Again, to my point above: there's a cost to doing this but it's negligible for very large organizations like Microsoft.