New candidate JEP: 357: Migrate from Mercurial to Git

Joe Darcy joe.darcy at oracle.com
Mon Jul 15 20:10:21 UTC 2019


Hello,

On 7/15/2019 11:52 AM, Aleksey Shipilev wrote:
> On 7/15/19 7:54 PM, mark.reinhold at oracle.com wrote:
>> https://openjdk.java.net/jeps/357
> Unfortunately, this JEP only discusses the advantages, and does not discuss the disadvantages of
> performing this move.
>
> The disadvantages, off the top of my head:
>   *) Conversion takes time and effort for all projects, including those developed outside of
> mainline: Amber, Loom, Panama, Portola, Shenandoah, Valhalla to name a few;


Clearly the development processes of the projects in question would have 
to be updated at least slightly if the SCM used for the code is changed. 
Just on an administrative front, several months back as part of Skara 
mirrors of git conversions of Amber, Loom, Panama, etc. were put up on 
github:

     https://github.com/openjdk/amber
     https://github.com/openjdk/loom
     https://github.com/openjdk/panama
     https://github.com/openjdk/portola
     https://github.com/openjdk/shenandoah
     https://github.com/openjdk/valhalla

These are live mirror updated within a few minutes after a push occurs 
to the corresponding hg repo.

>   *) Developers who are already quite constrained to deliver things with 6 months pace would have to
> re-adjust their workflows, some would need re-training to Git, many would have to accept the
> temporary productivity losses, and/or modify their delivery schedules;


Yes; it is true, switching SCMs would involve a nonzero amount of time 
and effort to learn the new tool. This is true independent of the length 
of the release cycle. Since the proposal is to change to the most widely 
used distributed SCM, one that has extensive tooling support, there are 
plenty of learning materials available. Additionally, if there is 
interest, the Skara team could do a "git for recalcitrant hg users" 
online talk.


>   *) Downstream builders would need to refit their pipelines after the move -- and there are lots of
> them;

In September 2018 the JDK build was updated to work with either git or 
hg as the SCM, JDK-8210283.

If there was interest, build pipelines could be created based on the 
existing git mirrors today.

>
> Additionally, not addressed:
>   *) Existing hgupdater links in JBS would have to be updated, or they would break;


There is nothing in the JEP that requires or implies the old hg repos 
need to be destroyed. I would recommend leaving them in place as 
read-only archives. Barring that, I recommend a proxy to rewrite the hg 
links into equivalent git ones. The Skara conversion process includes a 
map of corresponding hashes between the hg and git repos.


>   *) External links to hg.o.j.n -- that were deemed to be permalinks to the JDK source code, perhaps
> with lots of wishful thinking involved -- would break;


Breaking the links could be added as a non-goal of JEP. (I frequently 
use those links myself.)

Cheers,

-Joe



More information about the discuss mailing list