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

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

А я где-то говорю, что нужно делать ОДИН коммит? Ах да, в SVN же нет локальных веток :D

Судя по тому что ты пишешь, это работает только у тебя и только потому что подобный подход был изначально(ну или в процессе) заложен в сам проект и всё с ним связанное. Но я не уверен что подобный подход универсален и даже удобен.

Так нахрена эта ветка нужна если единственное её предназначение – уехать в ревью реквест? Я не ненавижу бранчи, я не вижу в них смысла.

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

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

Блин, еще один, не читавший ссылку. Подход называется trunk based development. Применяется в крупных компаниях – Гугл, Фейсбук и т.п.

Так нахрена эта ветка нужна если единственное её предназначение – уехать в ревью реквест?

Чтобы уехать в ревью реквест. // Копетан

После вливания в мастер ветки удоляют.

Я не ненавижу бранчи, я не вижу в них смысла.

Молыж, возможно ты слепой. Я других объяснений не могу придумать.

Сделай себе с помощью bash-алиасов svn stash. На самом деле, работать на двумя фичами приходится не так часто.

Которую? Мне все комменты читать влом.

После вливания в мастер ветки удоляют.

Вот и я о том же. Поэтому они нахрен не нужны.

Загугли trunk based development или поищи по комментам тут.

Сделай себе с помощью bash-алиасов svn stash.

О, отлично, пошли костыли и попытки сделать троллейбус из хлеба и пуговиц.

На самом деле, работать на двумя фичами приходится не так часто.

На самом деле часто.

Угу, уже загуглил

О, отлично, пошли костыли и попытки сделать троллейбус из хлеба и пуговиц.

И давно unix-way стал костылем?

И давно unix-way стал костылем?

О, последний довод королей приехал. Git, оказывается, не UNIX way.

Погуглил поверхностно.

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

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

Для тех, кто не научился code review.

Для тех, кто не научился code review.

А ты к этому как пришёл? И как назвать процесс, происходящий в пуллреквестах на гитхабе, кроме как code review?

Это ортогональные вещи

ЩИТО? Как раз в крупных проектах svn рулит и педалит. Крупные это 50G и больше исходников без истории.

Спасибо, поржал!

Хороший клоун!

И как назвать процесс, происходящий в пуллреквестах на гитхабе, кроме как code review?

Там ветки выполняют техническую функцию (по другому коммит не опубликовать, *.patch файлы не поддерживаются напрямую) и в целом сделано более убого чем в Gerrit.

Там ветки выполняют техническую функцию (по другому коммит не опубликовать

можно дать право на запись в репозиторий и все будут коммитить прямо в мастер ветку без всяких пуллреквестов

все будут коммитить прямо в мастер ветку без всяких пуллреквестов

А как же code review?

видишь говно - делаешь git revert :)

видишь говно - делаешь git revert :)

И будет бесконечная война правок и revert… Потом попробуй разбери всё это.

SVN это сплошное централизованное недоразумение, без подключения к центральному репозиторию даже коммита сделать нельзя. Боль и страдания, Git после него кажется божественной росой.

Последние несколько дней проприетарная операционная система FreeBSD

fixed

Hint: BSD в названии это и про лицензию тоже.

Ты не работал в немецких банках и немецких «убийцах» SAP.

Это либо SVN/CVS или вообще отсутствие системы версионирования как класса.

Ну не ту страну Сергей Брин назвал Нигерией. Правда без снега. Но иногда он падает. На праздники типа.

С 31 по 1 весь мир будет отмечать это событие.

Я тупой виндузятник чото не понял.

После перехода с SVN на GIT FreeBSD теперь наконец начнет поддерживать кучу оборудования, под ней будет теперь многа прикладных и нужных программ, и она станет популярней чем сейчас для полутора извращенцев ?

Потому что если нет, для ВСЕХ пользователей это будет просто перестановка кроватей в борделе.

