Fossil SCM 2.28

Для SVN?

Археологическая?

То есть оно ещё и с git несовместимо? Просто эталонное ненужно - эра экспериментов и конкуренции VCS уже лет 10 как закончилась. Несмотря на все его недостатки и кривизну git оказался приемлемого для большинства случаев качества.

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

Да, есть утята, которым подавай гит - для них делают разные гейты. В том же fossil есть «fossil export git» и «fossil import --git --incremental».

Мне вообще странно, что кто-то поднимает этот вопрос — в прикладной разработке вопрос CI/CD, тестирования и ревью намного более важен, чем «какой командой комитить утверждённый код».

Для крупных проектов Git

Проектов размера AOSP на всю планету не факт что сотня наберётся. А уж среди открытых он вообще такой один.

там чекаут сложнее, чем сборка

Это тебя тривиальный питоновский враппер так испугал? Мда, портрет пользователя fossil вырисовывается.

Мне вообще странно, что кто-то поднимает этот вопрос

Это потому что ты никогда не работал с достаточно большими командами разработки. Единственно правильный ответ это «привычной» - потому что несмотря не весь прогресс в ИИ время разраба это по-прежнему слишком ценный ресурс чтобы тратить его на возню с непривычной VCS.

Благо как раз благодаря повсеместному распространению git можно без проблем выкинуть porcelain часть и заменить на что-то приличное вроде magit совершенно прозрачно для коллег благодаря общему plumbing. Вот это разделение на уровни - единственное что не вызывает отвращения в архитектуре git.

Это тебя тривиальный питоновский враппер так испугал? Мда, портрет пользователя fossil вырисовывается.

Конечно же я утрирую. Сборка там сложная, но чекаут всё равно не тривиальный. Если ты всё ещё считаешь, что «всё просто», то предлагаю подумать над следующими вещами:
— чекаут всех реп с полной историей чудовищно долгий, а на быстром соединении тебя скорее всего просто блоканут;
— окей, делаем --depth=1;
— упс, теперь мы не можем сделать blame и слияния. Чтобы раскукожить репу, нужно отдельно делать git fetch --unshallow для интересующих реп;
— а апдейт дерева на новую версию/ветку в shallow clone мы делать всё равно не можем, потому по итогу делаем по мануалу «repo init -u https://android.googlesource.com/mirror/manifest --mirror», чтобы скачать все ветки через пару дней.

М-м-м, удобство.

Единственно правильный ответ это «привычной» - потому что несмотря не весь прогресс в ИИ время разраба это по-прежнему слишком ценный ресурс чтобы тратить его на возню с непривычной VCS.

М-м-м, ценитель времени разраба и любитель Git в одном флаконе — это что-то интересное. А тебе не приходило в голову, что Git без IDE (а то есть решение любой проблемы кривого состояния репозитория) — это одна из самых сложных в освоении VCS, то есть, на неё нужно потратить время — или оно не считается, разрабы из институтов поставляются со знанием всех ключей гита наизусть? Жонглировать чери-пиками и стешами, чтобы история правок не была похожа на персидский ковёр — это у нас экономия времени разработчика, я правильно понел? Или же у вас ковры в истории?

Благо как раз благодаря повсеместному распространению git можно без проблем выкинуть porcelain часть и заменить на что-то приличное вроде magit совершенно прозрачно для коллег благодаря общему plumbing.

Мне ещё и емакс нужно изучать, или как? Я как бы не спорю с тем, что Git без IDE малоюзабелен, но тут как бы можно задать вопрос: а при чём тут Git вообще? Может быть стоит выкинуть Git, а IDE оставить?

Вот это разделение на уровни - единственное что не вызывает отвращения в архитектуре git.

Толстые слои в=совместимости с кусками дерьма 20-летней давности ты называешь «разделение на уровни»? Интересное определение. Ты не задумывался, что эти «уровни» сами по себе никакой прикладной задачи не решают, они там просто как третья нога?

окей, делаем –depth=1

Там и другие числа подставить можно ;)

одна из самых сложных в освоении VCS, то есть, на неё нужно потратить время

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

со знанием всех ключей гита наизусть

Ты уверен что обессмысливание через утрирование поможет тебе донести мысль? Тебе серьёзно кажется что так убедительнее?

Мне ещё и емакс нужно изучать, или как?

Само собой! Этот шедевр софтостроения нужно вообще всем изучить ;) But I digress как говорят на языке основной массы разработчиков git :)

Может быть стоит выкинуть Git, а IDE оставить?

Как ты себе представляяешь реализацию этой идеи на практике?

с кусками дерьма 20-летней давности ты называешь «разделение на уровни»?

Разделением на уровни я называю именно то что описал в комменте, на который ты отвечаешь - разделение на plumbing и porcelain авторами git, которое там с первых версий практически.

эти «уровни» сами по себе никакой прикладной задачи не решают

Разумеется решают. Именно благодаря этому разделению я могу работать в комфортном интерфейсе magit вообще не парясь какие там у git ключи и что там в plumbing происходит. И я практически уверен что даже переезд на SHA256 будет максимально незаметным - как раз благодаря этому разделению.

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

Дык я как бы и не спорю. Честно говоря, я в явной форме об этом не задумывался, но как бы все факты указывали на это. Зачем MS сделал VFS for Git? Это ведь уже совсем не Git, там от гита один интерфейс. А вот потому — каждый студент знает Git.

Ты уверен что обессмысливание через утрирование поможет тебе донести мысль? Тебе серьёзно кажется что так убедительнее?

По-моему ты прекрасно понял мысль. Единственное оставшаяся непонятка — это двоякое толкование предмета обсуждения и постановки целей.

Взять пример Роба Пайка. Он топил за «давайте развивать ОС» — но потом встретился с реальностью гугла «у нас все админы пол жизни сидели только за Linux — как ты представляешь себе внедрение новой ОС»? Когда ты не умеешь в Linux/Git — это барьер. Когда ты потратил кучу времени на изучение Linux/Git — тот же самый барьер играет в твою пользу, потому что делает тебя ценным, как платного специалиста по «этой штуке».

Почему гугл сделал андроид таким чудовищно гигантским? Потому что разработку андроида совершенно точно не сможет перехватить компания меньше гугла. Отменяет ли эта цель искуственную переусложнённость? Нет. Если ты не гугл и тебе не нужно запускать приложения из Google Play, то тебе может быть не нужен андроид.

Git сложен, неудобен, и все умеют с этими проблемами справляться. Значит ли это, что нельзя использовать систему версионирования, отличную от Git? LOL, нет, но всё зависит от ситуации.

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

С Repo получается замечательный контрпример: опенсорсный проект, и вроде почти гит... но не гит. Оказывается, нужно изучать прокладку поверх гита, нужно изучать Gerrit — а ведь сообщество знает GitHub, на с Gerrit и Repo намного меньше людей знакомо.

И теперь скажи мне: какая разница между использованием Repo+Git или использованием Repo посторенного бесшовно на базе Mercurial? Ничего мержить-ребейзить в рамках макрорепозитория в Repo ты всё равно не можешь. Я ещё раз повторюсь, что я понимаю социальную составляющую сего феномена, но никакой технической составляющей там нет, использование гита больше похоже на постановку свечей в храме — потому что так принято.

А вот если проекту нельзя использовать Git по техническим причинам, но он использует гит «потому что все пользуются» — это принесет вполне себе реальные проблемы, которые могут на порядки перевешивать тот сэкономленный день, который вы не потратили на изучении более подходящей VCS.

Само собой! Этот шедевр софтостроения нужно вообще всем изучить ;) But I digress как говорят на языке основной массы разработчиков git :)

Статистика говорит об обратном — Emacs планомерно закапывают в могилу. И по социальным, и по техническим причинам.

Может быть стоит выкинуть Git, а IDE оставить?

Как ты себе представляяешь реализацию этой идеи на практике?

Смотря какую практику мы имеем в виду. Разработка кода — это не одна VCS, а целая инфраструктура. Если у вас GitHub, то вы ставите расиширения Github для VS Code, и тогда неявно оказываетесь приколоченными гвоздями к Git — не потому, что гит такой классный, а потому, что ваш проект на GitHub. Для GitLab примерно та же история. Если же у вас не GitHub и не GitLab? Зачем вам тогда Git вообще?

Разделением на уровни я называю именно то что описал в комменте, на который ты отвечаешь - разделение на plumbing и porcelain авторами git, которое там с первых версий практически.

Куда-то делось моё сообщение про исконную архитектуру Git, потому придётся в двух словах пояснить с нуля.

Не было никакой VCS, было пару сишных утилит для работы с деревьями исходников, и кучка башескриптов поверх них для автоматизации высокоуровневых задач. Всё это нужно было ровно одному человеку для того, чтобы сделать более интенсивными свои страдания по слиянию правок из разных веток ядра. Разваливалось это дело довольно регулярно, аля «растущая из пустоты ветка». Торвальдс не просто так называл его «stupid content tracker» — оно было реально капец какое тупое. Это и было «plumbing». Никакого «porcelain» там не было и никакого релиза для внешней публики эта штука не подразумевала...

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

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

Именно благодаря этому разделению я могу работать в комфортном интерфейсе magit вообще не парясь какие там у git ключи и что там в plumbing происходит.

