NetBSD переходит на Mercurial. И Git. Одновременно.

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

Это какое-то очень-очень странное заявление. Этой «кастой» до появления dvcs были чуть менее чем поголовно все, потому что путь CVS → SVN → git прошло большинство взрослых проектов.

Я хочу сказать, что косяков, вызванных этим, я видел тоже достаточно. Так что, повторюсь, «что одно говно, что другое». Обосраться на ровном месте вообще не сложно.

Так нет же. Только одно говно. Второе не говно, потому что просто работает.

Если Вам нужно знать историю переименования файла – то это какая-то сторонняя проблема. Ну назывался он иначе, и зачем это знать?

Ты не понял. Суть не в истории переименования, суть в отслеживании изменений через это переименование. Особенно git начинает лажать, когда было не переименование, а разбитие файла на два или перемещение больших кусков кода между файлами. Я видел ложные срабатывания в таких случаях, и это может быть довольно неприятно.

У них всё ещё репа не должна превышать 1ГБ, чтобы считаться здоровым. Возможно есть какие-то инструменты поверх. Ну и ладно.

У кого у них? В Mercurial? Нет, это не так.

Это верно. С появлением NVMe и уходом вращающихся дисков (куда им и дорога), заметить разницу нереально.

Реально, но на достаточно больших репозитариях. Ядро Linux является одним из таких. Аналогом для Mercurial будет репозитарий Firefox (https://hg.mozilla.org/mozilla-central/).

У него ядро простое как топор. Остальное всё сверху навешано.

Так ядро или формат данных? Потому что это разные вещи. Формат данных и у Mercurial не то чтобы сложный.

Там ядро простое. Изначально это вообще было 80 строк кода – закатать в блоб, вычислить SHA1, поместить этот блоб куда-то там.

Ага, Mercurial так же работает, плюс фишки типа трекинга имён. Ваще ничего сложного.

Это какое-то очень-очень странное заявление. Этой «кастой» до появления dvcs были чуть менее чем поголовно все, потому что путь CVS → SVN → git прошло большинство взрослых проектов.

Эти чуть менее чем поголовно все уже на пенсию выходят, чувак. Многим программистам, начинавшим сразу с git/hg, скоро будет 40 уже при среднем возрасте в индустрии около 28. А если учесть многократный рост индустрии в последние 15 лет, количество пользователей svn оказывается весьма незначительным. Людей же, использовавших CVS где-то, я лично вообще не встречал за пределами тусовок вокруг BSD.

Эти чуть менее чем поголовно все уже на пенсию выходят, чувак. Многим программистам, начинавшим сразу с git/hg, скоро будет 40 уже при среднем возрасте в индустрии около 28. А если учесть многократный рост индустрии в последние 15 лет, количество пользователей svn оказывается весьма незначительным.

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

К чему ты сейчас сюда примешиваешь сравнение той индустрии с этой?

Так это ты его подмешиваешь, когда пишешь про опыт с svn в контексте обсуждения hg. Хер знает, зачем ты это сюда вообще приплёл.

В свн не нужно ничего клонировать, репа одна. Забираешь из неё только нужные для текущей ревизии файлы.

У меня нету ничего. Мне нужно собрать проект локально. Нужно забрать всё.

Я сравнивал конкретные фичи с использованием накопленного в индустрии опыта. Ты начал блеять о каких-то кастах и сравнениях аудиторий svn тех времён с индустрией этих. Ещё раз, зачем? Чтобы показать безосновательность моих выводов? Мимо. Опыт с svn был всеобъемлющ, потому что какое-то время svn использовали почти все. И svn mv/cp не работал. Я утверждаю на основании этого опыта что mv/cp не будет работать, и ни размер индустрии, ни то что ты напишешь вместо роли играть не будет. А --follow работал и работает. Вот и всё.

Это вывих мозга - две системы одновременно.

CVS → SVN → git прошло большинство взрослых проектов.

Были ещё платные БитКипер и Перфорс. И может даже есть до сих пор.

Кстати, Гит наследовал многое от БитКипера. А от CVS и SVN он старательно не наследовал ничего (потому что они by design убоги).

В свн не нужно ничего клонировать, репа одна. Забираешь из неё только нужные для текущей ревизии файлы.

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

Были ещё платные БитКипер и Перфорс. И может даже есть до сих пор.

Платные не были и быть не могли, пока мы о СПО сообществе говорим. В конторках-то чего только не было, включая ещё микрософтовские поделки типа vss.

Анон, ты не поверишь, но Mercurial ещё жив.

nginx переезжает на GitHub (комментарий)

А что-то из крупных и значимых проектов осталось на этом Mercurial?

P.S. NetBSD незначимый проект.

Я не понимаю, почему они свн дропнули, логичный же переход цвс->свн.

У кого у них? В Mercurial?

У Гита.

Так ядро или формат данных? Потому что это разные вещи. Формат данных и у Mercurial не то чтобы сложный.

Логика закатывания и логика хранения. Если где-то что-то отвалится. Включая сдохший сектор диска. Чтобы по цепочке всё остальное не подохло.

Или во время закатывания, какой-то ультра-алгоритм не внесёт ненужного чего-то.

Если ядро простое, то его вероятность отказа минимальна.

Если формат простой, то его вероятность октаза (при хранении, при сбоях оборудования на холодном репозитории) минимальная. Простое в данном случае – именно как топор.

Ну и проще Гита ничего нету. Он же элементарен в своём внутреннем устройстве.

Ага, Mercurial так же работает, плюс фишки типа трекинга имён. Ваще ничего сложного.

У них сложнее устройство. И процессы сами сложнее. Как он там имена файлов отслеживает и всё остальное. И как считается тогда хэш фиксации? Отслеживание тоже в хэш попадает? Если нет, то это просто сторонняя фишка. И в целом для неё Ртуть не нужна. Если да – то это сомнительное решение.

Анонимус выдал базу.

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

А я вот как раз помню время, когда эти svn-адепты Subversion напыщенно шипели на тех, кто ещё в 2008-2010 года перелазил на Git, GitHub и BitBucket (пусть с Mercurial), называя их чем-то вроде «хипстеров с подворотами», хотя на то время там что-то другое было.

Но время расставило всё по своим местам. В итоге пользователи Subversion по иронии судьбы остались у разбитого корыта и дай-то бог хотя бы со срезами в архивах без истории, тогда как у «хипстеров с подворотами» вся их история разработки и все исходники с 2008 году в репах как были запушены так и доступны до сих пор.

А разгадка проста. Как только «держащий» SVN-репозиторий отходил от дел по каким-то причинам в IRL, сервер моментально умирал, а пользователи которым был нужен код проекта, как последние виндузятники опрашивали по почте бывших участников не осталось ли у них чекаута хоть на какое-то там время, клянчили архивчик и потом с утерянной историей что-то там продолжали ковыряться.

Сколько проектов и репозиториев эта SVN-мразь таким образом в итоге погубила – не счесть. Так что смело плюйте в лицо тем, кто предлагает вам использовать SVN в 2025 году. Проще сразу rm -Rf своему коду сделайте.

Нет, тебе нужно забрать только последнюю ревизию (версию).

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

Скажи, ЛОР, что ты думаешь по этому поводу?

Я думаю не спроста в любой организованной группе людей первым делом выбирают руководителя.

Если в проекте столько идиотов-ретроградов что медленный, неудобный и вообще мёртвый меркуриал вообще рассматривался как вариант

Ты же в курсе, что такое NetBSD?

не включая перфоратор

Где-то у Гугла видел текстовый README (а не Markdown или что-то иное). В репозитории. Автор объяснял даже этот выбор как-то.

Видимо ретардство – неотъемлемая часть отрасли на всех уровнях.

ClearCase ещё забыл.

Платные не были и быть не могли, пока мы о СПО сообществе говорим.

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

Или стоит уже наконец отказаться от git и перейти на Mercurial?

Что лучше знает инициатор, на то и переходят.

Тут где-то firkax должен рассказывать, что это не баг, а фича. И вообще, делайте бэкапы.

ClearCase – это самое потрясающее что я видел на своём веку. В Мотороле была команда админов только чтобы это говно поддерживать в рабочем состоянии и отвечать на нытьё юзеров о том, что CC им выдал непонятную ошибку (они реально были непонятные).

У Гита.

У меня пачка репов размером сильно больше гига и всё ок.

Если да – то это сомнительное решение.

Нет в нём ничего сомнительного. git так же хранит атрибуты файлов вместе с данными.

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

Motorola наверное была одним из самых активных и крупных потребителей ClearCase. Эти /vobs/ мне в страшных снах снятся до сих пор, как и захардкоженные полные пути в исходниках (хедеры) начинающиеся с /vobs/, а уж сколько баек было о том, как сотрудники Motorola в командировках в США где тогда был быстрый инет (речь про 2003-2005 годы) качали фильмы торрентами, заливали их в ClearCase и потом выкачивали на работе и записывали на флешки…

У меня пачка репов размером сильно больше гига и всё ок.

git-sizer

Happy Git repositories are all alike; every unhappy Git repository is unhappy in its own way. —Linus Tolstoy

Is the repository too big overall? Ideally, Git repositories should be under 1 GiB, and (without special handling) they start to get unwieldy over 5 GiB. Big repositories take a long time to clone and repack, and take a lot of disk space.

Пишут, что до 1ГБ – идеально. После 5ГБ – громоздко.

Нет в нём ничего сомнительного. git так же хранит атрибуты файлов вместе с данными.

Вопрос, как вычисляется контрольная сумма. Если данные легко присолить, и это ничего не сломает, то её и подделать много проще. К тому же какие-то там метаданные (если они есть) вряд ли видны при diff. А значит никто и не заметит подлога.

Но я так понимаю, что Ртуть по своему устройству хранит разницу. И вынуждена обходить историю. Что упрощает отслеживание изменений. А Гит для получения разницы между двумя фиксациями не нуждается ни в какой истории. Он просто сравнивает два варианта. И это играет роль. Если так, то проход по всей истории должен решить проблему.

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

И это просто вопрос реализации конкретного функционала в Гите.

Анонимус выдал кринж.

У меня пачка репов размером сильно больше гига и всё ок.

git-sizer

И что именно оно должно мне посчитать?

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

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

Все правильно сказал. Любая технология развивается до момента good enough, когда ее замена несет больше страдания, чем пользы. Git — единственная система контроля версий, которую имеет смысл использовать, если руководствоваться соотношением пользы к затраченным усилиям на поддержку процессов. Есть нишевые случаи, но топик не про них.

Любая технология развивается до момента good enough, когда ее замена несет больше страдания, чем пользы.

А является ли git этим «good enough»? Я вот не уверен.

С другой стороны, замена git тоже не является чем-то из ряда вон фантастическим, потому что конверсия или прозрачное проксирование (как у NetBSD) вполне возможны, как и возможно построение новых инструментов на базе git, радикально от него отличающихся (как вышеупомянутый jj).

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

А является ли git этим «good enough»? Я вот не уверен.

А есть аргументы против? Все workflow уже готовы, на любой вкус. Документация написана. Любой джун постигает необходимые команды для работы за два дня при правильном обучении. Есть что-то, что лучше делает какую-то особую часть, которую Git делает хуже? Да. Есть что-то, что делает весь процесс разработки лучше, чем Git? Нет.

С другой стороны, замена git тоже не является чем-то из ряда вон фантастическим, потому что конверсия или прозрачное проксирование (как у NetBSD) вполне возможны, как и возможно построение новых инструментов на базе git, радикально от него отличающихся (как вышеупомянутый jj).

Возможно что угодно, вопрос в количестве страданий в процессе перехода (полный переход индустрии с SVN занял порядка 5-10 лет) и выгоде после. Люди станут писать программы в 5 раз быстрее, если мы перейдем на jj? Если нет, то этот переход не имеет никакого смысла.

медленный, неудобный и вообще мёртвый меркуриал

Спорное утверждение. Но если бы они решили на git перейти, то у них бы точно не осталось времени

ОС разрабатывать

А является ли git этим «good enough»

git при всех своих плюсах - огромный разросшийся монстр.
Оно уже давно переросло фазу «good enough»

Вот все команды которые нужны 99% разработчикам:

git init
git add
git commit -am 'commit'
git switch branch
git rebase main
git pull
git push
git merge

Вот все команды которые нужны 99% разработчикам:

Отлично. Как собрать гит без лишнего 1%?)

