Завершён переход FreeBSD с системы контроля версий Subversion на Git

Этот код НИКАК не влияет на продакшен.

А если влияет? Если там изменение где-то в корневом функционале?

Пока не убедительно звучит

Тебя разве кто-то убеждает здесь? Я вот по большей части ржу над твоими оправданиями. Совать флаги компиляции в код чтобы компенсировать убогость контроля версий – какой-то мазохистский шик.

Ну и про миллионы мух это не аргумент.

Интересно, какой процент кандидатов послали твою компанию к лешему, услышав про svn на собеседовании?

На code review обсуждается код всех коммитов фичи целиком, очевидно же.

Не очевидно. code review это ТОЛЬКО ревью коммита.

Потому этот код, внезапно, логически связан.

И что? У тебя фича может занимать в конечном варианте 1000 строк, 10000 строк и т.п. Если делать ревью как ты говоришь, то в транк она попадет через полгода, год и т.п. Я это всё уже проходил. Этот подход не работает.

И чо?

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

А если влияет? Если там изменение где-то в корневом функционале?

На это есть тесты, очевидно же.

Совать флаги компиляции в код чтобы компенсировать убогость контроля версий – какой-то мазохистский шик.

ЩИТО? Какие нахер флаги компиляции? Фича-флаги это настройки, приезжающие из конфигов или из запросов.

Интересно, какой процент кандидатов послали твою компанию к лешему, услышав про svn на собеседовании?

0

Ага. Их и ребейзят. От целевой ветки :)

Возможно ли сделать так, чтобы все ветки были применены в master и всё автоматически rebase’илось при вызове git pull --rebase?

Я не хочу руками rebase’ить каждую ветку.

https://www.toptal.com/software/trunk-based-development-git-flow

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

В git бранчи совсем дешёвые в плане дискового пространства и переключения между бранчами с сохранением трека, потому уровней "стабильности" (а соответственно и бранчей) может быть больше одного только trunk (master). Все коммитят в кучу, QA эту кучу разгребает (спасибо ребейзу за мерж-коммиты, которые это дело упрощают) дальше, RelEng и SecTeam так же разгребают дальше, и вот релиз готов! Почти конвейер.

Замечательно, тогда огребет разработчик фичи при мерже. Нет уж, правильно это когда все проблемы решает тот, кто делает рефакторинг, он должен чинить чужой меняющийся код и «огребать».

Не огребает, потому что дальше он делает дифф и ребейзит снова свой код перед пушем для актуализации. Рефактор делается тем, кто в этом (своём!) коде разбирается, и делается практически безболезненно.

Это про оптимизацию хранилища в vcs? Почему это должно волновать разработчика?

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

Он и так простой.

Относительно сложности операции. В git это делается просто и очевидно.

Очевидно, черрипикаться должны только фиксы.

А как же бэкпортирование фич между стабильными ветками (типа 11-STABLE и 12-STABLE)? А как же бэкпортирование из стабильных веток в master (trunk)?

Понятно что это не нужно на (простом) проекте под заказчика, но мир за аутсорс не заканчивается.

Если «фикс» по объему тянет на новую фичу, то лучше так не делать, а просто катить новый релиз – проблем меньше будет.

Это так не работает с очень большими проектами, увы. Иначе сейчас был бы Java 100500^over9000 вместо 18. Впрочем, к этому всё и идёт, IT катится в глубокую задницу, из которой уже никогда не выберется… ☹

Не огребает, потому что дальше он делает дифф и ребейзит снова свой код перед пушем для актуализации.

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

А как же бэкпортирование фич между стабильными ветками (типа 11-STABLE и 12-STABLE)?

В стейбл ветках ТОЛЬКО фиксы

А как же бэкпортирование из стабильных веток в master (trunk)?

В стабильных ветках НЕТ разработки

Транк ВСЕГДА зеленый, если нужны новые фичи, то катишь новый транк. Нет никакого смысла держать стейбл-бранч по полгода.

Это так не работает с очень большими проектами, увы.

Репа на 50G это очень большой проект или недостаточно большой?

