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

Не припомню, чтобы FreeBSD Foundation выделяли на это средства.

https://www.google.nl/amp/s/amp.reddit.com/r/freebsd/comments/7zk3z6/benno_rice_says_a_diversity_consultant_will_be/

OpenBSD свой git написали.

Ну, положим, пока не убрали (как минимум у меня в 12-STABLE оно всё ещё на месте).

Но таки да, тенденции нихуя не радуют.

Взять хотя бы это: https://github.com/freebsd/pkg/commit/f446c790707993656934e0c378b64ae28cb96575

Прекрасно всё начиная с формулировки и заканчивая методом решения.

То есть раньше, если эта хипстерская хуита ёбнулась, не получив лок на свою сраную БД, это хотя бы можно было понять по exit code, то теперь – хуйвам.

с блэкджеком?

Именно.

http://gameoftrees.org

За джавой повторили, байтеры.

А , куда им бежать от болеана со спрингом ? Они вон боятся признаться кто настоящий то разработчик выдвинули своего божка торвальда да столмана и провозгласили его среди московской индульгенции ит создателя от начала до конца , все просто зачем кидать денег еще одному создателю когда надо кинуть денег московским жидкам

Можно подумать что в svn нет черрипиков.

Как в git — нет. В git оно реализовано удобно.

А ребейзы нужны только при отсутствии дисциплины и культуры разработки.

А вот и нет! С диким ветвлением (как раз как у FreeBSD) ребейз очень даже применим.

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

Нравится или нет, а стоит признать что git сильно упростил разработку.

Не гворя уже о ситуациях, когда тебе нужен код из ещё не вмерженой ветки.

Я конкретно про миграцию на git. Про финансирование дебильного CoC я помню.

// Мог бы прямую ссылку запостить, а не редирект с гугла. ☺

BTW, а как, в свете всего этого декаданса, теперь должно выглядеть обновление *-STABLE?

Подробности об этом как-то умалчивают. В handbook всё ещё svn.

Зачем бранчи от каждого разработчика? С svn работают не так.

А как? Вот нужно мне работать над двумя фичами и багом. Параллельно, потому что то стенд занят, то апдейта от партнёров ждём, то мой коллега не успел доделать его кусок и мой код пока нельзя запустить.

Я ничего не понял.

Не гворя уже о ситуациях, когда тебе нужен код из ещё не вмерженой ветки.

В svn такого просто нельзя.

Я конкретно про миграцию на git. Про финансирование дебильного CoC я помню.

Дык, на CoC потратились, на git не хватило. У них, помнится, после этого были проблемы с финансированием. Вплоть до того, что их OpenBSD по донатам обгоняли.

// Мог бы прямую ссылку запостить, а не редирект с гугла. ☺

Сорян, постил с телефона, сидя в туалете по утру.

FreeBSD как всегда плетется в конце.

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

Так эти динозавры и любители мейнфреймов, может, еще и ClearCase не выкинули. :)

Если ты -контора, пишешь софт на заказ и у тебя от транка отрастает большое количество фича-бранчей для разных клиентов, то при редких слияниях SVN хорош, В модели базара и всеобщей слегка организованной анархии, SVN--боль, конечно.

a diversity consultant will be hired to train conduct team on CoC implementation

Просто бизнес, ничего личного.

А как? Вот нужно мне работать над двумя фичами и багом.

В транк всё коммить. Фичи отделяй в конфиге фича-флагами. Фикс потом чери-пикай в стейбл.

Параллельно, потому что то стенд занят, то апдейта от партнёров ждём, то мой коллега не успел доделать его кусок и мой код пока нельзя запустить.

У вас что-то в консерватории править надо, а не решать проблемы в организации разработки с помощью другой vcs.

Дык, на CoC потратились, на git не хватило. У них, помнится, после этого были проблемы с финансированием. Вплоть до того, что их OpenBSD по донатам обгоняли.

Ну как бы логично. Донатят на кот, а FreeBSD Foundation финансирует какую-то дичь. Естественно куча патронов отписались сразу же. Любой здравомыслящий так бы и сделал, потому что CoC никак не влияет на кот, а делать социальную сеть для программистов — идея заведомо провальная в любой среде. Нормальные кодеры в одном проекте и без CoC общий язык найдут, и не станут обсуждать ориентацию/политику/прочую_дичь в devel-рассылке.

Сорян, постил с телефона

