Amazon does multi-repo. I don't see what the problem or debate over this is. We seem to be handling it pretty fine despite a massive-scale SOA architecture.
Monorepo or Multirepo? Role-Based Repositories
11–20 of 120 posts
Re: Monorepo or Multirepo? Role-Based Repositories
#12Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it). I feel like these debates are ofte…
Can you elaborate on “monorepos do not prevent you from checking packages into source control” and how that helps to avoid recompiling everything? Why would you check a package into source control anyway? Surely source control is for source code? And I lean toward monorepos, btw, but there are still lots of obstacles and monorepo proponents don’t tend to acknowledge them or offer clear suggestions for how to solve or workaround them.
Re: Monorepo or Multirepo? Role-Based Repositories
#13I don't understand the isolation difference. You can hide, protect and branch code in a monorepo so why is isolation a concern?
Re: Monorepo or Multirepo? Role-Based Repositories
#14The main driver of success in either model is in the tooling and practices invested in it to make it work in an organization. Google is successful with their monorepo because they have invested in building (blaze), source control (piper, code search), and commit to always developing on HEAD. Multirepo is currently easier for most companies because most public tooling (git, package manager) is built around multirepos.…
I wonder why nobody have made a good public monorepo offering similar to what Google have internally. Would probably be a hit at many companies since it fixes so many issues related to working in very large teams.
Re: Monorepo or Multirepo? Role-Based Repositories
#15Why not both? I've been using https://github.com/mateodelnorte/meta and having a great time so far, it's just that GitHub (and others) don't have a simple way to bundle multi-repo commits in pull requests.
Re: Monorepo or Multirepo? Role-Based Repositories
#16I don't understand the isolation difference. You can hide, protect and branch code in a monorepo so why is isolation a concern?
It depends on which VCS you use. Git for example, doesn't have any native support for hiding or protecting code in particular folders within the repository.
Re: Monorepo or Multirepo? Role-Based Repositories
#17Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it). I feel like these debates are ofte…
Can you elaborate on “monorepos do not prevent you from checking packages into source control” and how that helps to avoid recompiling everything? Why would you check a package into source control anyway? Surely source control is for source code? And I lean toward monorepos, btw, but there are still lots of obstacles and monorepo proponents don’t tend to acknowledge them or offer clear suggestions for how to solve or…
You can use something like a shared binary repo such as maven or you could just check in dependencies and not worry about an external server being available for builds.
>Surely source control is for source code?
This is just pedantry. Checking in binaries is a pragmatic solution that solves a lot of problems.
Re: Monorepo or Multirepo? Role-Based Repositories
#18Monorepo shortcomings 1 and 2 seem like bullshit to me. Perforce, the popular monorepo at most companies I've worked at, supports access control. Monorepos do not prevent you from segmenting your code into modules and pushing binary/source packages into source control so that builds can avoid compiling everything(TiVo used to do this, and it worked well when you got the hang of it). I feel like these debates are ofte…
Can you elaborate on “monorepos do not prevent you from checking packages into source control” and how that helps to avoid recompiling everything? Why would you check a package into source control anyway? Surely source control is for source code? And I lean toward monorepos, btw, but there are still lots of obstacles and monorepo proponents don’t tend to acknowledge them or offer clear suggestions for how to solve or…
It's version control, not necessarily just source control! If something could benefit from being versioned, why would you not check it in? You then guarantee everybody has the same version. That's exactly what this thing is there for.
Git's design can limit its usefulness in this respect - though perhaps you could solve this to some extent with git LFS? - but not all version control systems have this problem.
Re: Monorepo or Multirepo? Role-Based Repositories
#19I don't understand the isolation difference. You can hide, protect and branch code in a monorepo so why is isolation a concern?
It depends on which VCS you use. Git for example, doesn't have any native support for hiding or protecting code in particular folders within the repository.
Hmm seems unfair to judge monorepos on what git is capable of. I hate perforce but it accomplishes this easily.
Re: Monorepo or Multirepo? Role-Based Repositories
#20There's a lot of people on here defending their current workflow, whatever that is.
I for one find it refreshing that people are willing to think about different workflows, even if they are different.
It feels like what is described is a cross between a good language package manager and git submodules. It's an interesting space to explore, because a lot of nice things come out of submodules, but it's not a proper package manager.
A proper dependency manager that puts code in a workspace and manages it as you are working on it in a non clunky way is not something we have right now and may be a game changer. Thanks for sharing to the authors.