Comment by vicapow | Hacker News Reader

Comment by vicapow | Hacker News Reader

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.

If 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).

I posit that if Git or Mercurial had better workflows for submodules, monolithic repositories would seem less attractive.

atlassian recommends you consider sub tree as an option if you are looking at Git submodule

Subtrees 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.

I 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.

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.

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.

Reply on news.ycombinator.com