Sharing parts of a monorepo

Question

We currently have a complex and inefficient build system consisting of many SVN and Git repos (about 50% each), including one which is a git submodules repo. We also have homemade scripts that manage more or less well the whole thing.
A major point of our (closed-source) codebase is that it is tightly coupled, and every project is released at the same time under the same version.

We want to migrate this to a simpler system and a single VCS, and are considering several options, including: git submodules, google Repo and monorepos. The final VCS is not yet defined (except for options that mandate it), and could be svn, git or even something else if that would fit our situation better.

We're trying to list the plus and minus of each solution and one of the major issue we currently have with monorepos is that it does not seem easy, or even possible to share just some modules to an external entity. We want those people to be able to checkout and work normally on those modules, but not to be able to access the code or history of the rest of the repo. It's not something we do often or extensively at the moment, but we might in the future, and we do not want this to become a nightmare because we made a bad decision here.

Does such a privilege management system exists in a VCS system?
Or is there any way to mitigate this issue?

Answer 1

From your description, I think you have a couple options here:

1. Use git submodules - with a service like GitHub (or anything else), you can manage permissions per-project and decouple your deployment process. However, I've heard that git submodules end up being a huge pain over time. Automated scripts for cleanly reinitializing/redownloading your git submodules could help here.
2. Break your repo into independent services. This allows you to develop concurrently, but also introduces a large amount of pain as you need to begin thinking about service discovery, deployment of multiple services, development environments, continuous integration/deployment, and all of the other small joys that come from managing a microservice architecture.
3. Use a formal package management system such as pip for Python, npm for Node.js, Maven for Java, etc. Deploy the pieces of code you need into the repository and consume them in your main repo as necessary, which should give you the capability to version them. Depending on the coupling between your modules and your main repo, you may not be able to actually extract, run, or test the lower-level modules independently. If you can, however, this is a pretty good way to go that gels well with multiple repositories while still being able to integrate your packages at build time by installing them from a remote repository.

Unfortunately none of these options are perfect, but they're all valid depending on the state of your codebase. Your description sounds like option 3 might work best here.