Монорепа, на то и монорепа, что там все. Ну и насчет размера, как пример, репа svn на 70к+ коммитов уже занимает порядка 20гб места на диске и 70% этого места не код, а метаданные репы...

Есть ещё другая основная идея - не объединять репозитории без особой  необходимости

Чтобы было понятно, 70к коммитов команда из 5 человек забила за 6-7 лет, боюсь представить, что могут сделать 150 человек за пару лет...

Выбирая svn, вы выбираете систему с избыточностью данных. Это не к монорепе притензия, а к выбору svn.

Не спорю, но проблема монореп от смены системы vcs не меняется

не совсем понятно, зачем это все. Если нужно согласовывать межсервисную коммуникацию, то есть версионирование апи, например

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

У меня вот с монорепой стрельнул следующий момент.
В монорепе лежат исходники одной системы, которая запроектирована как набор микросервисов.
Ввиду того, что весь код в одном месте, разработчики в какой-то момент решили завести "общую либу" для микросервисов и таким образом ушли от "дублирования", например, DTO классов для запросов между микросервисами. И пошло-поехало. Спустя полтора года получили очень большую общую либу, список зависимостей, которой перешагнул за пару сотен.

Простота такого решения навеяна именно монорепой, хоть и не является причиной такого бедствия.

Я видел точно такое же с мультирепой, прям вот слово в слово)

при архитектурном надзоре таких вещей можно избегать, но времени на этот самый архитектурный надзор, вечно не хватает :)

Как только появляется некий common или util, он быстро превращается в монорему и заодно в колхоз

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

Какие-то сервисы застряли на старой версии этой либы. какие-то типа более актуальный.

Ну и да, приколачивает к одному стеку. Нельзя при разработке или рефакторинге отдельного сервиса куда-то переехать на что-то более удобные или менее глючное. Как в монолите надо устраивать рефакторинг на всю систему практически

А что мешает рядом с основной монорепой сделать репу с отдельным сервисом на нужном стеке?

у нас не монорепа. Я про кейс, когда команда пилит "велосипедный фреймворк" свой

Не думаю, что монорепа тому причина)

О да, знакомо)) Пришлось заказчику отдавать две версии исходников такой либы.

сколько погромиста не корми, он все равно свой фреймворк велосипедит :D

Не велосипедит, а творит.

Э, метаинформацией, при чем тут git вообще?