Mercurial: 20 лет в тени Git. Почему легендарная DVCS всё еще жива и как она меняет индустрию сегодня

Введение: Апрель 2005-го и великая гонка систем контроля версий

В мире IT редко случаются моменты, когда одна неделя определяет развитие индустрии на десятилетия вперед. Апрель 2005 года был именно таким временем. После того как компания BitMover отозвала лицензию на бесплатное использование BitKeeper для разработчиков ядра Linux, возник вакуум. Линус Торвальдс начал работу над Git, а Мэтт Маккаллох (Matt Mackall) представил Mercurial (hg).

Сегодня, спустя 20 лет, принято считать, что Git победил окончательно и бесповоротно. Однако на конференции FOSDEM 2025/2026 сообщество Mercurial доказало обратное: система не просто «жива», она эволюционирует, внедряет Rust и управляет репозиториями такого масштаба, перед которыми пасует стандартный Git. В этой статье мы разберем, как Mercurial удалось сохранить актуальность, в чем его архитектурное превосходство и почему крупнейшие технологические гиганты до сих пор вкладывают миллионы в его развитие.

Архитектурная философия: Почему hg — это не «просто другой Git»

Главное различие между Git и Mercurial кроется в фундаментальном подходе к данным. Если Git рассматривает историю как набор снимков (snapshots) и граф объектов, то Mercurial изначально строился вокруг концепции Revlogs (журналов ревизий).

Revlogs и эффективность хранения

Revlog — это структура данных, которая эффективно хранит дельты (различия) между версиями файлов. В отличие от Git, который периодически выполняет ресурсоемкую операцию git gc для перепаковки объектов, Mercurial делает это «на лету». Это обеспечивает предсказуемую производительность даже при очень длинной истории правок.

Индексация и манифесты

Mercurial использует три ключевых типа файлов:

• Changelog: хранит метаданные о коммитах (автор, дата, описание).
• Manifest: список всех файлов в конкретной ревизии.
• Data files (.d): непосредственно содержимое файлов в виде дельта-цепочек.

Такая структура позволяет выполнять операции типа hg annotate (аналог git blame) значительно быстрее на больших объемах данных, так как системе не нужно восстанавливать состояние всего дерева для каждой исторической точки.

Ключевые особенности, которые Git «подсмотрел» или проигнорировал

Многие современные фичи Git, которые мы воспринимаем как должное, либо появились в Mercurial раньше, либо реализованы в нем более элегантно.

1. Расширение Evolve: Безопасная мутация истории

Одна из главных претензий к Git — легкость, с которой можно «выстрелить себе в ногу» при использовании rebase или amend в публичных ветках. Расширение Evolve для Mercurial решает эту проблему концептуально. Оно вводит понятие «устаревших» (obsolete) ревизий. Когда вы меняете историю, старые коммиты не исчезают бесследно, а помечаются как скрытые, сохраняя связь с новыми версиями. Это позволяет безопасно обмениваться изменениями в процессе их редактирования.

2. Named Branches vs Bookmarks

В Git ветка — это просто указатель на коммит. В Mercurial существует понятие Named Branches (именованные ветки). Имя ветки записывается прямо в метаданные коммита навсегда. Это создает идеальную прослеживаемость: спустя 10 лет вы точно будете знать, в рамках какой ветки был сделан этот конкретный фикс, даже если ветка была слита и удалена.

# Пример создания именованной ветки в Mercurial
hg branch feature-auth
hg commit -m "Добавлена аутентификация"
# Имя ветки 'feature-auth' теперь часть истории навсегда

Почему гиганты выбирают Mercurial?

Несмотря на доминирование GitHub, такие компании как Meta (Facebook), Google и Mozilla годами использовали Mercurial как основу для своих монорепозиториев. Почему?

Масштабируемость и Monorepos

Когда размер репозитория исчисляется терабайтами, а количество файлов — миллионами, стандартный Git начинает тормозить. Mercurial оказался более гибким для кастомизации под сверхбольшие нагрузки.

• Meta: Создали на базе Mercurial систему EdenFS и расширение Mononoke. В итоге это эволюционировало в проект Sapling — новую систему контроля версий, которая сохраняет совместимость с логикой Mercurial, но работает еще быстрее.
• Mozilla: Весь код Firefox живет в Mercurial. Для них критически важна стабильность CLI и возможность писать сложные расширения на Python, которые глубоко интегрируются в процесс разработки.
• Google: Долгое время использовал Mercurial для части своих внутренних проектов, ценя его за строгую структуру данных.

Современное состояние: Rust и Heptapod

Последние годы в экосистеме Mercurial ознаменовались двумя важнейшими трендами: переходом на Rust и появлением полноценной платформы для совместной работы.

Проект Rhg: Mercurial на стероидах

Разработчики активно переписывают ядро Mercurial на Rust. Проект Rhg (Rust Mercurial) нацелен на то, чтобы убрать накладные расходы интерпретатора Python в критических путях выполнения. Это дает прирост скорости в 10–50 раз на таких операциях, как hg status или hg diff в огромных репозиториях.

Heptapod: Ответ GitLab

Главной проблемой Mercurial всегда было отсутствие своего «GitHub». Bitbucket отказался от поддержки hg в 2020 году, что стало сильным ударом. Однако проект Heptapod (форк GitLab с поддержкой Mercurial) спас ситуацию. Сегодня это основной дом для Open Source проектов, использующих hg, включая PyPy и саму кодовую базу Mercurial.

Сравнение: Mercurial vs Git в 2025 году

Заключение: Есть ли смысл учить Mercurial сегодня?

Если вы работаете в стандартном веб-продакшене, Git останется вашим основным инструментом. Однако изучение Mercurial полезно по трем причинам:

1. Расширение кругозора: Вы поймете, что многие «проблемы» Git — это не норма, а следствие его архитектуры.
2. Работа в BigTech: Если вы метите в Meta или компании с огромными монорепозиториями, знание концепций hg/Sapling будет огромным плюсом.
3. Инструментарий: Такие фичи, как hg absorb (автоматическое распределение правок по коммитам), настолько удобны, что вы начнете искать их аналоги в Git (и найдете только в виде сторонних скриптов).

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