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

Как и с ветвлением в git, ну. Только там эти ветки дешёвые по ресурсам.

То есть тебе не надо после каждого коммита коллеги править его код под свой, ты можешь это сделать перед мержем в транк (мастер).

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

Тесты — это синтетика, и она не даёт совершенно никакой картины как всё будет вести себя в проде.

Но да, без тестов в большом проекте крайне больно.

Trunk-based development можно

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

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

И с большой можно.

С большой нельзя. Гит не вытягивает большую кодовую базу. Именно поэтому все конторы используют свои велосипеды (см. примеры выше)

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

Для ВСЕХ пользователей FreeBSD это будет небольшое упрощение в STABLE. Для разработчиков это будет удешевление (в плане ресурсов) процесса разработки.

А на пользователей других ОС разработчикам FreeBSD как бы плевать, что вполне логично, ведь они разрабатывают не те другие ОС.

С большой нельзя. Гит не вытягивает большую кодовую базу.

Зависит что для тебя большое. ☺

Вот FreeBSD — большое, и судя по удачному переходу, оно всё же вытягивает.

Именно поэтому все конторы используют свои велосипеды

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

Я пытался зафорсить мем про докеры под Windows в немецких банках…

Для разработчиков это будет удешевление (в плане ресурсов) процесса разработки.

Нельзя будет ссылаться на коммиты с помощью коротких и понятных номеров ревизий и будут ужасные длинные хеши. Теги с ревизиями как в Haiku я вижу они пока не сделали. Ломается связность, например: https://cgit.freebsd.org/src/commit/?id=546114d08ec693263d9c030c16f83ed826e4a379.

Вот FreeBSD — большое, и судя по удачному переходу, оно всё же вытягивает.

Не большое. Я писал выше что такое большое.

не прошло и 15 лет …оказывается прошло, но лучше поздно, чем через еще три президентских срока Пупынина Вадима Вадимыча

приплетаю_рашку_не_в_тему.jpg

Талант надо иметь, чтобы ТАК не в тему приплетать политоту.

будут ужасные длинные хеши

Можно использовать короткие хэши.

Ломается связность

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

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

В принципе логично, но чтобы критиковать git тебе его всё же стоит плотно пощупать, поучаствовав в каком-нибудь активном проекте, или даже нескольких, под git.

Не вижу где она тут ломается.

В коммите упоминается r368667 которого уже нет. В Haiku например связность работает: https://git.haiku-os.org/haiku/commit/?id=hrev54798. Можно нажать на hrev46195 в тексте коммита.

Выглядит иначе, потому что коммиты в git могут быть не последовательными.

В нормальном проекте не могут. Непоследовательные коммиты создают бардак.

збс

git > svn

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

Ты сам себе противоречишь тут: Видимо, правильней было бы сказать, что ребята попытались починить Hg, но в процессе написали свою VCS :)

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

Угу, я в курсе. Упоминание было к тому, что SVN с его моделью ветвления и чекаута не подходит для монорепы на 50 ГБ, иначе бы не пилили свое.

Ну и насчет DVCS… Скажем так, основное что людям надо от DVCS - это легкие ветки. А не прям distributed во все поля.

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

У себя на компьютере поправь и обнови ревью-реквест.

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

Каким образом второй разработчик вытащит себе локально правки по этой фиче?

Скачает изменения из ревью реквеста, обновит, сделает новый ревью реквест.

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

Пишете интеграцию с платёжной системой или каким-нибудь эквайером. У них часто есть sandbox разной степени упоротости. Понятно, что в боевом окружении на реальных деньгах никто не даст тестировать (никто в здравом уме не выдаст разработчик credentials от боевых систем). То есть, нужно иметь стенд, который смотрит в sandbox эквайера, чтобы потестировать flow. Также нужен подобный стенд, который смотрит в боевое окружение, чтобы прогнать предрелизные тесты перед тем, как катить всё в прод, изредка бывают ситуации, что в sandbox нельзя всё проверить и там поведение отличается. Как с помощью двух веток подобное организовать?

С git-ом делается всё просто, есть ветка master - это релизная, новая фича по интеграции с эквайером, дальше мёржим ветку в develop и проверяем песочницу. Как только с нею закончили, мёржим ветку в stage, где прогоняем предрелизные тесты в боевом окружении. Если всё хорошо, мёржим в master - релиз.

Непоследовательные коммиты создают бардак.

Бардак начинается в голове. ^_~

С чего ты взял, что я гит не щупал?

С того что я встречал противников git только среди тех, кто его не щупал. ☺ Ну вот ты оказался исключением.

С чего ты взял, что я гит не щупал?

С того что я встречал противников git только среди тех, кто его не щупал. ☺ Ну вот ты оказался исключением.

С чего ты взял что он противник? Он же просто клоун. Любит выделываться что бы все поржали.

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

Проверено: Shaman007

Твою дивизию… зашёл в кои веки на лор, вижу текст, угадываю апрувера с первой попытки.

Причем, поработав с ним недавно на одном этаже, убедился, что человек адекватный и хороший. Но каааааак, блин, Шома, кааак 😆

Насколько помню, PhoneMe использует svn, это из того что сейчас в голову пришло.

