Сообщение Re[3]: Версионнинг очень больших баз кода от 19.04.2022 5:17
Изменено 19.04.2022 5:19 vsb
Re[3]: Версионнинг очень больших баз кода
Здравствуйте, Miroff, Вы писали:
vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
M>И в чем профит такого подхода?
В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Ну у гугла, микрософта, фейсбука, твиттера, юбера, эинбнб получается, это из того, что я знаю.
vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
M>И в чем профит такого подхода?
В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Ну у гугла, микрософта, фейсбука, твиттера, юбера, эинбнб получается, это из того, что я знаю.
Re[3]: Версионнинг очень больших баз кода
Здравствуйте, Miroff, Вы писали:
vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
M>И в чем профит такого подхода?
В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.
vsb>>А чем не устраивает обычный моно-репозиторий (все проекты в одном репозитории в разных папках)? Вроде все большие так делают.
M>И в чем профит такого подхода?
В том, что нет возни с версиями, версия всегда ровно одна — последняя. И это предположительно убирает огромный пласт проблем по возне с совместимостью в каждой библиотечке. Ибо когда в каждом компоненте своя версия, есть транзитивные зависимости вроде того, что один старый компонент зависит от другого старого компонента, нужны какие-то багфиксы, и это всё превратится в ад по поддержке всех версий одновременно, ибо пользователи библиотек обновляться не хотят, им и так норм.
А когда версия одна — если хочешь что-то сломать — будь добр, пофикси всех клиентов в том же коммите. Не хочешь фиксить — значит и ломать не очень хочется.
M>Минусы очевидны: большой монорепозиторий чекаутится неделю и не влезает на диск.
Это не минусы, с большими репозиториями работают не так, у гита есть специальные расширения для решения этой проблемы.
M>А плюсы? В одном проекте ты все равно не можешь напрямую использовать код другого проекта. Потому что другой проект это зона ответственности другой команды, у которой свое видение релизного цикла и свое чувство прекрасного.
Ну у гугла, микрософта, фейсбука, твиттера, юбера, эйрбнб получается, это из того, что я знаю.