Proposal to Migrate JDK from Mercurial to Git Gets a JEP

Call it "A Tale of Two Repositories."

Mercurial is a free, cross-platform, distributed version-control system (SVM), and current host of the source files and change histories of most JDK projects since 2008. Git is the free, cross-platform, distributed version-control system that is almost certain to become the new home of those repositories.

It has been almost exactly one year since the launch of Project Skara, an investigation of alternative source-code management (SCM) systems and code review options for the JDK -- and in particular, whether Git might not be a better option than Mercurial. Sponsored by the Build Infrastructure Group and led by Joseph Darcy, a member of the Technical Staff at Oracle, the project sparked a serious discussion in the Java community about SCM options for OpenJDK.

For at least two Java jocks (and a whole lot more), that discussion turned into action last week, when Darcy and his colleague on Oracle's Technical Staff, Erik Duveblad, proposed JEP 357, the goal of which is to "Migrate all single-repository OpenJDK Projects from Mercurial to Git."

The list of specific goals of JEP 357 includes:

• Migrate all single-repository OpenJDK Projects from Mercurial to Git
• Preserve all version control history, including tags
• Reformat commit messages according to Git best practices
• Port the jcheck, webrev, and defpath tools to Git
• Create a tool to translate between Mercurial and Git hashes

The JEP's authors also included a list of things they will not do:

• We will not migrate multi-repository OpenJDK Projects, such as the JDK 8 Updates Project. Those Projects can migrate to Git if and when they consolidate into a single repository.
• We will not change the bug system from JBS.
• We will not address the question of whether OpenJDK Git repositories will be self-hosted or hosted by an external provider. That issue will be the topic of a future JEP.
• We will not propose changes to the current JDK development process, though this JEP does enable such changes.

The bottom line for proponents of this move is that Git has the potential to handle larger projects. In the prototypes initially developed via the Skara project, converted repositories showed "a significant reduction in the size of the version control metadata," the JEP authors reported. In one example cited, the .git directory of the jdk/jdk repository, which is approximately 300 MB with Git is about 1.2 GB with Mercurial, depending on the Mercurial version being used.

"The reduction in metadata preserves local disk space and reduces clone times," they wrote, "since fewer bits have to go over the wire. Git also features shallow clones that only clone parts of the history, resulting in even less metadata for those users who do not need the entire history."

And then there's the bulging toolbox Git provides: text editors with Git integration (native and plugins), including Emacs, Vim, VS Code, and Atom; almost all IDEs ship with Git integration out of the box, including IntelliJ, Eclipse, NetBeans, and Visual Studio; and multiple desktop clients are available for local interaction with Git repositories.

The group working on JEP 357 has already prototyped a program to convert a Mercurial repository to a Git repository. The structures of commit messages for both Mercurial and Git jdk/jdk repositories are shown on the JEP page. The group has also prototyped backward compatible ports of several Mercurial tools.

Examples of converted repositories are available at https://github.com/openjdk/.

Posted by John K. Waters on July 17, 2019