Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Very thorough and well balanced article. Congratulations.

I'm still in the multi-repo camp for the following reasons:

-It's true that in both case special tooling will eventually need to be created, but I think that special tooling that sits on top of VCS is easier than tooling that requires actually improving the VCS themselves.

-The article mentions that in a mono repo allows you to more easily fix things yourself, but in practice you should not fix things yourself because you'll be slower and/or make more mistakes than the people that are experts in this area of the code. Making hard for any person to fix any random piece of the code is a feature of multi-repos.

-"when reality dictates that things the used to be coupled should be decoupled or things that used to be decoupled need to be joined closer together" Again, making it hard to couple code together is a feature.

-Re-usability of mono-repos is 0.



> The article mentions that in a mono repo allows you to more easily fix things yourself, but in practice you should not fix things yourself because you'll be slower and/or make more mistakes than the people that are experts in this area of the code. Making hard for any person to fix any random piece of the code is a feature of multi-repos.

I disagree: nothing's worse than when someone changes one of my dependencies. I know nothing about his API or why he changed it, and now I have to figure out what he did and why.

In a professional organisation, the cost of a change should be borne by the one making it, not by others. I shouldn't be able to hold another team back by pursuing my bliss.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: