4 ms·

3) A monorepo with significant investment in ecosystem and tooling is a better choise than a polyrepo For other (smaller) companies, polyrepo might be the bett

by dtech 8y ago

3) A monorepo with significant investment in ecosystem and tooling is a better choise than a polyrepo For other (smaller) companies, polyrepo might be the better choice because [significant investment in ecosystem and tooling] is not appealing, and the investments of Google et al. have not leaked through sufficiently into general available tools. Some headway is being made in the latter [1], so monorepo might be the "obvious" best choice in 10 years or so. [1] For example, Git large file support is mostly from corporate contributors https://git-lfs.github.com/ https://git-lfs.github.com/ https://github.com/Microsoft/VFSForGit https://github.com/Microsoft/VFSForGit

eadmund 8y ago
> For other (smaller) companies, polyrepo might be the better choice because [significant investment in ecosystem and tooling] is not appealing That's not the choice, though: significant investment in tooling is a function of codebase size. In my own experience, polyrepos require more tooling, because you're not just dealing with files & directories, you're also dealing with repos (& probably PRs & issues & other stuff in a forge).
- briantakita 8y ago
  Another thing is that the OP categorized "medium sized menorepos" as being too large to fit on a laptop. Maybe the companies I've worked for is limited (mainly startups & consultancies), but the entire codebase, after several years of operation, still easily fits on a single laptop. Of course there is a threshold, however this is typically a concern of a large organization or an organization that has been producing software for a decade or more.
- dtech 8y ago
  > In my own experience, polyrepos require more tooling That's not my experience. In my experience, polyrepo's significantly reduce complexity for a medium (30 developers) project. An example: the following things are good software development practices if you work with a master-PR branch model: 1. Tests must pass on CI before merging a branch to master 2. Before merging a branch into master, the latest master must be merged into the branch so that tests are still reliable This quickly becomes untenable if 30 people all commit to the same repo. By the time your PR is reviewed, it's outdated. So you merge master into your branch. By the time you come back to check your test results and merge, its outdated again. Repeat until 6 PM. So you need partial builds to keep build time low, and would probably like to amend 1 & 2 with "unless your code has zero overlap with the changes in master". These are not standard features of any CI system I know of, hence the need for tooling. Instead of tooling, polyrepo's provide the above benefits out-of-the-box. Just set your CI to build the repo, and it will do partial builds and PR-merging is uninfluenced by other repos. This is a huge advantage over monorepos. The downside is that if your repos have tight coupling, you'll need simultaneous PRs in more than 1 place or need to look up history/files in more than 1 repo. If this is more than a rare occurence, this downside is so large that polyrepo is not a suitable solution for your project. The projects of this size I've worked with did not have this problem, or the problem was solvable without much difficulty.

by dtech 8y ago

eadmund 8y ago

> For other (smaller) companies, polyrepo might be the better choice because [significant investment in ecosystem and tooling] is not appealing That's not the choice, though: significant investment in tooling is a function of codebase size. In my own experience, polyrepos require more tooling, because you're not just dealing with files & directories, you're also dealing with repos (& probably PRs & issues & other stuff in a forge).

briantakita 8y ago
Another thing is that the OP categorized "medium sized menorepos" as being too large to fit on a laptop. Maybe the companies I've worked for is limited (mainly startups & consultancies), but the entire codebase, after several years of operation, still easily fits on a single laptop. Of course there is a threshold, however this is typically a concern of a large organization or an organization that has been producing software for a decade or more.
dtech 8y ago
> In my own experience, polyrepos require more tooling That's not my experience. In my experience, polyrepo's significantly reduce complexity for a medium (30 developers) project. An example: the following things are good software development practices if you work with a master-PR branch model: 1. Tests must pass on CI before merging a branch to master 2. Before merging a branch into master, the latest master must be merged into the branch so that tests are still reliable This quickly becomes untenable if 30 people all commit to the same repo. By the time your PR is reviewed, it's outdated. So you merge master into your branch. By the time you come back to check your test results and merge, its outdated again. Repeat until 6 PM. So you need partial builds to keep build time low, and would probably like to amend 1 & 2 with "unless your code has zero overlap with the changes in master". These are not standard features of any CI system I know of, hence the need for tooling. Instead of tooling, polyrepo's provide the above benefits out-of-the-box. Just set your CI to build the repo, and it will do partial builds and PR-merging is uninfluenced by other repos. This is a huge advantage over monorepos. The downside is that if your repos have tight coupling, you'll need simultaneous PRs in more than 1 place or need to look up history/files in more than 1 repo. If this is more than a rare occurence, this downside is so large that polyrepo is not a suitable solution for your project. The projects of this size I've worked with did not have this problem, or the problem was solvable without much difficulty.