LINUX.ORG.RU

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

 , , ,


1

0

Последние несколько дней свободная операционная система FreeBSD переходила от своей разработки, которая велась с помощью Subversion, к использованию распределенной системы контроля версий Git, которая используется в большинстве других проектов с открытым исходным кодом.

Переход FreeBSD с Subversion на Git состоялся. Миграция была завершена на днях, и теперь новый код поступает в их основной репозиторий Git и на Github.

>>> Подробности

★★★★

Проверено: Shaman007 ()
Последнее исправление: demidrol (всего исправлений: 1)

Ответ на: комментарий от Reset

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

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

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

И чо?

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

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

0

Reset ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от Reset

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

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

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

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

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

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

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

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

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

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

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

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

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

mord0d ★★★★★
()
Ответ на: комментарий от mord0d

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

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

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

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

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

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

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

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

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

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 2)
Ответ на: комментарий от Reset

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

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

+1

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

Возможно.

anonymous
()
Ответ на: комментарий от Reset

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

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

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

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

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

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

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

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


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

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

mord0d ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

X512 ★★★★★
()
Ответ на: комментарий от X512

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

anonymous
()
Ответ на: комментарий от X512

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

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

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

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

mord0d ★★★★★
()
Ответ на: комментарий от X512

$ git pull –rebase $ git rebase master

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

anonymous
()
Ответ на: комментарий от mord0d

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

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

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

anonymous
()
Ответ на: комментарий от mord0d

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Reset

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

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

X512 ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

:3

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

mord0d ★★★★★
()
Ответ на: комментарий от Dark_SavanT

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

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

X512 ★★★★★
()
Последнее исправление: X512 (всего исправлений: 1)
Ответ на: комментарий от mord0d

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

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

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

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

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

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

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

Reset ★★★★★
()
Последнее исправление: Reset (всего исправлений: 1)
Ответ на: комментарий от Reset

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

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

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

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

0

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от Reset

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от hateyoufeel

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

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

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

anonymous
()
Ответ на: комментарий от Reset

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

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

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

anonymous
()
Ответ на: комментарий от hateyoufeel

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

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

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

hateyoufeel ★★★★★
()
Последнее исправление: hateyoufeel (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

anonymous
()
Ответ на: комментарий от hateyoufeel

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

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

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

anonymous
()
Ответ на: комментарий от Reset

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

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

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

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

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

Ага. В git.

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

anonymous
()
Ответ на: комментарий от hateyoufeel

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

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

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

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

anonymous
()
Ответ на: комментарий от Reset

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

Нахрена?

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

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

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

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от anonymous

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

Reset ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.