4 ms·

I don't get the hating here. With the right tooling it doesn't matter if its 10, 100 or 2000 repos. And it buys you some nice things like per-repo permission se

I don't get the hating here. With the right tooling it doesn't matter if its 10, 100 or 2000 repos. And it buys you some nice things like per-repo permission settings.

AlotOfReading 3y ago
What's your preferred solution to coordinating PRs across multiple repo boundaries? This is an enormous pain to do manually and the only tooling solution to it I've seen is Gerrit, which I find hard to describe as "right".
- MenhirMike 3y ago
  It's one of the reasons I prefer monorepos in practice. Especially if you use something like GitHub Enterprise, the cross-repo experience in terrible. In theory, many repos is better than a monorepo. In actual practice, most tooling only works well for monorepos. (And don't get me started on CI/CD tooling like GitHub Actions) Or you do what the .NET team at Microsoft did, create a separate monorepo that rolls up individiual repos: https://github.com/dotnet/dotnet https://github.com/dotnet/dotnet
- Jach 3y ago
  I believe the "right" way to do it is to have every repo only able to talk to another repo's code via versioned APIs. So e.g. a client repo can ship an update that will talk to some service repo's code at either version N or N+1, the server repo can later on leisurely ship its update that actually makes version N+1 available (and has to support however many prior versions by policy). Or vice-versa, the server side can have N and N+1 already in service while the clients roll out their updates. You have to do something like this anyway if you have a mobile app. Of course it has consequences and makes some things harder, you really have to go in on API-first even for things like UI widgets if different ones live in different repos, but it at least alleviates the common problem of trying to get multiple repo commits merged at the same time and have everything keep agreeing. I still prefer the monorepo approach.
- sethammons 3y ago
  Don't? You make backwards compatible changes and provide an API. To sunset a thing takes coordination and measuring usage. If you are having to keep two or more modules/libs/packages/repos in sync, those should be unified.
  - AlotOfReading 3y ago
    I'm only concerned with calling the feature done, not the details of interface compatibility. Let me give a historical example for clarity. I built a data path for an important sensor. The hardware team made their board rev (not in source control), the FPGA modifications were made, the bootloader had to be updated, the kernel had to be updated, application middleware had to be modified, the application had to be modified, and the networked application talking to that code had to be updated. You can certainly make the argument that all of that should belong to a monorepo (and I would agree), but it's not a painless or easy argument.
aylmao 3y ago
I mean, with the correct amount of investment, research and work, one can build a livable house out of Lego. I'm sure that gets you some nice things too. It doesn't change the fact other people will think: "why didn't you just build it out of normal bricks to save yourself all that trouble?".

I don't get the hating here. With the right tooling it doesn't matter if its 10, 100 or 2000 repos. And it buys you some nice things like per-repo permission settings.

AlotOfReading 3y ago

What's your preferred solution to coordinating PRs across multiple repo boundaries? This is an enormous pain to do manually and the only tooling solution to it I've seen is Gerrit, which I find hard to describe as "right".

MenhirMike 3y ago
It's one of the reasons I prefer monorepos in practice. Especially if you use something like GitHub Enterprise, the cross-repo experience in terrible. In theory, many repos is better than a monorepo. In actual practice, most tooling only works well for monorepos. (And don't get me started on CI/CD tooling like GitHub Actions) Or you do what the .NET team at Microsoft did, create a separate monorepo that rolls up individiual repos: https://github.com/dotnet/dotnet https://github.com/dotnet/dotnet
Jach 3y ago
I believe the "right" way to do it is to have every repo only able to talk to another repo's code via versioned APIs. So e.g. a client repo can ship an update that will talk to some service repo's code at either version N or N+1, the server repo can later on leisurely ship its update that actually makes version N+1 available (and has to support however many prior versions by policy). Or vice-versa, the server side can have N and N+1 already in service while the clients roll out their updates. You have to do something like this anyway if you have a mobile app. Of course it has consequences and makes some things harder, you really have to go in on API-first even for things like UI widgets if different ones live in different repos, but it at least alleviates the common problem of trying to get multiple repo commits merged at the same time and have everything keep agreeing. I still prefer the monorepo approach.
sethammons 3y ago
Don't? You make backwards compatible changes and provide an API. To sunset a thing takes coordination and measuring usage. If you are having to keep two or more modules/libs/packages/repos in sync, those should be unified.
- AlotOfReading 3y ago
  I'm only concerned with calling the feature done, not the details of interface compatibility. Let me give a historical example for clarity. I built a data path for an important sensor. The hardware team made their board rev (not in source control), the FPGA modifications were made, the bootloader had to be updated, the kernel had to be updated, application middleware had to be modified, the application had to be modified, and the networked application talking to that code had to be updated. You can certainly make the argument that all of that should belong to a monorepo (and I would agree), but it's not a painless or easy argument.

aylmao 3y ago

I mean, with the correct amount of investment, research and work, one can build a livable house out of Lego. I'm sure that gets you some nice things too. It doesn't change the fact other people will think: "why didn't you just build it out of normal bricks to save yourself all that trouble?".