JEP 296: Consolidate the JDK Forest into a Single Repository
要約
原文
Combine the numerous repositories of the JDK forest into a single repository in order to simplify and streamline development.
翻訳
多数の林立しているJDKリポジトリを一つにまとめて、開発を合理化します。
動機
原文
For many years, the full code base of the JDK has been broken into numerous Mercurial repositories. In JDK 9 there are eight repos: root, corba, hotspot, jaxp, jaxws, jdk, langtools, and nashorn.
While this model of multiple repos offers some advantages, it also has many downsides and does a poor job of supporting various desirable source-code management operations. In particular, it is not possible to perform an atomic commit across repositories of inter-dependent changesets. For example, if the code for a single bug fix or RFE spans both the jdk and hotspot repos today, the change to both repositories cannot be done atomically in the forest hosting those two distinct repos. Changes spanning multiple repos are a common occurrence; over 1,100 bug ids have been reused across repositories in the JDK forest. The 1,100+ repo-crossing bugs is only a lower bound on the number of logically repo-crossing bugs, since some engineers use separate bug ids to push to different repos.
This mismatch between the divisions of the Mercurial repos and unity of the engineering dilutes one of the main benefits of modern source-code management: tracking changes to sets of files rather than just individual files. As a corollary, this mismatch between SCM transactions and logical transactions complicates use of tools such as Mercurial bisect.
The individual repos don't have a development cycle separate from the JDK as a whole; all the repos advance in lockstep with the JDK promotion cycle. The multiplicity of repos presents a larger than necessary barrier to entry to new developers and has lead to workarounds such as the "get source" script.
翻訳（意訳：間違ってるかも）
長年の間、全てのJDKのコードベースは、多数のMercurialリポジトリに分断されていた。
JDK9の中には、root, corba, hotspot, jaxp, jaxws, jdk, langtools, nashorn の８つのリポジトリが存在している。
この構成は、多少のメリットがあると同時に、それぞれのソースコードを管理する上では貧弱であるデメリットがあります。
特に、相互に依存する変更箇所をコミットすることはできません。
例を挙げると、単一のバグ修正や機能拡張のエンハンス対応が、現在のJDKと改修中のリポジトリの両方に変更が必要な場合は、競合がおこってしまいます。複数のリポジトリにまたがる変更は、一般的に存在するものです。
1,100以上のバグが、JDKのリポジトリで同一バグとして修正されています。
1,100以上のリポジトリをまたがったバグは、論理的には下限値ではありません。なぜなら、一部のエンジニアが、同一バグを別のバグIDを使用してリポジトリに反映させているからです。
Mercurialリポジトリの分割と統一されたエンジニアリングの両方を成立させるという相反する考えは、ソースコード管理の主なメリット（変更したファイル群の変更追跡）を弱くする。
その結果、ソースコード管理と論理的課題の間に起こる不一致は、Mercurial bisectなどのツールの利用を複雑化する。
各リポジトリは、JDK全体の開発サイクルから独立しているわけではありません。
全てのリポジトリは、JDKの進捗状況と足並みを揃える必要があります。
多くのリポジトリが存在することは、新規開発者の参入に大きな弊害をもたらしたて、ソースコード入手方法が複数存在する状態になっています。
詳細
疲れたからパス
