New candidate JEP: 357: Migrate from Mercurial to Git

[Joe Darcy]

Hello,

On 7/16/2019 7:23 AM, Aleksey Shipilev wrote:
> On 7/16/19 2:19 PM, Severin Gehwolf wrote:
>
[snip]

>>>   *) 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;
>> Right. As David Lloyd said, this seems to be a one-time investment.
>> Consider 3 years down the line after a conversion, would you still have
>> a productivity loss?
> Look at it this way: I routinely deal with multiple JDK release trains.
>
> They are:
>   * 8u: Mercurial forest
>   * 9u+: Mercurial forest with major Jigsaw-inspired reshuffling
>   * 10u+: Mercurial monorepo with yet another major reshuffling
>   * 14+: Git monorepo (?)
>
> The cost of moving the changes between these differently shaped repos is significant. Here, 8u is
> way over "3 years down the line", and we are still paying the cost. I cannot honestly say
> introducing another repo shape would simplify this story in foreseeable future. This is the cost
> maintainers would pay for quite a long time, and it should be acknowledged and agreed upon.

There is a saying along the lines of "the best time to plant a tree is 
twenty years ago; the second best now time now."

Slides 10 through 27 of [1], given at the August OCW last year, 
summarize the changes in SCM usage from JDK 8 (graph of integration hg 
forests) to JDK 12 (most developers push directly to a single hg master 
repo).

Assuming you agree the shared monorepo is structurally preferable to the 
collection of team forests (modulo cloning issues), what other sort of 
path do you suggest to get from one arrangement to another? I can easily 
imagine a criticism of "trying to do too much at once" if coalescing 
some of the intermediate steps was proposed instead.

Or do you think the overheads associated with those changes are too high?

These kinds of changes are never especially convenient to make, but if 
they are never made, we can never get the benefits of them either.

(The maintenance costs would be reduced if the older release trains 
weren't maintained as long, but people want to use the older releases 
too of course.)

Cheers,

-Joe

[1] "Call for Discussion: Project Skara
Investigating source code management options for the JDK sources"

http://cr.openjdk.java.net/~darcy/Presentations/ocw-2018-08-01-skara.pdf