Ладно, не буду больше задавать вопросов, давать намёки и иносказания: в норм VCS есть нстоящие API, будь то сишное API у SVN или же XML/JSON входы-выходы у Mercurial. Не парсинг текста случайно выбранного формата, а чётко сформулированные точки взаимодействия с системой. Зачем же разрабатывается https://github.com/libgit2/libgit2 , если есть такой замечательный Plumbing API? Да потому что он никогда не разрабатывался как API, со всеми вытекающими. Да и зачем второй-третий раз писать «на этот раз комфортный» пользовательский интерфейс, если можно сразу сделать хороший?... Ну вот, я опять говорю вопросами, а ведь обещал...

— zabbal, я вот тут мучаюсь со своим репозиторием; подскажи, как проблему исправить.
— Ну это просто: потрать два месяца на изучение Emacs, потом ещё несколько дней попользуйся Magit — и тогда я тебе покажу, как за двадцать секунд исправить твою проблему.

И как выложить репу для read-only клонирования аноном?

Через любой HTTP сервер захости, как статику. После изменений надо дёргать git update-server-info, это в принципе всё, что нужно. Вроде через post-update хук.

GitHub эдак 2012 года был почти один в один Fossil. Если ты хочешь узнать, как выглядел GitHub - открой веб интерфейс Fossil.

Я не про это. GitHub это прежде всего сообщество. А какой там веб интерфейс - вообще плевать.

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

Меркуриал был убит питоном. Облачный меркуриал получался слишком дорогим в плане CPU+RAM.

В Git цепочки подписей коммитов тоже перманентны — просто они не называются ветками,

Не понимаю как подписи (signature) коммитов в git связаны с ветками.

В терминологии fossil: https://fossil-scm.org/home/doc/trunk/www/branching.wiki

Branch
A branch is a set of check-ins with the same value for their "branch" property.
<...>
Single DAG
Fossil keeps all check-ins on a single DAG. Branches are identified with tags. This means that check-ins can be freely moved between branches simply by altering their tags.
<...>
The initial check-in of every repository has two propagating tags.
<...>
The branch tag tells (by its value) what branch the check-in is a member of. 

В терминологии mercurial: https://wiki.mercurial-scm.org/Branch#A_Changeset_attribute

Mercurial branch name is an attribute associated with a changeset.
<...>
Although there is no "diverging development line" above, the Mercurial branch name can be changed.

Another case is that if a "diverging development line" occurs later, both diverged lines will inherit the parent's branch name if no new branch name is started.  

Реализация и поведение весьма близки.

Зачем MS сделал VFS for Git?

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

По-моему ты прекрасно понял мысль.

А там была какая-то мысль? Я только неудачную попытку пошутить заметил.

Почему гугл сделал андроид таким чудовищно гигантским?

Потому что проект поддерживающий такое количество фич на таком чудовищно разнообразном железе сделать меньше просто невозможно.

ты хочешь, чтобы участники проекта тебе пушили свои ветки по ssh?

Именно так мы и делали в проектах над которыми я работал. А что конкретно тебя смущает?

нужно изучать Gerrit

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

Ничего мержить-ребейзить в рамках макрорепозитория в Repo ты всё равно не можешь.

И как по-твоему идёт разработка андроида без merge-rebase?

Emacs планомерно закапывают в могилу

Его туда 40 лет уже закапывают - он ещё на твоих похоронах простудится :)

никакого релиза для внешней публики эта штука не подразумевала

Что за бред ты несёшь? C самой первой скобки git предназначался к публичному релизу потому что его делали для замены не менее публичного BitKeeper после того как эти недоумки скорчили кривую рожу и запретили использовать его для разработки ядра.

Да потому что он никогда не разрабатывался как API

И? Мне вполне достаточно того что он работает. Делается это через API, JSON или парсинг выхлопа команды - исключительно вопрос удобства разработчиков интерфейса, которым я пользуюсь.

подскажи, как проблему исправить

Именно так. Тебя что-то конкретно удивляет? Или ты просто не привык к тому что окружающие не бросаются по первому требованию вытирать тебе сопли?

ну с гитом это тоже можно

Гит отлично работает и без вебни через ssh, вместе с ним идёт и легковесный gitweb (ридонли веб-морда), то есть в принципе основные фишки для небольшого проекта есть.

Но вот так, чтобы с багтрекером, вики, форумом и чатом, да всё ещё в едином формате, нет, этого и близко нет.

Например, как сделать просмотр репозитория через браузер

Тут ты неправ. Есть gitweb же, там всё очень просто

В принципе неистово плюсую, кроме части про емакс+magit. Емакс таки очень полезный и нужный редактор, а магит действительно снимает массу проблем. Согласен с @zabbal что его полезно изучить всем разработчикам.

У меня опыт скромный, я очень долго работал на cvs, потом перешёл сразу на git, с другими системами управления версий не работал. Читая почему не гит, вспоминаю чуть ли не со слезами переход на гит. В этой статье очень верно подмечены проблемы git. Это был весьма болезненный опыт и до сих пор мне непонятна необходимость такой переусложнённости git при ограниченности выхлопа. Твой пост немного приоткрыл мне глаза на причину всего этого. Спасибо за потраченное время.