В стейбл ветках ТОЛЬКО фиксы

В стабильных ветках НЕТ разработки

+1

Релизы на то и релизы что они фиксируют функциональность.

Возможно ли сделать так, чтобы все ветки были применены в master и всё автоматически rebase’илось при вызове git pull –rebase?

Возможно.

Возможно.

Как? Простыни Bash скриптов не предлагать. Тут пишут что нельзя.

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

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

В стейбл ветках ТОЛЬКО фиксы

Ещё раз: в git бранчи по ресурсам дешёвые, уровней "стабильности" может быть больше одного.

В стабильных ветках НЕТ разработки

Не совсем, но в общем я с тобой согласен.

Транк ВСЕГДА зеленый, если нужны новые фичи, то катишь новый транк. Нет никакого смысла держать стейбл-бранч по полгода.

Дядь, вылезай из криокамеры-аутсорса, окда? ☺

Я не утверждаю что Subversion плох сам по себе, он плох в сравнении. ☺

Но да, для совсем уж простых проектов Git — это из пушки по воробьям, но с другой стороны по ресурсам выходит дешевле.

Не очевидно. code review это ТОЛЬКО ревью коммита.

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

И что? У тебя фича может занимать в конечном варианте 1000 строк, 10000 строк и т.п. Если делать ревью как ты говоришь, то в транк она попадет через полгода, год и т.п. Я это всё уже проходил.

Лол что за бред.

Этот подход не работает.

У тебя не работает, у всего остального мира работает.

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

Иии? В дизайн-доке описывается «мы хотим чтобы наш софт вел себя так и так». Это может быть закодировано сотней разных вариантов.

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

В Gerrit всё это есть безо всяких веток (relation chain, topic).

В Git все это есть безо всяких Gerrit.

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

В Gerrit всё это есть безо всяких веток (relation chain, topic).

«От $drug_1 так штырит!» — «От $drug_2 тоже так штырит но отходняк другой.»

Когда до вас дойдёт что это всё разные инструменты с разным подходом. Цель в общем одна, но в деталях отличается область применения. И git покрывает больше таких областей.

$ git pull –rebase $ git rebase master

Алиас, наверное, сможешь сделать сам.

Когда до вас дойдёт что это всё разные инструменты с разным подходом. Цель в общем одна, но в деталях отличается область применения. И git покрывает больше таких областей.

Что бы мы без тебя делали. Git и Gerrit – разные инструменты. Вау. Вот это новость. Мне кажется, стоит написать в какой-то научный журнал.

Ещё жизненные мудрости, профессор?

Юношеская любовь считай. Я свой путь в unix-like с 5.2 начинал и довольно долго на десктопе использовал. Потом из-за лучшей поддержки железа на линукс перекатился.

Бранчи нужны чтобы хранить промежуточные результаты работы на сервере не ломая основную ветку. Ещё и с историей изменений, а не кучу тарников хренпоймигде.

Бранчи нужны чтобы хранить промежуточные результаты работы на сервере не ломая основную ветку.

Для этого есть Gerrit. А бранчи не нужны.

Я свой путь в unix-like с 5.2 начинал и довольно долго на десктопе использовал.

:3

Я позже вкотился, где-то на 6.x, точно уже не помню. И тоже потом выкотился. Но то что творится сейчас в Linux разрушает мою нервную систему, потому я перекотился обратно. Десктоп, конечно, из FreeBSD и сейчас с натяжкой совы на глобус, но поддержка железа стала значительно лучше, чем было (хоть и не сравнить с покрытием в Linux).

Gerrit вообще не для этого нужен.

Gerrit вообще не для этого нужен.

И для этого тоже. Позволяет хранить и организовывать изменения, не внесённые в upstream. Есть индикация что изменения upstream сломали хранящиеся изменения.

Он огребает минимально,

А не должен огребать совсем

потому что это его код и код с которым он работает.

Это не его код, а общий код. Код фирмы.

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

Как показывает практика, не вынуждает.

в худшем — ненависть со стороны автора этого кода.

В этим к психотерапевту

Ещё раз: в git бранчи по ресурсам дешёвые, уровней «стабильности» может быть больше одного.

