5 ms·

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 consistin

by wtbob 10y ago

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.

Hussell 10y ago
http://web.archive.org/web/20160625124824/http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext http://web.archive.org/web/20160625124824/http://cacm.acm.or...
kuschku 10y ago
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.
- ryandrake 10y ago
  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.
  - deleted 10y ago
    [deleted]
- zellyn 10y ago
  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.
  - deleted 10y ago
    [deleted]
- to3m 10y ago
  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!
- jahewson 10y ago
  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.
- zeven7 10y ago
  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.
zimbatm 10y ago
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.
huherto 10y ago
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.
pnathan 10y ago
> 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.

by wtbob 10y ago

Hussell 10y ago

http://web.archive.org/web/20160625124824/http://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext http://web.archive.org/web/20160625124824/http://cacm.acm.or...

kuschku 10y ago

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.

ryandrake 10y ago
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.
- deleted 10y ago
  [deleted]
zellyn 10y ago
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.
- deleted 10y ago
  [deleted]
to3m 10y ago
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!
jahewson 10y ago
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.
zeven7 10y ago
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.

zimbatm 10y ago

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.

huherto 10y ago

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.

pnathan 10y ago

> 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.