Хотелось бы добавить, что github ведь не понижает сложность, а добавляет её, хотя и прикрывает её фиговым листочком вебни.

Но надо признать, при всех своих недостатках, git берёт тем что он действительно стал стандартом де-факто.

И как выложить репу для read-only клонирования аноном?

Через любой HTTP сервер захости, как статику. После изменений надо дёргать git update-server-info, это в принципе всё, что нужно. Вроде через post-update хук.

Молодец, ты изобрёл github/gitlab.

Я не про это. GitHub это прежде всего сообщество. А какой там веб интерфейс - вообще плевать.

С 2012 года — да. До 2012 года ~ нет, это был именно Fossil, то есть, удобный веб-интерфейс к VCS. Fossil именно в этом состоянии и остался.

Меркуриал был убит питоном. Облачный меркуриал получался слишком дорогим в плане CPU+RAM.

Расскажи гуглу, который сделал Piper с Mercurial клиентом, о том, как меркуриал убивает их монорепу на 2 млрд строк кода.

На секундочку, гихтаб до сих пор на Руби, и почему-то никого это не волнует.

Если уж на то пошло, то Fossil в плане скорости и низкого потребления ресурсов уделывает с огромным запасом любое решение с бэкендом на Git или Mercurial. Это кого-то волнует? Сервер Fossil работает на роутере со 100 Мб оперативы — мне нужно рассказывать, сколько нужно для запуска гитлаба?

Не понимаю как подписи (signature) коммитов в git связаны с ветками.

Я имею в виду де-факто ветки как граф коммитов. Именно граф коммитов является наибольшей ценностью в wannabe-distributed VCS, ты не можешь прочитать файл, не читая граф его истории — именно потому ветки фундаментальны.

В терминологии mercurial: https://wiki.mercurial-scm.org/Branch#A_Changeset_attribute

У тебя плохой источник, хотя, я соглашусь, что документация по Mercurial так-себе (хуже разве что Git):
https://wiki.mercurial-scm.org/StandardBranching

2.2. Don't treat branch names as disposable
If you're coming from Git, you may be used to the idea that branch names are disposable. Mercurial's model is more traditional: branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced.

В терминологии fossil: https://fossil-scm.org/home/doc/trunk/www/branching.wiki
Fossil keeps all check-ins on a single DAG. Branches are identified with tags. This means that check-ins can be freely moved between branches simply by altering their tags.
Реализация и поведение весьма близки.

Серьёзно различны во всех трёх.

Mercurial единственная, имеющая перманентные ветки в стиле DVCS, то есть, распределённые метаданные не подлежат изменению.

В git вообще ветки строго локальны, то есть, твой собственный master и origin/master — это два совершенно разных ref-а.

Fossil же по духу ближе к кооперативным системам аля Google Docs: она версионирует метаданные.и разрешает пользователям публиковать несколько голов одной и той же ветки — то, что называется «fork» и чему нет аналогов ни в Git, ни в Mercurial. Точнее, git позволяет создавать те же master и origin/master, то есть, одно имя ветки в разных репозиториях, но публикации в одну репу эта штука не подлежит, потому что в Git крайне примитивная система метаданных.

Расскажи гуглу, который сделал Piper с Mercurial клиентом, о том, как меркуриал убивает их монорепу на 2 млрд строк кода.

не-не, думаю тут важен не объём кода, а количество клиентов

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

Чтобы удобно работать с огромными файлами, прежде всего нужно отказаться от git и даже не пытаться его использовать. Он просто не предназначен для этих задач. Но MS сделала VFS for Git именно по описанным мной и тобой причинам — «потому что все знают команды Git».

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

Потому что проект поддерживающий такое количество фич на таком чудовищно разнообразном железе сделать меньше просто невозможно.

Что значит «фич»? Для вывода теста на двухмерный экран нужно 3-4 Гб исходников и 300 Мб бинарей? Ты уверен?

Андроид — это на 95% совместимость с совместимостью. И немножко собственно логики приложений.

Именно так мы и делали в проектах над которыми я работал. А что конкретно тебя смущает?

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

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

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

И как по-твоему идёт разработка андроида без merge-rebase?

С марта 2025 года гугл больше не ведёт разработку в публичных Git репах. После ревью код комитится в закрытую централизованную репу, проходит тестирование, и потом выборочно публикуется обратно в Git. До марта 2025 это был вспомогательный механизм, теперь он стал единственным.

C самой первой скобки git предназначался к публичному релизу потому что его делали для замены не менее публичного BitKeeper после того как эти недоумки скорчили кривую рожу и запретили использовать его для разработки ядра.

