Информация об изменениях

Сообщение Re[3]: Версионнинг очень больших баз кода от 19.04.2022 5:17

Изменено 19.04.2022 5:20 vsb

Re[3]: Версионнинг очень больших баз кода
Здравствуйте, Miroff, Вы писали:

vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.


M>И в чем профит такого подхода?


В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.

А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.

M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.


Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.

M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.


Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.
Re[3]: Версионнинг очень больших баз кода
Здравствуйте, Miroff, Вы писали:

vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.


M>И в чем профит такого подхода?


В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.

А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.

M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.


Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.

M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.


Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю. Понятно, что такая модель разработки требует адаптации команд и готовности делать (и принимать) пул-реквесты в чужие проекты.