Совместное использование частей монорепо

В настоящее время у нас есть сложная и неэффективная система сборки, состоящая из множества репозиториев SVN и Git (около 50% каждый), в том числе репозитория подмодулей git. У нас также есть домашние сценарии, которые более или менее хорошо управляют всем этим.
Основной момент нашей (с закрытым исходным кодом) кодовой базы заключается в том, что она тесно связана, и каждый проект выпускается одновременно в рамках одной и той же версии.

Мы хотим перенести это на более простую систему и одну VCS, и рассматриваем несколько вариантов, в том числе: подмодули git, Google Repo и monorepos. Окончательный VCS еще не определен (за исключением вариантов, которые его обязывают), и он может быть svn, git или даже чем-то еще, если это лучше соответствует нашей ситуации.

Мы пытаемся перечислить плюсы и минусы каждого решения, и одна из основных проблем, с которыми мы сталкиваемся в настоящее время с monorepos, заключается в том, что не представляется простым или даже невозможным поделиться только некоторыми модулями с внешней сущностью. Мы хотим, чтобы эти люди могли проверять и нормально работать с этими модулями, но не иметь доступа к коду или истории остальной части репозитория. Это не то, что мы делаем часто или активно в данный момент, но мы можем сделать это в будущем, и мы не хотим, чтобы это стало кошмаром, потому что мы приняли здесь плохое решение.

Существует ли такая система управления привилегиями в системе VCS?
Или есть ли способ смягчить эту проблему?

Из вашего описания, я думаю, у вас есть несколько вариантов здесь:

1. Используйте подмодули git - с помощью сервиса, такого как GitHub (или чего-либо еще), вы можете управлять разрешениями для каждого проекта и отделять процесс развертывания. Однако я слышал, что подмодули git со временем становятся огромной болью. Здесь могут помочь автоматические сценарии для чистой повторной инициализации / повторной загрузки ваших подмодулей git.
2. Разбейте свое репо на независимые сервисы. Это позволяет одновременно разрабатывать, но также создает большие трудности, так как вам нужно начать думать об обнаружении служб, развертывании нескольких служб, средах разработки, непрерывной интеграции / развертывании и обо всех других небольших радостях, возникающих при управлении микросервисная архитектура.
3. Используйте формальную систему управления пакетами, такую ​​как pip для Python, npm для Node.js, Maven для Java и т. Д. Разверните нужные фрагменты кода в хранилище и при необходимости используйте их в своем основном репо, что должно дать вам возможность для версии их. В зависимости от связи между вашими модулями и вашим основным репозиторием, вы не сможете фактически извлекать, запускать или тестировать модули нижнего уровня независимо. Однако, если вы можете , это довольно хороший способ, который хорошо сочетается с несколькими репозиториями, но при этом позволяет интегрировать ваши пакеты во время сборки, устанавливая их из удаленного репозитория.

К сожалению, ни один из этих вариантов не идеален, но все они действительны в зависимости от состояния вашей кодовой базы. Ваше описание звучит так, как будто вариант 3 может работать лучше всего здесь.