4 ms·

Because you lose the 'single head' concept of actually being able to always have a clear view of the current newest version and of linear version history. The a

by q3k 6y ago

Because you lose the 'single head' concept of actually being able to always have a clear view of the current newest version and of linear version history. The ability to map a single revision number into the state of _all_ source code (including third party dependencies) is extremely powerful. You also lose the ability of performing sweeping changes across an entire codebase in lockstep (think: backwards compatibility breaking API changes). Not to mention that Google internally avoids multiple repositories (and instead runs of a single monorepo) - it's just the android/chrome/public stuff that's mostly split up.

AlphaSite 6y ago
Also there isnt really a lot of great tooling for making sweeping changes across repos.
erik_seaberg 6y ago
Don't make breaking API changes, you can't deploy them atomically. You have to support the old API until everyone has safely migrated and confirmed no rollback will be needed.
- joshuamorton 6y ago
  There are more apis than just rpc ones. If I change my library's api, I can update the callers atomically.
- fsociety 6y ago
  Then services would be stuck in a sea of technical debt. There are too many moving pieces to do that.
  - erik_seaberg 6y ago
    Technical debt is a tool to be used (with caution). Getting ludicrously far behind is a risk I'd avoid, but our stability is more important than staying on the bleeding edge and testing every single version of each of our dependencies.
- djohnston 6y ago
  you can if it's a monorepo and all your callers are in the monorepo, which sort of answers OP's question
  - erik_seaberg 6y ago
    The commit can be atomic, but if prod is many machines, the deployment cannot.
throwdbaaway 6y ago
> performing sweeping changes across an entire codebase in lockstep This thinking right here, sounds like a reason why Google retires a lot more services at much higher frequency compared to other companies? In https://thehftguy.com/2019/12/10/why-products-are-shutdown-the-case-of-verizon-and-yahoo-groups/ https://thehftguy.com/2019/12/10/why-products-are-shutdown-t..., the HFT guy brought up the "5 years upgrade pain" as the reason why a service would be retired, at the time when the pain from upkeeping outweights the gain from revenue. By regularly making backward incompatible API change, as afforded by the monorepo, while also having engineers moving freely between projects, the upgrade pain cycle becomes way shorter for Google services. By the way, this line of thought also leaks into public facing source code, with guava being the poster child of breaking backward compatibility, althought it has learned its lesson starting with version 21.

by q3k 6y ago

AlphaSite 6y ago

Also there isnt really a lot of great tooling for making sweeping changes across repos.

erik_seaberg 6y ago

Don't make breaking API changes, you can't deploy them atomically. You have to support the old API until everyone has safely migrated and confirmed no rollback will be needed.

joshuamorton 6y ago
There are more apis than just rpc ones. If I change my library's api, I can update the callers atomically.
fsociety 6y ago
Then services would be stuck in a sea of technical debt. There are too many moving pieces to do that.
- erik_seaberg 6y ago
  Technical debt is a tool to be used (with caution). Getting ludicrously far behind is a risk I'd avoid, but our stability is more important than staying on the bleeding edge and testing every single version of each of our dependencies.
djohnston 6y ago
you can if it's a monorepo and all your callers are in the monorepo, which sort of answers OP's question
- erik_seaberg 6y ago
  The commit can be atomic, but if prod is many machines, the deployment cannot.

throwdbaaway 6y ago

> performing sweeping changes across an entire codebase in lockstep This thinking right here, sounds like a reason why Google retires a lot more services at much higher frequency compared to other companies? In https://thehftguy.com/2019/12/10/why-products-are-shutdown-the-case-of-verizon-and-yahoo-groups/ https://thehftguy.com/2019/12/10/why-products-are-shutdown-t..., the HFT guy brought up the "5 years upgrade pain" as the reason why a service would be retired, at the time when the pain from upkeeping outweights the gain from revenue. By regularly making backward incompatible API change, as afforded by the monorepo, while also having engineers moving freely between projects, the upgrade pain cycle becomes way shorter for Google services. By the way, this line of thought also leaks into public facing source code, with guava being the poster child of breaking backward compatibility, althought it has learned its lesson starting with version 21.