Mercurial 介绍与选型指南

目标：从零建立对 Mercurial（命令名 hg）的完整认知——它解决什么问题、内部如何组织版本数据、与 Git/Fossil/Darcs 在哪些量化维度上有实质差异，以及什么团队适合选它。本文所有版本号、发布日期、许可证与特性说明均来自官方公开渠道，查询日期 2026-10-28；本文属认知与选型篇，不含本地压测数据。

一、环境信息

本文为选型与认知文档，不涉及部署操作，因此"环境信息"记录的是数据口径，便于读者复核每一条结论：

• 调研对象：Mercurial 分布式版本控制系统（Distributed SCM），命令行程序 hg
• 官方站点：https://www.mercurial-scm.org/
• 官方发布目录：https://www.mercurial-scm.org/release/
• 官方 Release Notes：https://wiki.mercurial-scm.org/ReleaseNotes（7.2 条目：https://wiki.mercurial-scm.org/ReleaseNotes/7.2）
• Python 包索引（PyPI）项目页：https://pypi.org/project/mercurial/
• 对比对象：Git 2.56.0、Fossil 2.28、Darcs 2.18.5
• 数据查询日期：2026-10-28
• 数据性质：官网 / 官方发布目录 / PyPI 元数据 / 各项目官方站点；不含本机实测性能数字

💡 说明：本文出现的版本号均带发布日期，读者可按日期回查官方发布记录。凡属"官方自述"而非第三方实测的表述，正文会显式标注来源，避免把宣传口径当成基准测试结论。

二、软件概述

2.1 它是什么

Mercurial 是一个免费的、分布式的源代码版本管理工具。官方首页对其定位的原话是：

Mercurial is a free, distributed source control management tool. It efficiently handles projects of any size and offers an easy and intuitive interface.

翻成中文即：免费、分布式、能处理任意规模项目、接口简单直观。它的核心特征是"每个克隆都持有完整项目历史"——官方在同一页面写道：

Every clone contains the whole project history, so most actions are local, fast and convenient.

这意味着提交、查看日志、比对差异、切分支等日常操作全部在本地完成，不依赖网络；只有 push/pull/clone 这类同步动作才需要连服务器。这也是"分布式版本控制"（DVCS）区别于 SVN 这类集中式系统的根本点。

Mercurial 的另一个设计目标写在官网"it just works"一节：

Mercurial strives to deliver on each of its promises. Most tasks simply work on the first try and without requiring arcane knowledge.

即开箱即用、少踩坑——这是它与 Git 在用户体验取向上最明显的分野：Mercurial 倾向把复杂机制收进默认行为，命令语义稳定，历史包袱少。

2.2 项目身份与治理

从 2005 年 5 月的 0.1 版到 2026 年 8 月的 7.2.4，项目已持续维护 21 年。这一点对选型很重要：Mercurial 不是"新潮实验品"，而是一个成熟度极高、变更节奏克制的老牌工具，适合放进需要长期稳定的基础设施清单。

2.3 版本节奏

官方 Release Notes 侧栏按时间倒序列出全部功能版本，把最近几个版本的发布日期摘出来即可量化节奏：

关键结论：每年约 2 个功能版本，节奏稳定；补丁版（7.2.1～7.2.4）随缺陷与安全问题发布，不含新特性。对生产环境而言，这意味着可以按"每年两次评估功能版、补丁版随时跟进"的节奏做版本管理，不会像某些高频发布项目那样疲于奔命。

⚠️ 注意：发行版仓库自带的 hg 往往显著落后于官方版本。以 Ubuntu 22.04 的 universe 仓库为例，其打包版本为 6.1.1，与官方 7.2.4 相差一个大版本，缺失 6.2 之后的多项行为改进。生产环境若需要新特性，应走官方 PyPI 包或源码安装，具体步骤见《Ubuntu 22.04 安装 Mercurial 7.2.4 指南》。

三、核心架构

3.1 存储层：revlog