Я тупой виндузятник чото не понял.

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

Чо ты как маленький-то?

Читал, читал ваш спор. И таки не понял в чем проблема. Trunk-based development - да, есть такой подход, я только с ним в основном и работал. Сейчас это модно, CI/CD, смерджил фичу в мастер - она уже в проде( если не готов то отключай флагами) .

Но я не вижу никаких проблем с использованием git, оно не противоречит Trunk-based development.. Я сделал локальную ветку, сделал в ней 10 комитов мелких, потом запушил ее ( от греха или чтобы с другого рабочего места продолжить). Причем я иногда не уверен какая реализация лучше и делаю ветвление внутри ветки - проверяю разные варианты и возвращаюсь к лучшему. Пока работаю переключился на другую задачу, так как ты заблочился на чем-то извне -другая ветка.. И потом снова вернулся, запушил окончательный вариант, сделал pull request, прошел ревью, замерджил все в master одним комитом со сквошем и ветку удалил.. Да я это мог сделать в svn, просто не удобно.

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

Я работал с cvs, svn и git.С svn как-то помню вел долгоиграющую ветку, которая подтягивала с master изменения, там это тяжело было. .. Там даже была проблема не в конфликтах, когда правят один код. Насколько я помню ( давно это было) для svn в каждом таком мердже в комментарии комита надо писать откуда смерджился чтобы в следующий раз начать с этого места иначе просто адские конфликты ( которых на самом деле нет, просто попытка накатить один и тот же код 2 раза). В таком варианте git лучше, но во время мерджа анализирует дерево и знает что именно надо мерджить.

но поддержка железа стала значительно лучше, чем было…

Но многие USB-модемы и Wi-Fi-роутеры, в отличии от Linux, до сих пор к сожалению не работают. :(

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

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

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

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

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

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

но поддержка железа стала значительно лучше, чем было…

Но многие USB-модемы и Wi-Fi-роутеры, в отличии от Linux, до сих пор к сожалению не работают. :(

А я не утверждал что работает вотпрямвсё. Но в сравнении с тем что было лет десять назад стало ощутимо лучше. И не только с железом.

Уж я не знаю, о каких крупных конторах речь, но в некоторых достаточно крупных- вполне себе git и даже, кхы-кхы, gitlab и какой-то CI/CD на его основе.

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

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

Эту штуку лет 10 назад исправили. Помнит теперь докуда смержено.

в сравнении с тем что было лет десять назад

У меня наверное не правильная выборка, но лет десять назад я просто взял два случайных 3G-модема и они оба без проблем работали, а вот теперь (4G же, надо менять, прогресс) из 4-х испробованных во FreeBSD 4G-модемов/роутеров заработал только один(!) а в Linux-е все 4 шт.

Эту штуку лет 10 назад исправили. Помнит теперь докуда смержено

Спасибо, да я больше 10 лет его не трогал. Не в курсе, может svn стал лучше за это время :)

Ждем, когда переведут ядро своей операционки на Linux.

На спаде волны хайпа вокруг Git наконец-то решились на отказ от старой системы SVN перейти на что-то более известное БОЛЬШИНСТВУ.

По-мне, так Mercurial был бы лучшим выбором для разработчиков операционной системы с академическими корнями - это одним махом заслонило бы её от безответственных «скитальцев», которым нас..ть на поддержание целостности и стабильности протоколов.

С привлечением более молодых разработчиков, которым известен ТОЛЬКО Git, система в скором времени начнёт испытывать проблемы с целостностью историй изменений (если кому-то это будет нужно) и странные математические несоответствия заложенных в код формул (если над ним работают несколько человек, не имя других каналов общения).

Пользователю системы, использующему исходники лишь для обновления и пересборки, все эти системы управлениями версиями нужны лишь отчасти - синхронизировать исходники, посмотреть измения, всё. Насколько полон будет доступ к git-репозиторию из системы - вопрос.

Ждем, когда переведут ядро своей операционки на Linux.

Linux ABI поддерживается ядром операционной систем FreeBSD и дополнительо устанавливаемым окружением. Этого достаточно для запуска большинства современных прикладных программ для Linux, распространяющихся без исходных текстов, в бинарном виде.

До этого сообщения я был уверен, что знаю место твоей работы. Но нет.

Насчет крупных компаний:

1. В FB используеься монорепа на базе Hg. На самом деле там свой бек и клиент, но в основе лежал Hg. Кажется, Hg можно назвать git-like в плане подхода к бранчеванию.
2. Microsoft сделала для git свою VFS, для удобства разработки своего крупного проекта. Опять таки DVCS в основе.
3. Amazon вроде просто использует git. С минирепами. Не рассматриваем.
4. Yandex: пилит свою систему контроля версий, с ветками, ребейзами, длинными цепочками коммитов и так далее. Она тоже git-like. Про это есть статья на хабре, могу скинуть.
5. Google. Не знаю. Но, возможно, ты мне про это расскажешь?

При всем вышенаписанном, стоит заметить, что в FB и Яндексе пропагандируется TBD и монорепа, не смотря на пользовательские ветки. Так что SVN не нужен.

По-мне, так Mercurial был бы лучшим выбором для разработчиков операционной системы с академическими корнями

Тогда уж darcs или camp, раз академичность нужна :)