А что именно тебя тревожит? Что там есть неиспользуемые функции? Почему это тебя тревожит?

А есть аргументы против? Все workflow уже готовы, на любой вкус. Документация написана. Любой джун постигает необходимые команды для работы за два дня при правильном обучении. Есть что-то, что лучше делает какую-то особую часть, которую Git делает хуже? Да. Есть что-то, что делает весь процесс разработки лучше, чем Git? Нет.

Всё то же писали про Subversion почти 20 лет назад.

Возможно что угодно, вопрос в количестве страданий в процессе перехода (полный переход индустрии с SVN занял порядка 5-10 лет) и выгоде после.

Полный переход индустрии не релевантен вообще. Переход одного проекта занимает примерно три дня и бутылку вина, при наличие остального тулинга. Я вчера вечером ради эксперимента сконвертировал репозитарий GHC из git и hg и это сработало на удивление быстро и беспроблемно, и дальше я мог бы просто пользоваться hg, если бы захотел.

Единственная причина использовать git для меня – общая убогость source forge под другие системы. Единственная относительно адекватная штука для hg, что я знаю, это srht. Аналога Gitea/Forgejo просто нет, что впрочем не мешает использовать hg локально и пушить им в гит на сервере.

Люди станут писать программы в 5 раз быстрее, если мы перейдем на jj? Если нет, то этот переход не имеет никакого смысла.