Бывает.

сидя в туалете

А ну иди читай CoC! xD

В git оно реализовано удобно.

Алиасы на баше сделай и будет как в гите.

А вот и нет! С диким ветвлением (как раз как у FreeBSD) ребейз очень даже применим.

Ветвление не нужно.

Это был долгий путь. Некоторые из участников сообщества никогда не использовали гит до этого и уже не в состоянии его освоить. Даже старый МакКьюзик незадолго до миграции на гит сделал свой последний коммит во фряшу, думаю это тоже заслуживает новости. Тем не менее, это хорошие новости для фряши и будущих членов комьюнити. Ждем 13 версию, это будет хороший релиз.

Алиасы на баше сделай и будет как в гите.

Не будет.

Ветвление не нужно.

Всё с тобой понятно. Move along. ☺

Ну как бы логично. Донатят на кот, а FreeBSD Foundation финансирует какую-то дичь. Естественно куча патронов отписались сразу же. Любой здравомыслящий так бы и сделал, потому что CoC никак не влияет на кот, а делать социальную сеть для программистов — идея заведомо провальная в любой среде. Нормальные кодеры в одном проекте и без CoC общий язык найдут, и не станут обсуждать ориентацию/политику/прочую_дичь в devel-рассылке.

Лол ты мне это рассказываешь? Я тут чаще всех про CoC вбрасываю. Алсо, я тоже отписался от донатов им. Как раз по этой причине :(

Что характерно, следующая же версия FreeBSD после появления CoC у меня не поднялась после обновления. Теперь у меня везде лялекс :(

Не будет.

Это вопрос вкуса

Всё с тобой понятно.

Зачем нужны бранчи? Не считая релизных. Еще ни один адепт гита не смог внятно ответить на этот вопрос. Как я понимаю, бранчи нужны ради самих бранчей :)

Зачем нужны бранчи? Не считая релизных.

Шоп транк/мастер не превращался в помойку из недореализованных фич. // Ваш К.О.

Еще ни один адепт гита не смог внятно ответить на этот вопрос.

Ну вот я тебе внятно только что ответил.

В транк всё коммить. Фичи отделяй в конфиге фича-флагами. Фикс потом чери-пикай в стейбл.

То есть про итеративную разработку можно забыть, да? Все коммиты вперемешку и code review каждой фичи целиком превращается в ручной трекинг твоих коммитов в транке (в транк комитишь не только ты, поэтому все в перемешку)? Ну то есть те же ветки, только руками.

У вас что-то в консерватории править надо, а не решать проблемы в организации разработки с помощью другой vcs.

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

Лол ты мне это рассказываешь? Я тут чаще всех про CoC вбрасываю.

Я ж в толксы особо не хожу. Только если кастуют. Откуда мне было знать?

Алсо, я тоже отписался от донатов им. Как раз по этой причине :(

:3

Что характерно, следующая же версия FreeBSD после появления CoC у меня не поднялась после обновления.

Не вижу прямой связи, но подозреваю, что после введения CoC код неполноценных нельзя критиковать и/или не принимать. (%

// CoC я, конечно же, не читал.

Теперь у меня везде лялекс :(

Эскобар. ☺

Шоп транк/мастер не превращался в помойку из недореализованных фич. // Ваш К.О.

Это плохой аргумент. Количество «недореализованных фич» всегда конечное число. Условно константа*число_разработчиков. Это не помойка. Если у вас не так, то надо бить по башке менеджера проекта.

Фига, я думал они до сих пор на CVS!

То есть про итеративную разработку можно забыть, да?

С чего бы это? Как раз наоборот.

Все коммиты вперемешку и code review каждой фичи целиком превращается в ручной трекинг твоих коммитов в транке (в транк комитишь не только ты, поэтому все в перемешку)? Ну то есть те же ветки, только руками.

У вас что-то в консерватории править надо. Бардак какой-то. code review делается коммитов, а не фичи. Сама фича обсуждается на design review или подобном мероприятии. Более того, это на порядок упрощает и ускоряет code review.

Это плохой аргумент.

Нет, это как раз хороший аргумент. У нас весь код, попавший в master, уже прошёл через QA перед мержем и должен работать. Если что-то в master не работает, виновный подвергается порицанию.

Что тут невнятного?

Я ж в толксы особо не хожу. Только если кастуют. Откуда мне было знать?

Ну вот! Я стараюсь, а ты даже в Talks не ходишь. Для кого я всё это делаю?

Не вижу прямой связи, но подозреваю, что после введения CoC код неполноценных нельзя критиковать и/или не принимать. (%

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

FreeBSD созрело для десктопа!

У нас весь код, попавший в master, уже прошёл через QA перед мержем и должен работать.

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

Упоролся чтоле? Я работал на одном проекте в котором в svn репу запихнули всё. И исходники, и референсные изображения по 5 гигов штука для тестов и прочее говно. Над проектом работало команд 5. Билд транка был всегда красный, постоянные конфликты при обновлении/слиянии, ветки мерджили неделями. Клон рабочей копии шёл минут 15. Бррр. Перешли на гит, выкинули ресурсы на LFS, никаких фичебранчей и мерджа, только ребейз и линейная история. Сразу билды позеленели, волосы стали блестящими и шелковистыми и девушки похорошели.

Ах да, скорость работы с репой выросла в разы!

У нас тоже, внезапно, да?

И тут же.

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

Хахахахахаха! Ну кончай отмазы лепить. Выглядит невыносимо убого же, чувак.

Это на самом деле дисциплинирует, у тебя не будет бессмысленных коммитов типа fix фикса фикса.

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

Упоролся чтоле?

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

Я работал в банке, крупнее не бывает, мы перевели svn репу нашего проекта на гит в 2014 году. Другие команды тоже. Остатки svn декомиссовали году в 17-м.

Выглядит невыносимо убого же

В чем убогость? Этот код НИКАК не влияет на продакшен. Транк ВСЕГДА зеленый, его в любой момент времени можно катнуть и при этом НИЧЕГО не сломается.

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

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

зачем нужны бранчи

Не нужны кроме релизов. Код в них быстро протухает. Лучше rebase’ить.

+1

У нас весь код, попавший в master, уже прошёл через QA перед мержем и должен работать.

Для этого есть code review системы вроде Gerrit. Ветки там только для внутреннего пользования и программисту про них знать не обязательно.

Не будет.

Это вопрос вкуса

Это вопрос функционала.

Я работал и с Subversion и с Git, разницу знаю.

Зачем нужны бранчи?

• Чтобы отделить мух (нерабочий код, код в процессе реализации, код в процессе причёсывания, что-то, что может ломать уже существующий код или тот, который может быть смержен в основную ветку в процессе) от котлет (рабочий, стабильный и проинспектированный код, готовый к бэкпортированию в другие более стабильные ветки);
• Чтобы не огребать и не доставлять проблем в процессе, когда нужно работать с чужим кодом, который в данный момент меняется;
• Чтобы можно было держать один код на несколько веток (а не скопированные данные, как это реализовано в svn), если этот код в этих ветках идентичен;
• Чтобы упростить черрипик между ветками (читай предыдущий код).

Не считая релизных.

Релизные бранчи не нужны, для этого в git есть теги. Ты, наверное, имел в виду ветки старших версий?

ни один адепт гита

Я не фанатик git. Просто стараюсь оценивать объективно, а не «оно мне не нравится потому что я его не понимаю». ☺ Вначале, конечно, относился скептически, типа «Ну зачем ещё одна VCS, когда их уже 100500?», но оказалось что оно действительно удобнее, хоть может и не проще.

бранчи нужны ради самих бранчей

Мартышка и очки Крылова читал? Сейчас большинство разработчиков примерно такие. ☺

У вас что-то в консерватории править надо. Бардак какой-то. code review делается коммитов, а не фичи.

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

Сама фича обсуждается на design review или подобном мероприятии. Более того, это на порядок упрощает и ускоряет code review.

И чо?

То есть делаем лишние сущности лишь бы не делать веток? Ох уж эти фанатики.

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

Я работал и с Subversion и с Git, разницу знаю.

Я тоже работал

Чтобы отделить мух

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

Чтобы не огребать и не доставлять проблем в процессе, когда нужно работать с чужим кодом, который в данный момент меняется;

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

Чтобы можно было держать один код на несколько веток (а не скопированные данные, как это реализовано в svn), если этот код в этих ветках идентичен;

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

Чтобы упростить черрипик между ветками (читай предыдущий код).

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

Для кого я всё это делаю?

Для товарища майора своего психиатра? xD

Т.е. переход был быстрым и безболезненным.

У меня так же было наоборот. Ну кроме ОС-специфичного.