合并 JDK 10 OpenJDK Mercurial 资源群的提议

在 OpenJDK 邮件列表的一封邮件中，Oracle 的JDK 工程师 Joe Darcy 提议将 JDK 10 OpenJDK 的 Mercurial （又称“Hg”，意思为水银）源码资源群（repositories）合并为一个单一资源库。

目前 JDK 9 OpenJDK 是 Hg 资源群结构，即由多个相关的 Hg 资源库组成。JDK 9 的这个资源群由 8 个资源库组成：

• root
• corba
• hotspot
• jaxp
• jaxws
• jdk
• langtools
• nashorn

提议合并的动机始于 JEP 296 ，目的是消除维护多个资源库所带来的不利因素。例如，以现在的集群结构，无法将一个 bug 的修复传播到群内的多个资源库。单一资源库的一个好处是，可以追踪一堆文件的变更历史而不仅仅是单个文件。

JEP 中其他可选的提案是（a）保持现有的 Hg 资源群、（b）只合并这些资源群的核心子集，但后者被否决了。同时也决定不将 JavaFX 包含到 Hg 资源群中。

尽管在提案中已包含了对预期到的疑问的回答，但还是引起了贡献者们对其扩展性、性能以及其他麻烦的讨论，特别在这篇回复中提出了一系列问题。为了将注意力引回到“大局”中，Oracle 语言架构师 Brian Goetz 这样解释：

利益相关者不仅仅只有 OpenJDK 的开发者们。像其他开发人员一样，把代码维护在一个线性的、事务级更新的资源库中，可以增加项目的可行性，减少使用‘bisect’等工具检查问题引入源所花费的代价。同时也减少了软件测试环境相关的成本，并提升了产品质量，这对我们大家都有好处。同时 David Lloyd 指出了其他与工具相关的优势，如更方便地维护一个 git 镜像。

目前主要的反对声是来自于“（我认为他们会）让开发变得困难”的想法。这很正常，人们为自己辩护无可厚非。但是别忘了这样做给 * 大家 * 所带来的巨大好处，在判断利弊时要将这点也考虑进去。

这不是 Oracle 第一次试图清理 OpenJDK 的 Hg 资源群。早在 2013 年 11 月，Darcy 就提议“JDK 9 使用替代的资源群结构，进而显著缩短资源群内 bug 修复的传播时间。”

相关资源
为验证 Hg 资源群的合并，已经创建了一个原型，可以在此下载它的 Python 支持脚本（具体说明如下）。

• convert.py：包含为合并做的准备工作，将资源群中每个资源库转换成一个合适的形式。
• unify.py：将所有转换完的资源库合并到一个资源库。
• verify.py：验证资源群和合并后资源库的文件内容，确保每个历史 tag 都一致。这是使用 diff(1) 实现的。

这个原型包含了 8 个资源库，并通过 Python 脚本进行合并。变更历史、变更注释和原始的创建时间都会被保留。合并后的单一资源库将包含一个顶级 src 目录。例如：

$ROOT/jdk/src/java.base
$ROOT/langtools/src/java.compiler

合并为

$ROOT/src/java.base
$ROOT/src/java.compiler

查看英文原文： Proposed Consolidation of JDK 10 OpenJDK Mercurial Repositories

感谢冬雨对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。