4 ms·

you could create submodules of submodules to make an ever lasting chain too :D tbh I believe this is an organisational problem and the usefullness of the monor

you could create submodules of submodules to make an ever lasting chain too :D tbh I believe this is an organisational problem and the usefullness of the monorepo just has to be questioned in this case. If you had lets say 30 devs in your org, there would have been 300 repositories. Since they are only containers for something, the question is what does each repo actually represent? What we are trying to do is to ogranize things that belong together therefore I suggest a domain driven approach where stuff that belongs together is simply grouped together. kind of like a workspace is anyway in the end. eg: Org - Infra - DB-Servers - App-Servers - xyz Servers - App1 -x -x - App2 - etc Now the questions I would like to throw into the room is that if you need all repositories in order to build the software in front of you at the same time: why has it not been a monorepo to begin with? Subtress do seem to be the answer here I completely agree. At lesat this way you have -some- possibility to work on a subset of the code. But if you use libraries/modules/pacakges to build the product, no matter what language, testing and integration should be done on the package level, even if at least at first anyway right? So its not really a tech problem, but an organitational one. What Submodules give you, is a repository that acts kind of like a readme, and you can even deploy documents alongside those submodules easily. By adding and removing ohter repositories you are also given the possiblity to fade out tech you are no longer using and with things like background ci workers you can even keep it nicely updated. Basically built by tech to be used by humans. edit: I forgot to mention, that if one of those repos is on github, it for instance does not need to be cloned locally but can simply be clicked with a mouse and in the end you clone the repository you would like to work on.

sirwhinesalot 5y ago
All very true, I'm not suggesting a monorepo for the whole org (that's dumb) but per project. If you have libraries shared across different applications, treat those libraries as fully independent products. No different from something you'd download from NPM. Anything else is too tightly integrated, and if it is tightly integrated, you want a monorepo, not a repo with submodules. edit: At least for C++ I typically use submodules to store libraries from their own git repos, but these are very carefully versioned. If there's a good package management solution for the language, this is typically not necessary.

sirwhinesalot 5y ago

All very true, I'm not suggesting a monorepo for the whole org (that's dumb) but per project. If you have libraries shared across different applications, treat those libraries as fully independent products. No different from something you'd download from NPM. Anything else is too tightly integrated, and if it is tightly integrated, you want a monorepo, not a repo with submodules. edit: At least for C++ I typically use submodules to store libraries from their own git repos, but these are very carefully versioned. If there's a good package management solution for the language, this is typically not necessary.