3 ms·

Does anyone have "aha" moments to share about working in a single repository? Stuff that just made you say, "Great, I wouldn't have been able to do that if it

Does anyone have "aha" moments to share about working in a single repository? Stuff that just made you say, "Great, I wouldn't have been able to do that if it was in separate repositories!".

nwienert 9y ago
1. Huge changes that affect the API's of multiple sub-packages. 2. Having no friction to change anything makes you far more productive and ambitious. 3. Scripting at a org-level means you can automate things more easily and more in depth. We run an entirely node stack so Lerna enables this in the first place. Given that, I'd never move to more than one repo if possible. It's almost all downside: more overhead/fragmentation, less control, more wasted time/mental overhead moving between things, API friction that reduces ambitious change. Only downside of monorepo is Github not supporting them well. If you want to release some sub-packages as OSS, or want to use GH to track issues you're stuck using one big repo to handle everything. I'd bet Github fixes this within the next year or so though.
BrandonY 9y ago
Once, I noticed that a minor piece of how Google's Python system tests could be very slightly cleaner and more consistent. It would be a tiny change, it seemed very safe, and it was easily accomplishable with a short sed script, but it'd also be a backward-incompatible change across the projects of hundreds of teams and thousands of build targets. I was able to make that change with only a few commits and without needing to bother most of those teams. These sorts of small, general, large scale cleanup commits are quite common at Google, and they're encouraged. They help keep the codebase healthy. There are special groups that review them so that all of the individual teams affected don't have to bother, and there are tools to manage the additional testing and approval requirements for such a change. At my previous company, making such a change would have been a major undertaking. I never would have considered a refactor of that scale without a critical need. They had thousands of packages, each of which had its own repository and an incredibly complex web of build and runtime dependencies. It was a nightmare, and fiddling to find a working sets of versions of internal dependencies took up way, way too much of my time each day.
joeblau 9y ago
For me, refactors were the largest "aha" moment. On large scale projects you can move a lot faster if you don't have to maintain backwards compatible API's. We use Facebooks version of a mono-repo (BUCK [1]) for iOS dev. It's really easy to change an API, see all of the upstream breakages, write tests, fix upstream and submit a diff (pull request). With a fragmented large code base you're in a world of hurt because you're dealing with versioning. There is no guarantee of when every other dependency will migrate to the latest code path. But again, if you're in a 1-10 person team working on some trivial codebase, a monorepo might not be helpful. If you have 500 engineers working on a single codebase, tradeoffs change. [1] - https://buckbuild.com https://buckbuild.com

Does anyone have "aha" moments to share about working in a single repository? Stuff that just made you say, "Great, I wouldn't have been able to do that if it was in separate repositories!".

nwienert 9y ago

1. Huge changes that affect the API's of multiple sub-packages. 2. Having no friction to change anything makes you far more productive and ambitious. 3. Scripting at a org-level means you can automate things more easily and more in depth. We run an entirely node stack so Lerna enables this in the first place. Given that, I'd never move to more than one repo if possible. It's almost all downside: more overhead/fragmentation, less control, more wasted time/mental overhead moving between things, API friction that reduces ambitious change. Only downside of monorepo is Github not supporting them well. If you want to release some sub-packages as OSS, or want to use GH to track issues you're stuck using one big repo to handle everything. I'd bet Github fixes this within the next year or so though.

BrandonY 9y ago

Once, I noticed that a minor piece of how Google's Python system tests could be very slightly cleaner and more consistent. It would be a tiny change, it seemed very safe, and it was easily accomplishable with a short sed script, but it'd also be a backward-incompatible change across the projects of hundreds of teams and thousands of build targets. I was able to make that change with only a few commits and without needing to bother most of those teams. These sorts of small, general, large scale cleanup commits are quite common at Google, and they're encouraged. They help keep the codebase healthy. There are special groups that review them so that all of the individual teams affected don't have to bother, and there are tools to manage the additional testing and approval requirements for such a change. At my previous company, making such a change would have been a major undertaking. I never would have considered a refactor of that scale without a critical need. They had thousands of packages, each of which had its own repository and an incredibly complex web of build and runtime dependencies. It was a nightmare, and fiddling to find a working sets of versions of internal dependencies took up way, way too much of my time each day.

joeblau 9y ago

For me, refactors were the largest "aha" moment. On large scale projects you can move a lot faster if you don't have to maintain backwards compatible API's. We use Facebooks version of a mono-repo (BUCK [1]) for iOS dev. It's really easy to change an API, see all of the upstream breakages, write tests, fix upstream and submit a diff (pull request). With a fragmented large code base you're in a world of hurt because you're dealing with versioning. There is no guarantee of when every other dependency will migrate to the latest code path. But again, if you're in a 1-10 person team working on some trivial codebase, a monorepo might not be helpful. If you have 500 engineers working on a single codebase, tradeoffs change. [1] - https://buckbuild.com https://buckbuild.com