Их должно быть 2. Остальное – увеличение сложности на пустом месте.

А теперь представь, что у тебя для реализации фичи требуется сделать 10, скажем, коммитов.

Типичная ситуация. И?

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

Не смотрят. Еще раз. 10 маленьких коммитов просмотреть проще и быстрее чем 1 большой. Когда смотришь 1 большой, то теряешь контекст изменений и ревью превращается в ад.

Иии? В дизайн-доке описывается «мы хотим чтобы наш софт вел себя так и так».

Нет, описывается как именно будет это решаться. А тут уже остается ограниченный набор способов.

Я выше уже объяснил, что ничего не ломается.

На это есть тесты, очевидно же.

Как тесты помогут при сломанном API, который требует изменений по всей кодовой базе?

ЩИТО? Какие нахер флаги компиляции? Фича-флаги это настройки, приезжающие из конфигов или из запросов.

Ещё прекраснее! Добавлять дополнительные флаги в конфигурацию, потому что у тебя убогая система контроля версий. Так победим!

0

Наверное, потому что они до вас тупо не дошли. Я вот в 2020 не представляю человека, который готов идти писать код в компанию, где до сих пор SVN. Только если за очень большие деньги. Либо если он реально ненавидит себя.

Не смотрят. Еще раз. 10 маленьких коммитов просмотреть проще и быстрее чем 1 большой. Когда смотришь 1 большой, то теряешь контекст изменений и ревью превращается в ад.

У тебя шизофрения?

• Смотри, вот люди смотрят десять маленьких коммитов за один раз…

• НЕТ ОНИ СМОТРЯТ. ДЕСЯТЬ МАЛЕНЬКИХ КОММИТОВ ПРОСМОТРЕТЬ ПРОЩЕ ЧЕМ ОДИН БОЛЬШОЙ.

Нет, описывается как именно будет это решаться. А тут уже остается ограниченный набор способов.

Либо описываются общие подходы, либо ты пишешь код прямо на дизайн-сессии. Если второе, то зачем тебе ревью? :)

Как тесты помогут при сломанном API, который требует изменений по всей кодовой базе?

Тесты на api, очевидно же!

Добавлять дополнительные флаги в конфигурацию, потому что у тебя убогая система контроля версий. Так победим!

Я выше написал, что тебе в любом случае придется их добавлять, даже если у тебя «неубогая» система контроля версий. А как иначе? Ты фичу сразу на всех пользователей катишь? А если она в каких-то случаях работает плохо?

Наверное, потому что они до вас тупо не дошли.

У нас конкурс 100 человек на место. Очередь стоит из желающих.

Какие нафиг общие подходы? Если ты описываешь поведение, но не описываешь как оно будет реализовано. Какие новые компоненты ты напишешь и как это будет взаимодействовать, то в 99.99% случаев в результате получится нерабочая херь.

Шизофрения это в одном ревью мешать изменения документации, апи, бэка …

Тесты на api, очевидно же!

Окей, тесты сказали тебе то, что ты и так уже знаешь: API сломан. Дальше что?

У нас конкурс 100 человек на место. Очередь стоит из желающих.

В вашу палату? Больницы переполнены?

Тесты на api, очевидно же!

Чувак, ты теряешь нить диалога. Возвращайся!

Смотри: ты меняешь api библиотеки, от которой зависит весь остальной проект. Это требует изменений во всём остальном проекте. Пусть мелких, но тем не менее. Как ты это в флаг конфигурации-то обернёшь?

У нас конкурс 100 человек на место. Очередь стоит из желающих.

Твоя компания – сортир в Диснейленде, что ли?

Окей, тесты сказали тебе то, что ты и так уже знаешь: API сломан. Дальше что?

Править коммит, очевидно. Коммит, ломающий api, вообще не должен попадать в транк. А как иначе?

Какие нафиг общие подходы? Если ты описываешь поведение, но не описываешь как оно будет реализовано. Какие новые компоненты ты напишешь и как это будет взаимодействовать, то в 99.99% случаев в результате получится нерабочая херь.

