4 ms·
I've worked both at a large company (Facebook) that used the mono repo approach as well as a large company that uses the per project repo approach (Uber) and I
by vicapow 11y ago
I've worked both at a large company (Facebook) that used the mono repo approach as well as a large company that uses the per project repo approach (Uber) and I have to say I'm personally a VERY big fan of the project based repo approach but every company is different. So is every team. If you're a small company with primarily one service and primarily in one programming language, the mono-repo way seems to be the best approach. On the other hand, if you're a company that has embraced a service oriented architecture, the per project repo approach is likely the way to go. Especially if your company is OK with services being written in a variety of different languages and so long as it is as easy to use open source code as it is to use third party code written within your org. It also goes a long way in supporting local (ie., laptop) development. Otherwise, the entire codebase would be too big to fit in RAM.
Disclaimer, these opinions do not necessarily represent the opinions of my employer.
- indygreg2 11y agoIf your concerns are driven by resource requirements, then I posit your concerns are driven by limitations of fully distributed version control tools of today. Shallow and/or narrow clone (like the Subversion model) limit the amount of data required on clients and thus facilitate monolithic repositories without the extreme resource requirements on clients. I posit that if Git or Mercurial allowed you to clone a subset of directories, the differences between a monolithic repository and a set of smaller repositories becomes indistinguishable, as a clone of a sub-directory is functionally equivalent to a standalone repository! The problem is that narrow clone is not implemented in any popular DVCS tool today (but Mercurial is working on it).
- glandium 11y agoI posit that if Git or Mercurial had better workflows for submodules, monolithic repositories would seem less attractive.
- minot 11y agoatlassian recommends you consider sub tree as an option if you are looking at Git submodule
- glandium 11y agoSubtrees are nice for some use cases. But that's the very problem, there's no general (and supported out-of-the-box) solution to the problem. DVCSes have solved the distributed development part for one (sub)project, but we currently don't have a compelling solution for distributed development across several (sub)projects.
- indygreg2 11y agoI don't disagree. Although, for the case where you want to copy/move things across repositories, monolithic repositories still have the advantage that history is more easily preserved. Although you can argue that proper submodule support would handle this and preserve history.
- glandium 11y agoAlthough, for the case where you want to copy/move things across repositories, monolithic repositories still have the advantage that history is more easily preserved. Well, let's wait and see how partial clones actually handle this situation. I'm not convinced a partially cloned monolithic repository will be better than what submodules currently do.