Why Google Stores Billions of Lines of Code in a Single Repository (2016)

Re:Why Google Stores Billions of Lines of Code in a Single R... by vkou on Tuesday July 24, 2018 @09:14PM (#17606240)

You can soft-deprecate the old code path, and communicate that warnings will turn into errors at some future date.

You can send your pull request to the affected team leads, and request that they approve it, once they make changes on their end.

I mean, the alternative is that you have 17 different projects, each using one of five different versions of the common code. Heaven forbid one of them makes an incorrect assumption about another. Getting 17 different teams to dance together around a breaking change is always going to be hard.

[ Parent | on HN ]

Re:Why Google Stores Billions of Lines of Code in a Single R... by u801e on Tuesday July 24, 2018 @10:48PM (#17606591)

If the common code is a versioned package, then each of the 17 different projects could update their code to handle breaking changes in the common package independently and update the version dependency after thorough testing.

[ Parent | on HN ]

Re:Why Google Stores Billions of Lines of Code in a Single R... by vkou on Wednesday July 25, 2018 @03:19AM (#17607443)

You can have versioned packages inside a mono-repository, too, though. /common_libs/foo_lib_v1.13/, /common_libs/foo_lib_v1.14/, etc.

[ Parent | on HN ]

Re:Why Google Stores Billions of Lines of Code in a Single R... by flukus on Wednesday July 25, 2018 @04:17AM (#17607665)

By that point your creating micro-repositories in your mono-repository and getting the worst of both worlds.

[ Parent | on HN ]

Re:Why Google Stores Billions of Lines of Code in a Single R... by vkou on Wednesday July 25, 2018 @03:00PM (#17611849)

No, you're getting the best of both worlds, because it's incredibly clear to the infrastructure maintainers what version everyone's on, whether or not the old version can be safely deprecated, who is responsible for deprecating it, etc.

[ Parent | on HN ]