я просто взял два случайных 3G-модема и они оба без проблем работали

У меня наверное не правильная выборка

Ты просто не делаешь поправку на то что раньше девайсы делали немного "лучше". ☺ Это сейчас стараются как можно сильнее огородиться, чтобы конкретное устройство работало только с оригинальным драйвером и только в поддерживаемой ОС. Раньше такой дичью если и страдали, то только единицы.

из 4-х испробованных во FreeBSD 4G-модемов/роутеров заработал только один(!) а в Linux-е все 4 шт.

Ну так сейчас популярность (читай нужность) таких девайсов очень низкая, вот никто и не заморачивается с реализацией драйверов. Я драйвер для Gobi3000 вообще никогда не дождусь, потому что он кроме меня никому не нужен (а для Linux он есть, от самих SierraWireless, под GPL).

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

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

Подозреваю, у вас в транке нерабочая свалка,

У нас зеленый транк, который можно выкатить в любой момент. Никаких свалок нет. Почитай как работает trunk based development.

В FB используеься монорепа на базе Hg.

Ты сам себе противоречишь тут:

На самом деле там свой бек и клиент, но в основе лежал Hg

Я бы сказал, что в FB используется vcs внешне похожая на hg

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

Она git-like, но при этом не dvcs, как бы странно это не звучало :) Ну и svn в Яндексе еще жив.

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

Пагади! Ты мне тут утверждал что кодер не должен страдать, и тут же пишешь что это нормально.

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

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

У нас зеленый транк, который можно выкатить в любой момент.

Так не бывает.

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

Никаких свалок нет.

В trunk-based? Ну-ну. ☺

Почитай как работает trunk based development.

Trunk-based development можно и в Git, причём большинство так и делает. Но часто реализации новых фич идут в отдельных ветках, которые по готовности мержатся в master.

Ты не работал в немецких банках

Тот банк был как раз таки немецкий, прям так и назывался.

А то, что ИТ в Германии отсталый это другое. Там кое-где и про CI/CD-то не слышали. Куда уж им гит, с чугунным рылом.

Пагади! Ты мне тут утверждал что кодер не должен страдать, и тут же пишешь что это нормально.

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

Так не бывает.

Бывает

но это не даёт гарантий что всё работает так как задумано.

Значит надо больше тестов. Никакой подход не дает гарантий. Нужно дополнительное тестирование. Например, покатать срез транка в тестинге/престейбле пару дней.

Trunk-based development можно

Можно, если кодовая база небольшая.