Чисто формально оно было опенсорс, но вот проблема — оно не было VCS/SCM, со слов самого же Торвальдса:
https://lkml.org/lkml/2005/4/8/9

The database is designed so that you can do the equivalent of a nonmerging (ie pure superset) push/pull with just plain rsync, so replication really should be that easy (if somewhat bandwidth-intensive due to the whole-file format).
Never mind merging. It’s not an SCM, it’s a distribution and archival mechanism. I bet you could make a reasonable SCM on top of it, though. Another way of looking at it is to say that it’s really a content-addressable filesystem, used to track directory trees."

И во-вторых, ещё раз повторюсь, что оно не предназначалось для использования никем, кроме самого Торвальдса:
https://github.blog/open-source/git/git-turns-20-a-qa-with-linus-torvalds/

So I was like, okay, I’ll do something that works for me, and I won’t care about anybody else. And really that showed in the first few months and years—people were complaining that it was kind of hard to use, not intuitive enough.

То есть, по сути это было «ребята, допилите мне инструмент, чтобы я им пилил ядро», а не «я подарил миру систему управления версиями» — именно это я имел в виду, когда писал «не предназначалься для публичного релиза». Если ты всё ещё готов цепляться к словам, то я предлагаю сразу ответить: чем отличаются «публичный релиз программы» и «открытие исходных кодов без прикладного применения»?

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

Это вопрос производительности, атомарности-корректности многошаговых операций, и обработки ошибок. Тут выше кто-то рискнул упомянуть про медлительность Mercurial, но Git не так давно в ряде операций был совершеннейшей черепахой, потому что команды Porcelain были баш скриптами, запускавшими тысячи подпроцессов Git — это было чудовищно медленно. Ну и когда «разработчикам интерфейсов» приходится пробираться через сплошное поле граблей, то рано или поздно что-то прилетит в лицо лично тебе. По моему опыту обработка проблемных ситуаций/ошибок в git омерзительная.

Ну это просто: потрать два месяца на изучение Emacs, потом ещё несколько дней попользуйся Magit — и тогда я тебе покажу, как за двадцать секунд исправить твою проблему.

Именно так. Тебя что-то конкретно удивляет? Или ты просто не привык к тому что окружающие не бросаются по первому требованию вытирать тебе сопли?

Что и требовалось доказать. Емакс изучить — это плёвая ерунда, а освоить CLI какого-нибудь Mercurial — это неподъемная сложность

Емакс таки очень полезный и нужный редактор, а магит действительно снимает массу проблем. Согласен с @zabbal что его полезно изучить всем разработчикам.

Зачем, если есть VS Code с гитом из коробки? Собственно, я помню, как как редактировал код в другом редакторе, а VS Code использовал только для формирования комитов, аля «GitHub client app».

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

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

The «Resume-Driven Development» Factor
Developers and architects often choose technologies that maximize their future employability, not necessarily what minimizes current operational overhead.
• Learning Fossil makes you an expert in Fossil.
• Learning Git + GitHub Actions + Complex CI/CD makes you a «DevOps Engineer.»
• Learning Vanilla K8s with 50 microservices looks more impressive on a resume than «I run everything on a single K3s node.»
• Result: Teams choose the «fat» stack because it signals competence to the market, even if it's over-engineered for the problem.

Фактор «мам, смотри что я умею» является доминирующим в айти эдак последние 70 лет.

Хотелось бы добавить, что github ведь не понижает сложность, а добавляет её, хотя и прикрывает её фиговым листочком вебни.

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

Расскажи гуглу, который сделал Piper с Mercurial клиентом, о том, как меркуриал убивает их монорепу на 2 млрд строк кода.

Ни в гугле, ни в ФБ ванильный меркуриал не был на стороне главной репы. В гугле меркуриал служил интерфейсом к Piper, в ФБ были сильно перепилены и клиент, и сервер. Тот же питон оказался так удобен для перепиливания и впиливания экстеншенов, что сами разработчики надорвались, сначала переписывая все со второго питона на третий, и потом с третьего питона на раст.

На секундочку, гихтаб до сих пор на Руби, и почему-то никого это не волнует.

Волнует. Много раз в неделю вижу 429 от гитхаба.

Если уж на то пошло, то Fossil в плане скорости и низкого потребления ресурсов уделывает

Вот и славно.

Ни в гугле, ни в ФБ ванильный меркуриал не был на стороне главной репы. В гугле меркуриал служил интерфейсом к Piper, в ФБ были сильно перепилены и клиент, и сервер.

На самом деле ни гуглу, ни ФБ не нужны были ни Git, ни Hg. В IT гигантах тоже принимают плохие решения. Особенно в айти гигантах принимают плохие решения. Ну никто не будет говорить, что гугл выбрал Python для маш обуча потому, что питон так быстро считает числа.

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

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