Переход на jj не требуется, это надстройка над git. Ты можешь работать с тем же репозитарием, просто он делает это удобнее.

Всё то же писали про Subversion почти 20 лет назад.

Ну это не ответ. SVN был принципиально другой системой не позволявшей распределенную разработку и вызывавшей много страданий с ветками. JJ это streamlined Git. И кажется что достаточно просто улучшить UX Git в тех местах, где это имеет смысл.

Полный переход индустрии не релевантен вообще. Переход одного проекта занимает примерно три дня и бутылку вина, при наличие остального тулинга. Я вчера вечером ради эксперимента сконвертировал репозитарий GHC из git и hg и это сработало на удивление быстро и беспроблемно, и дальше я мог бы просто пользоваться hg, если бы захотел.

Что там каждый делает у себя на чердаке – его личное дело. hikari, композитор Wayland от FreeBSD, разрабатывается в HG. Это сразу накладывает косты на любое взаимодействие с новыми участниками, примерно как прием патчей через рассылку вместо PR в GitHub. А пользы никакой. То есть сделать-то можно, но это буквально бессмысленное усложнение ради того чтобы побыть не таким, как все.

Переход на jj не требуется, это надстройка над git. Ты можешь работать с тем же репозитарием, просто он делает это удобнее.

Тогда и смысла переходить на него нет, достаточно утащить удобные вещи в Git.

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