Ты понимаешь, что в дизайне не описывается код? Не описывается, какие параметры у функций меняются, как меняются блокировки в коде и прочее.

Шизофрения это в одном ревью мешать изменения документации, апи, бэка …

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

P.S. Я кажется понял. Reset не знает про серии патчей, потому что в SVN этого сделать нельзя :D

Смотри: ты меняешь api библиотеки, от которой зависит весь остальной проект. Это требует изменений во всём остальном проекте. Пусть мелких, но тем не менее.

Я меняю api и правлю все проекты. Внезапно, да ?

Чувак, ты теряешь нить диалога.

Хорош меня чуваком называть, своих собутыльников так называй.

Править коммит, очевидно. Коммит, ломающий api, вообще не должен попадать в транк. А как иначе?

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

Хорош меня чуваком называть, своих собутыльников так называй.

Хорошо, малыш. Собутыльников я малышами не называю, поэтому тебя, наверное, можно.

Ты понимаешь, что в дизайне не описывается код?

Я и не описываю там код. Я описываю компоненты и их взаимодействие. Посмотри, например, как это сделано в открытых проектах. Например, посмотри KIP’ы в Kafka.

Править коммит, очевидно. Коммит, ломающий api, вообще не должен попадать в транк. А как иначе?

API сломан в рамках реализации новой фичи. Ну вот так вышло, старый имел большие ограничения.

Но где же его хранить?

Внутри ревью-реквеста. Внезапно, правда?

Особенно, если это изменение нужно сделать серией коммитов

Если эти изменения нельзя делать сразу, то делается api/v2. Ты статью на которую я ссылку выше давал читал? Эти все «проблемы» давно решены и по сути проблемами не являются и не нужна никакая магическая «правильная» vcs.

Такого не бывает

Я и не описываю там код. Я описываю компоненты и их взаимодействие.

Вот именно. Поэтому дизайн не помогает тебе оценивать РЕАЛИЗАЦИЮ. Ты понимаешь разницу между МЫ ТАК ХОТЕЛИ и МЫ ТАК СДЕЛАЛИ?

Внутри ревью-реквеста. Внезапно, правда?

Ага. А теперь представь, для чего используются бранчи в гите.

Если эти изменения нельзя делать сразу, то делается api/v2.

Зачем? Если можно просто серией коммитов всё поправить, не ломая master при этом. Ну кроме того, что у тебя жопу рвёт от слова branch.

Эти все «проблемы» давно решены и по сути проблемами не являются

Ага. В git.

Очень даже помогает. Мне не нужно смотреть 10000 строк кода для оценки реализации отдельных компонент.

Очень даже помогает. Мне не нужно смотреть 10000 строк кода для оценки реализации отдельных компонент.

То есть на code review вы не читаете код? А потом мы удивляемся, откуда дыры в приложении :D

Зачем? Если можно просто серией коммитов всё поправить, не ломая master при этом.

Нахрена? Поправь внутри ревью-реквеста пока он не позеленеет. Бранчи тут не нужны. Ты похоже под бранчем понимаешь интерфейс к ревью реквесту.

Такого не бывает

То есть мажорные версии библиотек с несовместимым API придуманы жыдами. Сестра, галоперидолу!

Нахрена? Поправь внутри ревью-реквеста пока он не позеленеет. Бранчи тут не нужны. Ты похоже под бранчем понимаешь интерфейс к ревью реквесту.

Где править-то, если веток нету :D

Ты опять передергиваешь. Это все оценивается отдельными коммитами гораздо проще и быстрее. Вот нахера всё мешать в одном реквесте и апи и бэк и фронт и доки? Это бесполезно и даже вредно!

Нахрена?

Потому что так удобнее? Тебе анонимус про серии патчей выше рассказал.

Бранчи тут не нужны. Ты похоже под бранчем понимаешь интерфейс к ревью реквесту.

Под бранчем я понимаю отдельную ветку в репозитарии.

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

У себя на компьютере поправь и обнови ревью-реквест. Я смотрю у кого-то шаблон порвался о того, что ревью-реквест оказывается можно править и без веток.