在版本控制系统长达数十年的生命周期中，线协议（wire protocol）的稳定性往往决定了生态系统的健康度。Mercurial 自 2005 年发布以来，其线协议经历了从 SSH 到 HTTP、从单一命令到能力协商的演进，而贯穿其中的核心原则始终是：尽可能保留旧行为，新功能通过扩展点而非破坏性变更引入。这种保守策略使得 20 年前的客户端仍能与现代服务器通信，同时也为协议的未来演进预留了空间。
HTTPv2 的内容协商机制
Mercurial 的 HTTP 线协议在 2018 年引入了版本 2 的实验性支持，其核心改进是显式的内容协商机制。与早期协议不同，HTTPv2 要求客户端和服务器通过标准的 HTTP 头部进行能力协商，而非依赖隐式的版本检测。
在实现层面，HTTPv2 定义了专用的媒体类型 application/mercurial-tbd（后更名为正式版本标识）。客户端必须在请求中携带 Accept: application/mercurial-tbd 头部，否则服务器返回 HTTP 406（Not Acceptable）。同样，请求体的 Content-Type 必须匹配该媒体类型，否则返回 HTTP 415（Unsupported Media Type）。这种严格校验确保了双方对协议版本的理解一致，避免了因版本不匹配导致的数据损坏或静默失败。
从工程角度看，这种设计提供了清晰的降级路径：当服务器收到不带 Accept 头部的请求时，可以安全地回退到 HTTPv1 处理逻辑；而客户端在收到 406/415 响应后，也能明确知晓需要降级或升级。这种显式协商模式相比隐式版本检测更具可预测性，也为协议的未来扩展奠定了基础。
Bundle 格式的演进策略
Bundle 文件是 Mercurial 离线交换仓库数据的核心格式，其向后兼容策略体现了 Mercurial 对生态兼容性的重视。目前存在两种主要格式：v1 和 v2。
Bundle v1 作为最古老的支持格式，其优势在于几乎与所有 Mercurial 客户端兼容。然而，v1 存在明显局限：它仅支持 gzip、bzip2 和 none 三种压缩引擎，无法利用现代压缩算法（如 zstd）的性能优势；同时，v1 的变更组（changegroup）结构较为固定，难以携带书签（bookmarks）、阶段（phases）等元数据。
Bundle v2 则是为扩展性设计的格式。它支持参数化配置，可通过 bundlespec 字符串指定压缩引擎（包括 zstd）、变更组版本（cg.version）、以及是否包含过时标记（obsolescence）和阶段信息。v2 的扩展性体现在其分层的段（section）设计上，允许在不破坏旧解析器的前提下添加新数据段。例如，现代 Mercurial 可以在 v2 bundle 中嵌入 rev-branch 缓存和 tags-fnodes 缓存，而旧版本客户端只需忽略不认识的段即可继续解析核心变更组数据。
值得注意的是，v2 还引入了流式（streaming）变体，通过 streamv2 类型实现极高效的生产和消费，但这种模式不保证与旧客户端兼容，适用于受控环境。
Hash Namespaces 与无中断迁移
线协议的向后兼容不仅是技术问题，更是架构哲学问题。Mercurial 核心开发者 Gregory Szorc 在 2018 年的协议未来讨论中提出了 "Hash Namespaces" 概念，旨在解决 SHA-1 向更安全的哈希算法迁移这一长期难题。
传统思路倾向于设定一个 "flag day"—— 某一天服务器强制切换到新哈希格式，所有客户端必须同步升级。这种硬切换对大型组织而言风险极高。Hash Namespaces 的替代方案是：服务器同时维护多种哈希索引（如 hg-sha1-flat、hg-blake2b-tree），客户端在请求时通过命名空间参数指定所需的哈希类型。这意味着新克隆可以使用 blake2b 树形清单，而现有克隆继续接收 SHA-1 平面清单，两者在同一仓库中并存，无需强制迁移。
这一设计同样适用于清单格式（flat vs tree manifests）的演进，甚至为潜在的 Git 互操作提供了想象空间 —— 通过维护 Git 哈希命名空间，Mercurial 服务器理论上可以对外提供 Git 兼容的线协议接口。
工程实践建议
对于需要维护跨版本 Mercurial 环境的团队，以下实践可降低兼容性风险：
协议版本协商：在客户端实现中，优先尝试 HTTPv2 握手，收到 406/415 后自动降级到 HTTPv1。避免依赖隐式行为，始终检查服务器返回的 Content-Type。
Bundle 格式选择：对外分发的 bundle 优先使用 v1 格式以确保最大兼容性；内部 CI/CD 管道可使用 zstd-v2 或 zstd-streamv2 以获取压缩速度和传输效率。
兼容性测试矩阵：建立覆盖至少三个版本跨度（当前版本、中间版本、最旧支持版本）的集成测试，验证 clone/pull/push 操作在混合版本环境中的行为。特别关注部分克隆（partial clone）场景下的回退逻辑。
监控与告警：在服务器端记录客户端使用的协议版本和 bundle 格式分布，当旧版本占比低于阈值时，可评估退役旧代码路径，但需保留至少两个主要版本的兼容窗口。
Mercurial 的线协议演进证明，向后兼容性不是技术债务，而是生态投资。通过显式协商、分层格式和命名空间隔离，VCS 可以在不中断用户工作流的前提下持续演进。对于设计需要长期维护的分布式系统协议而言，这种 "渐进式革命" 的策略值得借鉴。
参考来源
- Mercurial Bundle File Formats 官方文档：https://www.mercurial-scm.org/help/topics/bundlespec.html
- Mercurial 开发者邮件列表，HTTPv2 内容协商设计讨论（Gregory Szorc, 2018）：https://lists.mercurial-scm.org/pipermail/mercurial-devel/2018-March/113791.html
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。