Mercurial 把版本数据存放在仓库目录 .hg/ 下，核心结构是 revlog——一种"只追加"（append-only）的版本化存储格式。每个被跟踪的文件对应一条 revlog，仓库的变更集（changeset）、清单（manifest）也各有一条 revlog。

revlog 的设计要点：

• 只追加、不改写：每次提交向文件末尾追加新版本，不修改既有数据，因此天然抗写入中断，也便于做增量传输。
• 增量与全量混存：每个版本可存为相对前一个版本的差异（delta）或完整快照（full text），由启发式策略决定，兼顾空间与读取速度。
• 按需计算校验：节点 ID 由内容哈希生成，读取时可校验完整性；hg verify 就是逐层复核 revlog、manifest、changeset 一致性的工具。

.hg/ 目录的骨架在初始化后即可见：

💡 技术拓展：版本控制的底层存储格式不止一种。常见三类——

存储模型	代表	特点
内容寻址对象库 + 引用	Git	松散对象/打包文件，按哈希寻址，分支只是引用文件
版本化追加日志（revlog）	Mercurial	每文件一条追加日志，增量/全量混存，读单文件历史快
关系库单文件	Fossil	全部内容存进一个 SQLite 数据库，事务原子
补丁集合	Darcs	历史即一组可交换补丁，按补丁理论合并

本文讨论的 Mercurial 采用 revlog；它换来的是"单文件历史查询快、仓库不易损坏"，代价是跨文件的大规模重命名追踪不如内容寻址模型灵活。

3.2 变更集 DAG 与分支模型

Mercurial 的历史是一张有向无环图（DAG），节点是变更集（changeset），边是父关系。一个变更集通常有一个父节点，合并产生的变更集有两个父节点。每个变更集由三部分组成：变更集头（作者、时间、提交说明、父节点）、清单（记录该版本全部文件及其对应 revlog 节点）、文件内容。

分支在 Mercurial 里有两种并行机制，这是初学者最容易混淆的地方：

1. 命名分支（named branch）：用 hg branch <名字> 创建，名字写进变更集元数据，永久且全局——一旦创建就留在历史里，关闭后仍可查询。执行 hg branch 时官方会提示： (branches are permanent and global, did you want a bookmark?)
2. 书签（bookmark）：用 hg bookmark <名字> 创建，本质是指向某个变更集的可移动指针，语义最接近 Git 的分支。书签可以随提交自动前移，也可以随时删除。

💡 技术拓展：主流 DVCS 的分支模型对比——

模型	代表	是否写入历史	适用场景
命名分支（永久）	Mercurial	是，分支名固化在变更集	长期维护的发布线、需要审计分支归属
书签 / 轻量指针	Mercurial bookmarks、Git branch	否，指针可移动	短期特性开发、频繁切换
补丁集合	Darcs	无分支概念，靠补丁交换	以邮件补丁为主的协作
单文件内建分支	Fossil	是	小团队一体化管理

本文建议：长期发布线用命名分支，日常特性开发用书签。这也是 Mercurial 社区的主流实践。

3.3 阶段（phases）与协作模型

阶段是 Mercurial 独有的一套"变更集成熟度"标记，用来防止误改已共享的历史：

默认情况下新提交是 draft。当变更集被推送到服务器后，会转为 public——这正是 [phases] publish=true（默认值）的行为。这套机制解决的是 DVCS 的经典风险：已经共享的历史被本地改写，导致他人仓库分叉。在 Git 中对应问题靠"保护分支 + 团队约定"解决，Mercurial 则把它做进了数据结构。

3.4 扩展机制

Mercurial 的核心保持精简，功能通过**扩展（extension）**叠加。官方随包自带一批"bundled extensions"，在 .hgrc 的 [extensions] 段按名字启用即可，例如 shelve、strip、purge、rebase、histedit、mq、largefiles、phabricator。

[extensions]
shelve =
strip =
purge =

值为空即"启用同名内置扩展"；也可写文件路径加载第三方扩展。扩展能新增命令、新增配置段、改写模板，甚至替换核心行为（如 largefiles 改变文件存储策略）。

