Если для РФ, то операторы связи вместе с услугой отправки смс для корпоративных клиентов продают услугу получения смс. Как минимум такая услуга есть у билайна, мтт и мегафона, наверняка и у остальных тоже есть. Поэтому можно не покупать непонятное устройство, просто изучите тарифы и купите номер.
Если что я не считаю что монорепозиторий - единственно верный подход, у меня есть перед глазами примеры плохих монорепозиториев. Просто те проблемы что решает монорепозиторий сабмодулями не решаются совсем никак.
Когда моно — автоматика такая, что аж на этапе коммита в одном месте билды по всему fuse-богатству идут, а вот если git-саб-модули, то строго ручной привод.
Есть реальный опыт автоматизации большого количества проектов на сабмодулях? Так чтобы проверки во всех зависимых модулях прогонялись автоматически, чтобы можно было поправить зависимый модуль если в нём начали падать тесты или компиляция? Я с самого начала просил про него рассказать.
Мой опыт работы с сабмодулями говорит что работать с ними неудобно даже когда есть всего один сабмодуль и надо внести синхронно изменения в проект и в его зависимость.
Опять же из моего опыта работы с отдельными git-репозиториями (не с сабмодулями, а просто без монорепозитория) - было два проекта, один добавил себе зависимость из второго, а второй из первого, в итоге после обновления одного из них до актуальной версии получилась циклическая зависимость - это просто следствие гибкости и отсутсвия проверок на всём стеке зависимостей.
Ну и по прежнему непонятно, что делать когда зависимость решает поменять систему сборки, начать писать на другом языке или воспользоваться новым таким стандартом языка, который в зависимых проектах не поддерживается, а раз мы топим за максимальную гибкость - такие случаи 100% будут.
Вот у нас есть большая git-репа (моно!), с кучей каталогов, одни люди клепают /mono/some/foo/bar, другие вообще /mono/something/else, при том, что последняя #include-юзает файло из этого самого bar/, и его недавно поменяли — и кому тут видно, кого затронула последняя правка этого файла? Первым? — Как? — Как? grep'ом? по всей моно-репе? На fuse? — лол! Вторым? Они давно забыли, про этот include… В случае с submodule у них хотя бы чё-то пикнуло при git pull'е.
В случае монорепозитория при изменении в /mono/some/foo/bar прогонится сборка else и если там были изменения которые поломали компиляцию или тесты /mono/something/else - такое изменение не будет вкоммичено, пока не поправят компиляцию и тесты. А если тесты прошли, то else получит свежую версию foo/bar автоматически.
В случае сабмодулей автору else надо
каким-то образом узнать про изменения в foo/bar
обновить версию самостоятельно, а у него дедлайн по своему проекту и конечно не до обновления каких-то библиотек
он может быть несогласен с изменениями в foo/bar и мог бы предложить какое-то альтернативное решение
проектов else несколько штук, каждый из которых должен пройти пункты 1-3
Другой пример, это несколько git-реп, часть из которых юзает другие через git-submodules, ответ на вопрос какие именно репы юзаются (через submodules) тривиален. Зато иерархия меняется легко и просто, она не задана каким-то одним способом, что добавляет гибкости, которой в случае с моно-репой просто нет.
Когда у тебя много проектов - гибкость становится из преимущества проклятием. У разных проектов свое представление о том какие транзитивные зависимости нужно использовать, какую систему сборки, какую версию компилятора, на каком языке писать. Любое изменение может привести к тому что те кто твой код используют решат что им выгоднее поддерживать форк, чем следовать втоим изменениям.
И ровно так же можно провернуть обратное — привязку к определённой версии «сторонней»-репы если свежие правки там оказались проблемными. Можно хоть так, хоть сяк.
И это приведет к тому что вместо исправления в "сторонней" репе люди будут жить на старой версии, потом вообще форкнут её и будут жить на форке, где тут "переиспользование кода"?
так же (не-/) помогут как и моно-репа. Серьёзно, в чем отличие? Вытаскивайте свежак, гоняйте юнит-тесты. В чём в сим аспекте принципиальное отличие-то, что это не один репозиторий? ))
Нет, в монорепе не надо ничего "вытаскивать", при изменении зависимостей сразу видно, какие потребители затронуты.
Зависимости тут если что - это внутренние общие библиотеки, а не внешнее что-то.
Если это был ваш основной довод, блин, то это лишь чёткое подтверждение тезиса NIH-синдрома.
Нет, это не мой "основной довод", просто если несколько аргументов привести то дискуссия уйдет куда-то не туда.
Почитал с чего все началось - понял что отвечал не на тот вопрос. Если что сабмодули сами по себе не решают практически ни одной проблемы, которую решает монорепозиторий. Можете почитать слайды с доклада выше, там в целом есть основная аргументация. И да, пользоваться сабмодулями для организации зависимостей если они часто меняются и надо менять зависимости паралельно с основным кодом - очень неудобно.
Что? Откуда снова берётся «большой репозиторий», если есть саб-модули?
Объясняю - сабмодули - это способ организовать иерархию мелких репозиториев и объединить их в один.
Вас не смущает, что тот же Github используют миллионы, а там вовсе не монорепа? )
Для жизни в гитхабе никаких сабмодулей не нужно, но там и уровень переиспользования кода так себе.
Ещё раз спрошу - а вы пробовали пользоваться сабмодулями или нет?
У вас какой вопрос был, почему сабмодули не подошли, или зачем нужен монорепозиторий?
Я пытался сказать что для организации монорепозитория сабмодули - плохое решение. А без монорепозитория зачем вы предлагаете сабмодули мне неясно.
Если вопрос в том зачем вообще нужен монорепозиторий то это совсем другой вопрос, я на него не пытался ответить, боюсь что для ответа на него нужна целая статья, возможно даже на хабре уже есть такая.
Для переиспользования кода - годятся, для поддержки большого репозитория в который коммитят тысячи разработчиков - так себе. Вы пробовали разрабатывать и резолвить конфликты в репозитории где есть несколько сабмодулей? Я даже когда один разрабатывал в репозитории с сабмодулями постоянно натыкался на грабли. Может конечно я просто не разобрался и на самом деле всё очень просто и легко (или с тех пор как я пробовал стало сильно лучше), было бы интересно ваш опыт узнать.
Но это же не новость, даже в самом начале статьи написано
Note: This blog was first published on 2 Feb 2022. Following the paper’s publication in Science on 8 Dec 2022, we’ve made minor updates to the text to reflect this.
Не знаю, обсуждали ли это на хабре в феврале, но на других ресурсах точно обсуждали довольно сильно.
Если для РФ, то операторы связи вместе с услугой отправки смс для корпоративных клиентов продают услугу получения смс. Как минимум такая услуга есть у билайна, мтт и мегафона, наверняка и у остальных тоже есть. Поэтому можно не покупать непонятное устройство, просто изучите тарифы и купите номер.
Если что я не считаю что монорепозиторий - единственно верный подход, у меня есть перед глазами примеры плохих монорепозиториев. Просто те проблемы что решает монорепозиторий сабмодулями не решаются совсем никак.
Есть реальный опыт автоматизации большого количества проектов на сабмодулях? Так чтобы проверки во всех зависимых модулях прогонялись автоматически, чтобы можно было поправить зависимый модуль если в нём начали падать тесты или компиляция? Я с самого начала просил про него рассказать.
Мой опыт работы с сабмодулями говорит что работать с ними неудобно даже когда есть всего один сабмодуль и надо внести синхронно изменения в проект и в его зависимость.
Опять же из моего опыта работы с отдельными git-репозиториями (не с сабмодулями, а просто без монорепозитория) - было два проекта, один добавил себе зависимость из второго, а второй из первого, в итоге после обновления одного из них до актуальной версии получилась циклическая зависимость - это просто следствие гибкости и отсутсвия проверок на всём стеке зависимостей.
Ну и по прежнему непонятно, что делать когда зависимость решает поменять систему сборки, начать писать на другом языке или воспользоваться новым таким стандартом языка, который в зависимых проектах не поддерживается, а раз мы топим за максимальную гибкость - такие случаи 100% будут.
В случае монорепозитория при изменении в /mono/some/foo/bar прогонится сборка else и если там были изменения которые поломали компиляцию или тесты /mono/something/else - такое изменение не будет вкоммичено, пока не поправят компиляцию и тесты. А если тесты прошли, то else получит свежую версию foo/bar автоматически.
В случае сабмодулей автору else надо
каким-то образом узнать про изменения в foo/bar
обновить версию самостоятельно, а у него дедлайн по своему проекту и конечно не до обновления каких-то библиотек
он может быть несогласен с изменениями в foo/bar и мог бы предложить какое-то альтернативное решение
проектов else несколько штук, каждый из которых должен пройти пункты 1-3
Когда у тебя много проектов - гибкость становится из преимущества проклятием. У разных проектов свое представление о том какие транзитивные зависимости нужно использовать, какую систему сборки, какую версию компилятора, на каком языке писать. Любое изменение может привести к тому что те кто твой код используют решат что им выгоднее поддерживать форк, чем следовать втоим изменениям.
И это приведет к тому что вместо исправления в "сторонней" репе люди будут жить на старой версии, потом вообще форкнут её и будут жить на форке, где тут "переиспользование кода"?
Нет, в монорепе не надо ничего "вытаскивать", при изменении зависимостей сразу видно, какие потребители затронуты.
Зависимости тут если что - это внутренние общие библиотеки, а не внешнее что-то.
Нет, это не мой "основной довод", просто если несколько аргументов привести то дискуссия уйдет куда-то не туда.
Для примера страница 14, хотелось бы услышать как сабмодули помогут в решении проблемы
Почитал с чего все началось - понял что отвечал не на тот вопрос. Если что сабмодули сами по себе не решают практически ни одной проблемы, которую решает монорепозиторий. Можете почитать слайды с доклада выше, там в целом есть основная аргументация. И да, пользоваться сабмодулями для организации зависимостей если они часто меняются и надо менять зависимости паралельно с основным кодом - очень неудобно.
Объясняю - сабмодули - это способ организовать иерархию мелких репозиториев и объединить их в один.
Для жизни в гитхабе никаких сабмодулей не нужно, но там и уровень переиспользования кода так себе.
Ещё раз спрошу - а вы пробовали пользоваться сабмодулями или нет?
У вас какой вопрос был, почему сабмодули не подошли, или зачем нужен монорепозиторий?
Я пытался сказать что для организации монорепозитория сабмодули - плохое решение. А без монорепозитория зачем вы предлагаете сабмодули мне неясно.
Если вопрос в том зачем вообще нужен монорепозиторий то это совсем другой вопрос, я на него не пытался ответить, боюсь что для ответа на него нужна целая статья, возможно даже на хабре уже есть такая.
Для переиспользования кода - годятся, для поддержки большого репозитория в который коммитят тысячи разработчиков - так себе. Вы пробовали разрабатывать и резолвить конфликты в репозитории где есть несколько сабмодулей? Я даже когда один разрабатывал в репозитории с сабмодулями постоянно натыкался на грабли. Может конечно я просто не разобрался и на самом деле всё очень просто и легко (или с тех пор как я пробовал стало сильно лучше), было бы интересно ваш опыт узнать.
Но это же не новость, даже в самом начале статьи написано
Не знаю, обсуждали ли это на хабре в феврале, но на других ресурсах точно обсуждали довольно сильно.