One problem he didn't mention with the poly-repo approach is that repositories are like rabbits: as soon as you have more than one they begin breeding. Repositories, plural, beget more repositories.
The problem of course is that the only way to share code between repos is to create another repo. As the saying goes, once you have two things, you will soon want three.
"Oh, repo B needs to use some code in repo A. We'll just split that out into a separate repo."
Be very wary of this impulse. Soon, you end up in the situation I'm in now, where you have hundreds of tightly coupled repos, some with a single file! Worse, these all compose at runtime into only one application running on one host.
Consider instead that perhaps repo A and repo B should be joined. Or, (yes I dare say it), that perhaps the code should be duplicated.
The problem of course is that the only way to share code between repos is to create another repo. As the saying goes, once you have two things, you will soon want three.
"Oh, repo B needs to use some code in repo A. We'll just split that out into a separate repo."
Be very wary of this impulse. Soon, you end up in the situation I'm in now, where you have hundreds of tightly coupled repos, some with a single file! Worse, these all compose at runtime into only one application running on one host.
Consider instead that perhaps repo A and repo B should be joined. Or, (yes I dare say it), that perhaps the code should be duplicated.