3 ms·

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.

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

glandium 11y ago
I posit that if Git or Mercurial had better workflows for submodules, monolithic repositories would seem less attractive.
- minot 11y ago
  atlassian recommends you consider sub tree as an option if you are looking at Git submodule
  - glandium 11y ago
    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.
- indygreg2 11y ago
  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.
  - glandium 11y ago
    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.

glandium 11y ago

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

minot 11y ago
atlassian recommends you consider sub tree as an option if you are looking at Git submodule
- glandium 11y ago
  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.
indygreg2 11y ago
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.
- glandium 11y ago
  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.