Ну, то есть, если бы в Subversion починили ветки, он бы не сдох? Сомневаюсь.

hikari, композитор Wayland от FreeBSD, разрабатывается в HG. Это сразу накладывает косты на любое взаимодействие с новыми участниками, примерно как прием патчей через рассылку вместо PR в GitHub. А пользы никакой

Может, они просто не хотят твой код :)

Я вот не принимаю PR и вообще выключил их. Многие проекты так делают, даже весьма популярные типа того же sqlite.

JJ это streamlined Git. И кажется что достаточно просто улучшить UX Git в тех местах, где это имеет смысл.

Здесь есть два нюанса:

1. Сценарии использования JJ сильно расходятся с git в некоторых аспектах.
2. Авторы git могут быть категорически против такого улучшения ux git, просто потому что.

Тогда и смысла переходить на него нет, достаточно утащить удобные вещи в Git.

И из-за этого всего процесс утаскивания может быть сложнее, чем просто забить болт и перейти на jj.

С другой стороны, что такое вообще git? Это интерфейс и формат репозитария. Если новые тулзы типа got или jj, работающие с тем же форматом, станут популярнее самого git, это всё ещё будет git или нет? Или, если Microsoft провернёт классический EEE над git и «расширит» формат репозитария штуками, совместимыми лишь с их тулингом, будет ли это git или уже нет? Напомню, MS владеет самым крупным хостингом Git и вполне может вот такое вот провернуть, вообще как нехрен.