30% репы Mercurial составляют C/C++/Rust так-то, потому не совсем корректно и даже совсем некорректно говорить, что это прямо-таки питон всё там делает.

Вот с чем я соглашусь полностью — так это с тем, что деплой в питоне как был, так и остаётся полнейшим трешем. Они в 2022 году добавили в pip анализ зависимостей без установки пакетов. 2022 год, карл. До 2022 года ты должен был выкачать пакет, посмотреть что это не он, выкачать другой, и так далее — вот такой вот анализ зависимостей был в pip. Если бы с Hg можно было деплоить соответствующую версию питона, то проблемы бы не было в принципе. Вот мой https://github.com/byko3y/python-shared-objects вполне возможно уже и не собирается на новых питонах.

Тут выше кто-то рискнул упомянуть про медлительность Mercurial

А чего бы не рискнуть с вот такими цифрами на руках:

$ hyperfine "git --version"                         
Benchmark 1: git --version                                                    
  Time (mean ± σ):      26.4 ms ±   2.7 ms    [User: 9.9 ms, System: 14.8 ms] 
  Range (min … max):    22.6 ms …  38.0 ms    84 runs                         
                                                                              
$ hyperfine "hg --version"                          
Benchmark 1: hg --version                                                     
  Time (mean ± σ):      75.2 ms ±   2.0 ms    [User: 47.5 ms, System: 26.1 ms]
  Range (min … max):    71.5 ms …  80.6 ms    35 runs                         

30% репы Mercurial составляют C/C++/Rust

Про раст ничего говорить не буду. С и С++ там видимо chg и hgwatchman. Это конечно не костыли, но все же костыли.

А чего бы не рискнуть с вот такими цифрами на руках:
$ hyperfine «git --version»

Ты серьёзно? Меряешь скорость выдачи номера версии программы? Не хочешь замерить скорость чекаута однобайтовых репозиториев?

Я подразумеваю не столько детали внутренней реализации, сколько то, как это выглядит для пользователя VCS.
Перманентность ветки в смысле однозначного способа определения принадлежности коммита к определенной ветке.
Как этот описано в доке меркуриал: «branch names are a permanent part of each commit and allow identifying on which branch each commit was introduced.»
И fossil: «Branches are identified with tags».

Fossil же по духу ближе к кооперативным системам аля Google Docs: она версионирует метаданные.и разрешает пользователям публиковать несколько голов одной и той же ветки — то, что называется «fork» и чему нет аналогов ни в Git, ни в Mercurial.

В mercurial ведь тоже можно запушить ветку с несколькими head в публичный репозиторий (с ключом --force), как я понимаю.
Но вообще это странный сценарий, который должен решаться через приватные ветки.

Кто-то из местных истользует fossil? Какие истории узбека есть?

Я пользовал некоторое время в качестве локальной системы контроля версий. Удобно в плане того, что всё носится с собой в виде одного файла, включая веб-интерфейс с вики и всякими трекерами.

Синкать его на удалённые машины не пробовал, т.к. не понял, как оно настраивается.

Потом отказался в пользу обычного гита на вдс.

Можно. У меня так Gitea работает и переносится куда надо.

Только есть нюанс: это контейнер, требуется докер и прочее. Фоссил в этом плане удобнее → это один единственный бинарь, который ты можешь запустить где угодно и сразу получить всё нужное.

LOL! Интересно что имеется в виду под «распределённостью»? Как и куда он собрался единственный бинарь распределять?

Ты бы подтянул матчасть :)

Зачем, если есть VS Code с гитом из коробки?

С учётом того что emacs появился задолго до VS Code, то правильно вопрос ставится ровно наоборот. Зачем нужен VS Code, если есть emacs с magit? Magit вполне интегрирован в emacs, единственное, его надо ставить дополнительно.

Сложность нужно повышать в любом случае, потому что разработка софта — это не только репозиторий.

Нет, я имею в виду именно работу с репозиторием. pull-request это же фишка github и на «чистом» git это никто не использует. Git предоставляет для этого возможности, а реализация уже внешняя.

Требуется докер в контексте линуксовых серверов, это в современном мире как «требуется уметь читать и писать» в описании вакансии. Наверное в XIX так и делали, но сейчас это просто подразумевается по умолчанию.

по итогу гугл всё-таки ушел на собственную систему контроля версий

Какую?

Для вывода теста

С этим на кухню - может хоть в готовке ты разбираешься лучше чем в технологиях.

секта свидетелей форспуша

Ты хоть что-то про git читал вообще? Как push –force связан с транспортом ssh? Это ортогональные вещи.

нормальный VCS, в котором уже есть всё, мы осилить не можем

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

После ревью код комитится в закрытую централизованную репу

Ты опять путаешь жопу с пальцем - закрытость репы вообще никак не связана с процессом разработки, которые по прежнему использует merge или rebase.

I bet you could make a reasonable SCM on top of it

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

