3 ms·
This is obvious to me (a monorepo advocate) but most people these days tend to organise their repos based on module/implementation lines rather than on product
by TickleSteve 7y ago
This is obvious to me (a monorepo advocate) but most people these days tend to organise their repos based on module/implementation lines rather than on product boundaries.
My motto is:
"What you release together, you should version-control together".
- Conan_Kudo 7y agoI'm a multirepo advocate, but I suggest splits similarly. Maybe it's my old-timey way of releasing software, but because I do releases as RPMs, it bothers me less if you do things like have your base library, your backend services, and your frontend in the same repo. If they need to be able to be deployed independently, I just split them up as subpackages. I guess most language package managers don't really have such a concept, so people are optimizing for that...
- ctroein89 7y agoI've learnt that for "What you release together, you should version-control together", the phrase "released together" needs to be defined as "what gets globally updated at once". If you provide anything for customers to implement, you cannot update those globally at once (because you need the customer to update), and should think about using a multi-repo set-up. My experience is that testing the interactions of historic versions of different components in a mono-repo against each other is difficult. With a multi-repo set-up, one can checkout to whatever historic version one needs to test. That makes it trivially easy to set-up testing that allows one to test historic versions of components against each.
- adrianN 7y agoI like having one repo for the project ("What you release together") that tracks subprojects as submodules.