需要注意的是：7.x 中部分曾属扩展的命令已并入核心，未启用扩展也能直接使用（shelve、strip、purge、rebase 在实测中均属此列）。判断某命令到底是内置还是扩展，最直接的办法是 hg help <命令>——若提示 (use 'hg help -e <名字>' to show help for the <名字> extension)，说明它由扩展提供。逐项配置方法见《Mercurial 7.2.4 配置参数详解》。

3.5 服务端形态

Mercurial 自带一个轻量 Web 服务器：hg serve，配合 hgweb 模板可提供浏览、日志、差异、原始文件下载与 HTTP 推送。它适合小团队内网协作与临时仓库托管，不需要外部依赖（Python 标准库即可起服务）。

大型部署则通常使用：

• Heptapod：GitLab 的 Mercurial 分支，提供 merge request 等协作能力；
• RhodeCode / SCM Manager：第三方多仓库管理平台；
• 自建 hgweb + WSGI：把 hgweb 挂到 Nginx/Apache 后面，做静态化与鉴权。

Mercurial 的 HTTP 协议只传输变更集与清单的增量，仓库越大，push/pull 的增量优势越明显。协议能力可通过 ?cmd=capabilities 查询，返回内容包含 bundle2、branchmap、pushkey、压缩算法清单等，可用于自动化巡检。

四、功能特性

4.1 核心能力清单

4.2 与 Git 工作流的语义差异

选型时最常被问的是"我会 Git，学 Mercurial 要改哪些习惯"。差异集中在四处：

最容易踩的坑是暂存区：Mercurial 没有 index，hg add 只是把文件加入跟踪清单，真正的"快照"发生在 hg commit。因此不存在"暂存一部分改动"的原生操作，需要精细拆分时改用 hg record（record 扩展）或 hg commit -I/-X 按文件筛选。

4.3 内置扩展一览（常用）

💡 说明：convert 是迁移场景的关键扩展，可把 Git 仓库转为 Mercurial 仓库（也可反向）。迁移前务必在副本上演练，转换是有损的——分支名、标签、合并结构都可能需要人工校正。

五、快速开始（官方最小示例）

5.1 获取方式

官方提供三条路径，按可控性从高到低：

1. PyPI 包：pip install mercurial，当前稳定版 7.2.4（2026-08-11）；
2. 官方源码包：mercurial-7.2.4.tar.gz，从 https://www.mercurial-scm.org/release/ 下载；
3. 发行版仓库：apt install mercurial，版本取决于发行版，通常偏旧。

5.2 克隆并提交（官方 Quick Start）

以下命令序列直接取自官网 Quick Start 页，未做本地改写：

hg clone https://www.mercurial-scm.org/repo/hello
cd hello
# (edit files)
hg add (new files)
hg commit -m 'My changes'
hg push

五条命令对应一个完整协作闭环：克隆官方示例仓库 → 编辑文件 → 把新文件纳入跟踪 → 提交 → 推送。注意 hg add 之后没有"暂存"步骤，hg commit 直接生成变更集。

5.3 创建项目并提交（官方 Quick Start）

hg init (project-directory)
cd (project-directory)
# (add some files)
hg add
hg commit -m 'Initial commit'

hg init 只创建 .hg/ 元数据目录，不生成任何工作文件；hg add 不带参数表示"把当前目录下所有未跟踪文件加入跟踪"。

⚠️ 注意：官网示例中的 (new files)、(project-directory) 是占位说明，不是可执行参数。实际使用时替换为真实文件名或目录名，例如 hg init /opt/hg-demo。

5.4 一条命令看懂当前状态

日常最高频的命令是 hg summary，它把当前父变更集、分支、工作区是否干净、待推送状态、阶段信息压缩成几行输出。官方文档推荐用它替代连续执行 hg status + hg log + hg branch。完整命令清单与实测回显见《Mercurial 7.2.4 常用 CLI 命令与工具详解》。

六、适用场景与限制

6.1 适合选 Mercurial 的场景

