Re:Why Google stores billions of lines of code in a single r...
by geocar on Tuesday December 12, 2017 @10:18AM
(#15906127)
> If tables, then if they are in the same DB, they should be in the same project.
Lock-stepping two otherwise unrelated applications because they both share support for a data structure is silly at best, and often impractical, especially if development for only one of the projects is "in-house". Consider the possibility that "A" is a commercial product produced by another company.
Anyway, it's my experience most software upgrades don't involve a schema change, so it's worth optimising for the common case, and supporting the difficult case.
If they are independent tables, then I don't care, show me the API between the projects.
If these are file/network/serialization/wire/in-memory/binary/codec formats, then there are conformance checkers (passive and active, like fuzzers). Those are separate projects, but they can be used like tools during testing and development.
Rely on tooling to make sure that the stated goal of the project is reached. (It now supports F or G or X,Y,Z formats. It supports output-format G by processing input-format F. If that's a project requirement, test it in that project.)
You can use a top level repo for the integration tests. But it's no need to make it one flat repo.