Ну, то есть, если бы в Subversion починили ветки, он бы не сдох? Сомневаюсь.

Ты забыл про бульон.

Может, они просто не хотят твой код :)

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

Я вот не принимаю PR и вообще выключил их. Многие проекты так делают, даже весьма популярные типа того же sqlite.

У них тоже забор:

Suggested changes or bug fixes can be submitted by creating a patch against the current source tree. Email patches to drh@sqlite.org. Be sure to describe in detail what the patch does and which version of System.

Но sqlite появился за семь лет до Git. Они едут по инерции, им нормально.

И из-за этого всего процесс утаскивания может быть сложнее, чем просто забить болт и перейти на jj.

Опять же, код на GitHub? На GitHub. Инструкции для Git? Для Git. Если людям удобно, они могут хоть руками hexedit’ом править файлы, но процессы будут выстроены вокруг Git.

С другой стороны, что такое вообще git? Это интерфейс и формат репозитария. Если новые тулзы типа got или jj, работающие с тем же форматом, станут популярнее самого git, это всё ещё будет git или нет?

Если они станут популярнее, значит Git уже не нужен и JJ плавно стал молодцом. Тогда проблемы нет.

Отказаться от Ртути. В ней нет смысла.

Архитектурно Mercurial лучше, чем Git. Другое дело, что с проблемами столкнуться только огромные репозитории на десятки MLoC (я слышал, Яндекс тоже пробовал использовать Mercurial, но в результате написал свою VCS)... Другое дело, что завязка на Python 2 все сильно испортила. :(

Скажи, ЛОР, что ты думаешь по этому поводу? Может ли подобный подход работать в других проектах? Или стоит уже наконец отказаться от git и перейти на Mercurial?

Ну, Mozilla когда уходила с cvs примерно так сделала (перешли со своих надстроек для cvs, типа bonsai на Mercurial), только в обратном порядке: git-зеркало появилось сильно позже.

Но sqlite появился за семь лет до Git. Они едут по инерции, им нормально.

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

Опять же, код на GitHub? На GitHub. Инструкции для Git? Для Git. Если людям удобно, они могут хоть руками hexedit’ом править файлы, но процессы будут выстроены вокруг Git.

Я не про файлы, я про отрыв формата хранения репозитария от UX. Git как формат хранения с нами скорее всего надолго. Git как набор команд в консоли – не факт.

Если они станут популярнее, значит Git уже не нужен и JJ плавно стал молодцом

Тут ещё есть такой нюанс, что реально очень многие консольный git не используют в принципе. Возможно, они уже популярнее.

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

Ну и бог с ними.

Я не про файлы, я про отрыв формата хранения репозитария от UX. Git как формат хранения с нами скорее всего надолго. Git как набор команд в консоли – не факт.

А ваще пофиг на набор команд. Важно чтобы разработчики коммиты писали одинаковые, понимали что куда мержить (или ребейзить), какие типы бранчей существуют и куда можно force push, а куда нельзя. Делается ли это через команду в консоли или vscode вообще не важно.

Ну и бог с ними.

Так и есть! :D

Важно чтобы разработчики коммиты писали одинаковые, понимали что куда мержить (или ребейзить), какие типы бранчей существуют и куда можно force push, а куда нельзя. Делается ли это через команду в консоли или vscode вообще не важно.

По твоему выходит, что тут вообще насрать git это или hg, потому что коммиты выходят примерно одинаковые. Т.е. если обобщить твои слова, то победил не git, а этакий абстрактный флоу, подходящий для большинства DVCS. Просто git стал наиболее популярным форматом.

По твоему выходит, что тут вообще насрать git это или hg, потому что коммиты выходят примерно одинаковые. Т.е. если обобщить твои слова, то победил не git, а этакий абстрактный флоу, подходящий для большинства DVCS. Просто git стал наиболее популярным форматом.

Нет, это не так. Дьявол в деталях и люди должны общими терминами пользоваться. Банальное: git describe по умолчанию учитывает только annotated теги и это пару раз ломало генерацию билдов, когда люди руками их делали вместо скрипта, которым надо было. JJ умудрился даже это сломать, например, и назвать commit change’м. С тегами вероятно тоже все непросто. И вот это постоянно будет создавать неопределенность на пустом месте.