New candidate JEP: 357: Migrate from Mercurial to Git

[Severin Gehwolf]

Hi Aleksey,

Source control discussions tend to be very opinionated. I'm not sure
all arguments can be objectively answered let alone quantified. Please
keep that in mind when reading my comments below. Again, as said
elsewhere, I'm biased towards Git.

On Mon, 2019-07-15 at 20:52 +0200, 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.

Should this JEP go into the details of advantages/disadvantages of HG
vs. Git itself? I wouldn't think so, but your mileage may vary.

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

I think many of those have been converted already for somebody to take
a look:

Amber: https://github.com/openjdk/amber
Shenandoah: https://github.com/openjdk/shenandoah
Panama: https://github.com/openjdk/panama
Portola: https://github.com/openjdk/portola
Valhalla: https://github.com/openjdk/valhalla
Loom: https://github.com/openjdk/loom

Perhaps it would be reasonable to provide some info on how those
repositories got converted and how much time it to to convert them.
This would allow involved parties to ball-park estimate their up-front
conversion work.

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

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

Could you perhaps in more detail explain what bearing source control
has on the actual building of projects? I understand that source code
has to get fetched somewhere, but once local, the build pipeline would
work in a similar fashion beyond that point, right?

FWIW, for Fedora fresh source tarball clones (package updates) would be
significantly faster via git shallow clones (we don't need the history
at all, just the source code).

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

Only if current mercurial repositories cease to exist entirely, I'd
think, no?

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

Consider preserving old HG repositories at hg.o.j.n. If they'd be read-
only, old links would still work.

>  *) There are improvements to Mercurial that can make the conversion advantages less appealing. For
> example, clonebundles that I pointed out multiple times over the year (and Mark promised to deliver,
> at OpenJDK Committers Workshop in February 2019) is still not enabled:
> https://bugs.openjdk.java.net/browse/JDK-8211383. Instead, we have "Alternatives: Keep using
> Mercurial" (sic!).

That's a valid alternative measure. It would not address the *local*
storage requirements though, would it? The JEP says:

"""
For example, the .git directory of
the jdk/jdk repository is approximately 300 MB with Git and the .hg directory
is around 1.2 GB with Mercurial, depending on the Mercurial version being used.
"""

>  *) The claim that "There are many more tools for interacting with Git than Mercurial" look dubious.
> For the tools I use from that list: IntelliJ, NetBeans, Atom are supporting Mercurial as well.

I wonder how the "builtin" vs. "available via extensions" compare for
those. Does somebody know?

Looking at the 3 primary reasons for migrating to Git:

 * Size of version control system metadata

Local metadata storage: That is, size of local metadata in .git/.hg
where Git seems to win.
Fresh clone times: Git has fewer metadata to transfer (above). JDK-
8211383 could help for Mercurial how does it compare? Is there a
"shallow" clone option for mercurial? The JEP seems to allude it's not
present in HG[1].

 * Available tooling

Git:       https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools
Mercurial: https://www.mercurial-scm.org/wiki/OtherTools

 * Available hosting

Mercurial: https://www.mercurial-scm.org/wiki/MercurialHosting
Git:       https://git.wiki.kernel.org/index.php/GitHosting

Thanks,
Severin

[1] https://www.mercurial-scm.org/wiki/ShallowClonePlan
>