New candidate JEP: 357: Migrate from Mercurial to Git

Joe Darcy joe.darcy at oracle.com
Tue Jul 16 16:26:07 UTC 2019


On 7/16/2019 12:38 AM, Aleksey Shipilev wrote:
> On 7/15/19 10:10 PM, Joe Darcy wrote:
>> 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.
> This comment of mine still stands very firmly.
>
>>> 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:
>>
>>      ...>
>> These are live mirror updated within a few minutes after a push occurs to the corresponding hg repo.
> You see, this is the other way around. These are read-only Git mirrors of active Mercurial repos, of
> course there is no impact, we can just ignore Git mirrors exist. What JEP proposes is to switch work
> to Git mirrors (and maybe have read-only Mercurial repos _tracking_ them? not clear from JEP text),
> this would be non-ignorable thing. If you look carefully, your comment does not address my concern
> at all.


Yes, I understand the difference between a git mirror of an hg master 
and a hg mirror of a git master.


>>>    *) 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;


[snip]


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


To be more explicit, the potential crunch associated with an SCM 
migration can be lessened if the tasks associated with the migration are 
spread out over time and, if downstream builders were interested in 
doing experiments to see what refitting their pipelines would involve, 
that work can occur today since there are live git mirrors to work from.

-Joe



More information about the discuss mailing list