атомарности-корректности многошаговых операций

За это отвечает как раз plumbing - ты опять путаешь архитектурные уровни.

Емакс изучить — это плёвая ерунда

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

Mercurial — это неподъемная сложность

А это как раз тривиально, но совершенно бессмысленно: это малораспространённый устаревший инструмент, все гипотетические преимущества над git которого полностью нивелируются доработками на уровне porcelain в git.

Я подразумеваю не столько детали внутренней реализации, сколько то, как это выглядит для пользователя VCS.

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

И я ещё раз повторюсь, что терминология «ветки-теги-форки» совершенно различна в разных системах, не нужно пытаться приравнивать ветки mercurial к веткам git.

В mercurial ведь тоже можно запушить ветку с несколькими head в публичный репозиторий (с ключом --force), как я понимаю.
Но вообще это странный сценарий, который должен решаться через приватные ветки.

Кому он должен? Тебе не приходило в голову, что конфликт правок — это фундаментально командная проблема, которая и решается командой?

Модель git построена из расчёта на то, что ей будет пользоваться один человек — некий Линус Торвальдс; он будет забирать правки у других людей и сливать их в локальных ветках. Всё, никакого другого воркфлоу не предусмотрено с завода.

С учётом того что emacs появился задолго до VS Code, то правильно вопрос ставится ровно наоборот. Зачем нужен VS Code, если есть emacs с magit? Magit вполне интегрирован в emacs, единственное, его надо ставить дополнительно.

Потому что не все разрабы готовы тратить годы на погружение в емакс. И это в том числе я. Ну вот не интересно мне ковыряться в моём личном собственном IDE, уникальном и не похожем ни на одну другую. Я, наоборот, сегодня сижу в одной IDE, завтра сижу в другой — часто тупо в произвольном текстовом редакторе текст пишу-читаю. Даже через браузер часто читаю историю коммитов.

Если ты изучил Emacs, то ты знаешь только Emacs. Если ты пользуешься VS Code, то тебе нужно изучить три-четыре базовых хоткея (Ctrl+T, Ctrl+P, Ctrl+Shift+P) — всё, ты занимаешься разработкой прикладного кода, а не разработкой своей IDE.

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

Только есть нюанс: это контейнер, требуется докер и прочее. Фоссил в этом плане удобнее → это один единственный бинарь, который ты можешь запустить где угодно и сразу получить всё нужное.

Как правильно написали ниже
Fossil SCM 2.28 (комментарий)
развёртывание одного докер-контейнера — это очень низкий барьер в 2026. Я бы предпочёл сфокусироваться на другом: Fossil и Gitea имеют радикально разные стили организации взаимодействия разработчиков; если Gitea предлагает традиционные полуцентрализованные ветки-форки-пул реквесты, то у Fossil умолчательный режим — это жесткая централизация, и даже в оффлайн режиме ты «клиент, который временно отключен от сети», а не равноправный узел. На самом деле этот последний режим намного более актуален для типичной коммерческой разработки, но почему-то все пытаются играться в DVCS.

И здесь я хочу отдельно подчеркнуть, что «централизованная разработка, допускающая временный уход в оффлайн» относится не только к исходным кодам, но к wiki, баг трекеру. И даже к истории создания-переименования веток это относится — в git вы не можете переименовать публичные ветки в оффлайне, для этого обязательно подключение к центральному репозиторию.

по итогу гугл всё-таки ушел на собственную систему контроля версий

Какую?

Jujutsu. Ну, как «ушел»... Отдельные команды на неё работают, но большая часть всё ещё на Piper, да.

Ты хоть что-то про git читал вообще? Как push –force связан с транспортом ssh? Это ортогональные вещи.

Форспуш не связан с SSH, форспуш является неотъемлимы и фундаментальным изъяном преимуществом Git.

Ты опять путаешь жопу с пальцем - закрытость репы вообще никак не связана с процессом разработки, которые по прежнему использует merge или rebase.

Разработка Android ведётся исключительно в монорепе на Piper. Ты уже ничего не можешь закомитить в git репозитории, это строго read-only зеркала Piper.

Однако это никак не отменяет твоего обсёра с утверждением про непубличность git: то что Линусу было насрать на кривой UX того что он релизит в паблик ни разу не отменяет того что это именно публичный инструмент с первой же минуты предназначенный быть именно публичным.

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

За это отвечает как раз plumbing - ты опять путаешь архитектурные уровни.

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

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

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

Mercurial — это неподъемная сложность

А это как раз тривиально, но совершенно бессмысленно: это малораспространённый устаревший инструмент, все гипотетические преимущества над git которого полностью нивелируются доработками на уровне porcelain в git.

Mercurial сам по себе не устарел, он вполне себе активно поддерживается в 2026. Другое дело, что под него меньше расширений IDE и хостинга аля Bitbucket/Github нету — но это не свойство Mercurial самого по себе.

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

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