Что такое PhoneMe и почему ты считаешь это крупным проектом, стоящим в одной линейке с монорепами Windows, FB, Google?

Или просто промахнулся с ответом?

Почему не Перфорс?

Правильнее phoneMe, реализация JVM для встраиваемых устройств, достаточно крупный opensource проект, известный в своих кругах, полная репа весит несколько десятков гигобайт.

Увы, гуглится только маленький проектик на 300 мб svn dump. Ссылочку подкинешь правильную?

так я ж говорю полная репа, со всем бранчем.

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

Кстати, 50 ГБ, про которые любит говорить Reset - это не размер репы с историей, это срез исходников по одной ревизии. Полная история весит терабайты. Репозиторий Windows поменьше, там сотни гигабайт с историей (отсюда https://m.habr.com/ru/post/330056/). Но, наверное сложновато сравнивать SVN и Git по размеру репозитория. Вроде бы подход к хранению изменений сильно отличается.

они походу схлопнулись :-)

Если у тебя кодовая база проекта БОЛЬШЕ ОПЕРАЦИОННОЙ СИСТЕМЫ, то у тебя очень странный проект.

Операционная система это всего лишь запускалка программ. С какого это перепугу запускалка должна быть сложнее того что она запускает?

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

Операционная система это всего лишь запускалка программ. С какого это перепугу запускалка должна быть сложнее того что она запускает?

С того, что дерево сырцов FreeBSD включает в себя всю базовую систему. То есть весь базовый userspace, clang, VPN’ы, DNS сервер, TFTP сервер, DHCP сервер и прочее барахло. Если твой проект сложнее всей FreeBSD, то твой проект переусложненный трешак. Ну либо ты из тех сумасшедших, что рекурсивно подтягивают сырцы всех зависимостей к себе в проект.

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

Там, однозначно, этот вариант.

Для такого у гит есть на выбор submodule, subtree и subrepo.

Все делают примерно одно и тоже, но сильно по-разному.

Для ВСЕХ пользователей FreeBSD это будет небольшое упрощение в STABLE.

А вот с этого места подробнее пожалуйста.

Для ВСЕХ пользователей FreeBSD это будет небольшое упрощение в STABLE.

А вот с этого места подробнее пожалуйста.

Сколько времени требовалось для синхронизации src через svn? У меня это обычно занимало несколько минут в CURRENT, а дерево портов апалось почти десять минут, сейчас с переходом на git это будет занимать секунды. Вместо svnlite co или svnlite up будет got clone или got pull соответственно, и это единственное что изменится для пользователя, зато прирост скорости будет ощутимый.

Сколько времени требовалось для синхронизации src через svn?

Понятия не имею. Я в это время сплю обычно.

будет got clone или got pull соответственно

Правильно ли я понял, что вместо срезов base/stable/ и ports/head теперь предлагается держать у себя полные репозитории base и ports? И это не Ваши фантазии, а официальная позиция FreeBSD development team? Если так, то это охеренно, ящетаю…

предлагается держать у себя полные репозитории base и ports?

Эм… с какого перепугу? о_О Git позволяет утащить срез. Юзеру полный репозиторий без надобности.

Но возможность утащить всё — это хорошо.

официальная позиция FreeBSD development team

По этому поводу документация ещё не подготовлена (и svn-сервера ещё не потушены), потому на данный момент ограничиваемся фантазиями. ☺

Все делают примерно одно и тоже, но сильно по-разному.

Я не дебил и использую системные библиотеки.

А кто может подсказать. Что нужно сделать, чтобы в этом дивном новом мире заполнялось $FreeBSD$?

Кто-нибудь напишет, как двумя командами скачать сорцы FreeBSD 12-SATBLE и обновлять их? (Что-то я видимо отстал от Git-нотации).

Ну хоть так к примеру:

$ git clone --no-checkout --depth 1 --origin freebsd --config remote.freebsd.fetch='+refs/notes/*:refs/notes/*' https://github.com/freebsd/freebsd-src.git /path/to/repo
$ ( cd /path/to/repo && git worktree add --force --detach /usr/src freebsd/stable/12 )

Вот только никак не пойму как заставить это кю раскрывать $FreeBSD$. А без этого весь mergemaster к херам ломается.

https://github.com/freebsd/freebsd-src.git — это ссылка на какой-то тестовый репозиторий, она не включена в официальный лист.

А без этого весь mergemaster к херам ломается.

Так порты отдельно обновляются:

% cd /usr/ports/ && portsnap fetch update && pkg version -vIL =

systemsnap какой-нибудь только для скачивания и обновления сырцов будет?

Хмм… Вроде вполне себе официальное зеркало.

Не понял причём тут порты.

А, в git clone забыл: --branch stable/12.

Ну и обновлять:

$ ( cd /path/to/repo && git fetch --depth 1 )
$ ( cd /usr/src && git pull /path/to/repo freebsd/stable/12 --ff-only )

Ужас.

Distributed mirrors for anonymous read-only checkout/clone:

https://git.freebsd.org/${repo}.git
ssh://anongit@git.freebsd.org/${repo}.git

*${repo} can be replaced by doc, ports and src.

– https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md