Hacker News Reader

Comment by wtbob | Hacker News Reader

Anyone have a cache?

Without reading it, I've used monorepos and multiple repos, and far prefer the former. What people don't get is that any system consisting of software in multiple repos is really a monorepo with a really poor unit & integration test story. The overhead of managing changes to inter-repo dependencies within the same system is utterly insane — I'd say that it's somewhere between 2^ n & n^2, where n is the number of repositories (the exact number depends on the actual number of dependency relationships between repos).

In fact, after these several years, I'm beginning to think that 'prefer' is not the word: monorepos appear, more and more, to be Correct.

View on HN

http://web.archive.org/web/20160625124824/http://cacm.acm.or...

I have also worked with mono/multi repos. My conclusion is the same. A mono repo is much easier to manage. It is a shared repository but every team manages their own runtime instances. Each team releases at their own pace. The repository is always consistent, no need to manage inter-repo dependencies. You really get the best of both worlds.

Coincidentally, I have been reading "Building Microservices" from O'reilly and I still don't see the benefits.

> In fact, after these several years, I'm beginning to think that 'prefer' is not the word: monorepos appear, more and more, to be Correct.

This is my analysis as well, after working with both.

How do you deal with updating a vendored library, do all the reverse dependencies need to be fixed in one go?

I can see how it would be an advantage to use only one library version but it could also discourage upgrading since all the cost is upfront.

Unless the software has nothing to do with each other.

A client software in Java, another client in C#, another one in Obj-C and a server software in C++ will be hard to test together, will share no code, and often be developed in independent development cycles, often by independent teams.

Putting such things in monorepos would be stupid.

Totally disagree. Any serious development project that has an application that needs to work across iOS, Android, Mac and Windows should be sharing as much of its business logic, in C or C++ which is usable on all those platforms. The UIs of course will be platform-specific, hopefully as thin as possible, but the majority of your code should be totally re-usable.

Disagree. Typically, in this scenario, you're using some kind of protocol to communicate. In our case, it's protobufs: they are in fact one of the prime sources of breakages between repos, and one of the main reasons I wish we had a monorepo. Same would be true of json schemas, etc.

Oh but it wouldn't. While those clients might not share code, each of them does share an interface with a common dependency: the server. Having the server code and a given client code in the same repo is what you want, which means you want the server code and all the clients in the same repo.

Google has code in C++, Java, Python, Go, and JavaScript spanning countless different products (Google has a lot of products), all in the same repo.

Disagree. If they're all part of the same system and/pr project, they ought to go in the same repo. Otherwise, you've not got one system/project at all - you've got several, and you shouldn't try to pretend otherwise.

You can of course just press on regardless anyway, but that doesn't mean it's a great idea!

Reply on news.ycombinator.com