Когда же ты пользуешься VS Code, то ты пользуешься готовым стандартизированным каркасом и его фичи будут требовать минимальных знаний-навыков от пользователя. Ты можешь пересесть с VS Code на Cursor, и продолжить точно так же пользоваться ими, не зная ни VS Code, ни Cursor.

Хотя, у тебя есть возможность привести пример какой-то задачи, где Emacs прямо-таки в хлам уделывает продукты для современных школьников.... но я таких не знаю. Справедливости ради, наиболее сильные задачи разработки в каком-то ЯП, вроде сложного рефакторинга, в Emacs делаются через LSP, которые изначально для VS Code разрабатывались. Ну и зачем мне Emacs?

Ну и зачем мне Emacs?

Я не знаю, зачем тебе Emacs. Я могу только сказать, зачем он мне. Здесь есть два основных аспекта. Во-первых я начинал работать программистом в девяностые. Знаешь сколько офигенных IDE и редакторов за это время сменилось? Счёту им нет. Но благодаря тому что я один раз сделал правильный выбор тогда, меня эти бури совершенно не коснулись. Во-вторых, уж если выбирать что-то другое, то точно не от Микрософта или других корпов. Потому что для них испоганить или даже закрыть и похоронить проект - раз плюнуть, потому что их цели вовсе не обязательно полностью совпадают с твоими. И если им что-то будет выгодно, они это безусловно сделают, не сомневаясь ни секунды. Проект не должен зависеть от корпов. Ну и третий аспект, или даже скорее принцип, которому я следую, не надо спешить выкидывать старые проверенные свободные инструменты, которые уважаемы опытным старшим поколением, а следует, наоборот, учиться у них их использованию и развивать их. Преемственность важна в нашем свободном сообществе.

Ты уже ничего не можешь закомитить в git репозитории, это строго read-only зеркала Piper.

https://github.com/web3infra-foundation/mega - отстают от FOSS аналога, забавно.

Ты покупаешь автомобиль. Платишь деньги.

Ты только начал аналогию строить, а она уже порвалась. Какие деньги ты за git заплатил? Кому?

https://github.com/web3infra-foundation/mega - отстают от FOSS аналога, забавно.

Опять бенчмарки вывода версии? Этот мусор использует ноль человек, про него ноль упоминаний на любой айтишной платформе. Прогресс разработки:

MONTH      | LINES ADDED  | LINES REMOVED
2026-03    |     55685    | 12422 
2026-02    |     42425    | 9141  
2026-01    |     24766    | 15206 
2025-12    |     40496    | 6339  
2025-11    |     26056    | 26060 
2025-10    |     12113    | 10188060
2025-09    |     52106    | 15746 
2025-08    |     25805    | 6566  
2025-07    |     283061   | 8387  
2025-06    |     18585    | 108333
2025-05    |     206919   | 12269 
2025-04    |     18980707 | 51432 
2025-03    |     186419   | 8490  
2025-02    |     176166   | 6959  
2025-01    |     19056    | 18643 
2024-12    |     45398    | 4050  
2024-11    |     25546    | 6356  
2024-10    |     28949    | 3590  
2024-09    |     8589     | 4606  
2024-08    |     14478    | 4640  
2024-07    |     20974    | 13061 
2024-06    |     5519     | 2873  
2024-05    |     15513    | 5124  
2024-04    |     5518     | 2624  
2024-03    |     13451    | 9742  
2024-02    |     14171    | 39410 
2024-01    |     9446     | 17111 
2023-12    |     5664     | 2699  
2023-11    |     24678    | 4253  
2023-10    |     1894     | 1159  
2023-09    |     44715    | 1725  
2023-08    |     48465    | 33152 
2023-07    |     72750    | 30327 
2023-06    |     1905     | 699   
2023-05    |     4159     | 539   
2023-03    |     3674     | 766   

--------------------------------------------------------------------------------
Language                      files          blank        comment           code
--------------------------------------------------------------------------------
TypeScript                     1755          20397           7204         138432
Rust                            471           9271           9278          67508
YAML                             17           5110            221          22918
TOML                             24            205            194           5490
Markdown                         46           1034              0           2788
JSON                             38              4              0           1638
CSS                               8            344            178           1591
JavaScript                       20            143            105           1418
Python                            4            248            102           1079
Bourne Shell                     11            202            215            901
SVG                              45              0              0            554
EJS                               5             82              0            513
Dockerfile                        6            120            101            291
DOS Batch                         1             51             36            256
HTML                              1              0              0            182
PowerShell                        1             11              9             79
diff                              1              0             74             68
Bourne Again Shell                1              9              8             19
--------------------------------------------------------------------------------
SUM:                           2455          37231          17725         245725
--------------------------------------------------------------------------------