• 团队规模中等、追求低培训成本：命令语义稳定，错误提示可读，新成员上手快；
• 需要长期并行的发布线：命名分支把"这条提交属于哪个发布线"写进历史，审计友好；
• 内网/离线环境：hg serve 零依赖起服务，克隆即全量历史，断网也能完整工作；
• 历史改写风险敏感：phases 从机制上阻止改写已共享提交，比"团队约定"更可靠；
• 大体量单体仓库：revlog 的单文件历史查询效率高，hg log <file> 在大仓库下依然轻快；
• 需要可预测的升级节奏：每年两个功能版，补丁版稳定，适合纳入长期维护计划。

6.2 不适合或需谨慎的场景

• 生态工具强绑定 Git：GitHub Actions、绝大多数 CI 模板、代码扫描 SaaS 默认只认 Git；
• 需要极大规模 monorepo 的稀疏检出：Mercurial 的 sparse 扩展可用，但生态与资料远少于 Git 的 sparse-checkout；
• 团队已深度使用 Git 工作流（rebase + PR + squash）：迁移成本高于收益；
• 要求"分支即目录"的轻量切换：命名分支的永久性会让频繁实验产生大量历史分支，应改用书签；
• 依赖 GitHub 作为唯一托管：GitHub 不原生托管 Mercurial 仓库，需自建或使用 Heptapod。

6.3 迁移与共存

Mercurial 可通过 convert 扩展与 Git 互转，也可用 hg-git 扩展把 Mercurial 仓库推送到 Git 远端，实现"本地用 hg、远端用 Git 托管"的混合模式。这条路径常用于渐进迁移：先让团队在熟悉的 Git 托管平台上保留协作流程，本地则逐步切换到 Mercurial 的工作方式。

七、同类选型对比

7.1 量化对比表

下表只列可核验的客观项，版本与日期均为 2026-10-28 实查结果：

如何读这张表：许可证一项，Mercurial/Git/Darcs 均为 GPL v2，Fossil 为更宽松的 BSD-2-Clause，若产品需要闭源分发嵌入，Fossil 的许可约束最小。存储模型一项，决定了"查单文件历史"与"跨文件重命名追踪"的性能侧重不同——revlog 偏前者，内容寻址偏后者。分支模型一项，直接决定团队工作流：Git 的轻量分支鼓励"每个需求一个分支"，Mercurial 的命名分支更适合"每条发布线一个分支"。

7.2 选型建议

按团队现状对号入座：

一条经验法则：工具选择应由协作拓扑决定，而不是由命令熟悉度决定。如果团队的核心协作平台已经锁定 Git 托管与 CI，那么引入 Mercurial 只会制造双份维护成本；反之，如果版本库是自建、协作圈子封闭、且更在意"历史不被误改写"，Mercurial 的 phases 与命名分支会显著降低管理负担。

7.3 社区与生态

解读：Mercurial 的生态短板不在"能不能用"，而在"周边工具是否现成"。它的官方文档质量很高（hg help 覆盖全部命令与配置项，可离线查阅），但中文资料与 CI 模板远少于 Git。若团队规模足以自建工具链，这不是问题；若依赖"开箱即用的 SaaS 集成"，则是硬约束。

八、参考链接

• Mercurial 官网首页：https://www.mercurial-scm.org/
• Mercurial 官方发布目录：https://www.mercurial-scm.org/release/
• Mercurial 7.2 Release Notes：https://wiki.mercurial-scm.org/ReleaseNotes/7.2
• Mercurial PyPI 项目页（7.2.4，2026-08-11）：https://pypi.org/project/mercurial/
• Mercurial 官方安装指南：https://www.mercurial-scm.org/wiki/InstallationGuide（wiki 页）
• Mercurial 扩展清单：hg help extensions（本地离线可查）
• Git 官方站点（2.56.0，2026-09-28）：https://git-scm.com/
• Fossil 官方站点（2.28，2026-03-11）：https://fossil-scm.org/
• Darcs 官方站点：http://darcs.net/

💡 说明：以上链接均为外部官方地址，查询日期 2026-10-28。版本号会随时间变化，复核时请以页面当日显示为准；本文表格中的日期即当日快照。