9 ms·

Advantages of monolithic version control

3 points by eadmund 9y ago

eadmund 9y ago
I'll actually go further than Dan here: I'm beginning to believe that the default should be one repo per company or team-of-teams, and that creating a second repo should require extremely good reasons why.
w4tson 9y ago
I wonder how far you could get at a startup just using git as the monorepo. That is, before it became too painful.
erik_seaberg 9y ago
> Since atomic cross-project commits are possible, the repository can always be in a consistent state – at commit #X, all project builds should work. At Google this regularly failed. We spent hours unable to commit changes (unless a disaster could justify ignoring build and test failures) because someone we'd never met had broken the world and the fix was still making its way through the enormous backlog of projects to retry. Every project needed people taking turns in a "build cop" role diagnosing this stuff and demanding rollbacks as quickly as possible. It's essential to pin known-good version of your dependencies and upgrade when you can handle it. You can't expect every commit anyone ever makes to be production ready.
- eadmund 9y ago
  > You can't expect every commit anyone ever makes to be production ready. Of course not — but surely that's what branches are for. Does Perforce not have a concept of branches? It seems absurd that Google would let folks merge untested commits into master.
  - erik_seaberg 9y ago
    Generally Googlers edited and reviewed a changelist (which is like amending a commit that hasn't been pushed yet) and then submitted when it's considered ready to deploy. You're expected to run your project's test targets (which might include a few critical dependents) before you submit, but if you have a huge set of dependents there's no way to be certain none will break—their tests might be flaky or fail for reasons that aren't your fault, and there will be hundreds of new changelists submitted (including changes to your own dependencies!) while your tests were running.

3 points by eadmund 9y ago

I'll actually go further than Dan here: I'm beginning to believe that the default should be one repo per company or team-of-teams, and that creating a second repo should require extremely good reasons why.

w4tson 9y ago

I wonder how far you could get at a startup just using git as the monorepo. That is, before it became too painful.

erik_seaberg 9y ago

> Since atomic cross-project commits are possible, the repository can always be in a consistent state – at commit #X, all project builds should work. At Google this regularly failed. We spent hours unable to commit changes (unless a disaster could justify ignoring build and test failures) because someone we'd never met had broken the world and the fix was still making its way through the enormous backlog of projects to retry. Every project needed people taking turns in a "build cop" role diagnosing this stuff and demanding rollbacks as quickly as possible. It's essential to pin known-good version of your dependencies and upgrade when you can handle it. You can't expect every commit anyone ever makes to be production ready.

eadmund 9y ago
> You can't expect every commit anyone ever makes to be production ready. Of course not — but surely that's what branches are for. Does Perforce not have a concept of branches? It seems absurd that Google would let folks merge untested commits into master.
- erik_seaberg 9y ago
  Generally Googlers edited and reviewed a changelist (which is like amending a commit that hasn't been pushed yet) and then submitted when it's considered ready to deploy. You're expected to run your project's test targets (which might include a few critical dependents) before you submit, but if you have a huge set of dependents there's no way to be certain none will break—their tests might be flaky or fail for reasons that aren't your fault, and there will be hundreds of new changelists submitted (including changes to your own dependencies!) while your tests were running.