OpenJDK (Java) migrating from Mercurial?

[Arne Babenhauserheide]

Craig Ozancin <c.ozancin at gmail.com> writes:

> I did a little searching on this one and fond the following:
>
> https://openjdk.java.net/jeps/357
>
> Their official reasoning is:

… kind of flaky …

> Motivation
> There are three primary reasons for migrating to Git:
>
> Size of version control system metadata
> Available tooling
> Available hosting
>
> Initial prototypes of converted repositories show a significant reduction
> in the size of the version control metadata. 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 reduction in metadata preserves local
> disk space and reduces clone times, since fewer bits have to go over the
> wire.

While the first parts are true but self-inflicted (renaming everything
despite being asked not to, so I’m not sure whether it was intentional
to give Git an edge), the latter is wrong — or would be, if they
activated clone bundles on the server. As we’ve seen here, hg with clone
bundles sends fewer bits over the wire.

Not activating clone bundles seems very much intentional to me.

And what I just realized when I cloned the firefox repo: I can simply
download a clonebundle manually (with wget or similar), continuing the
download if the connection goes down during download, and then clone
directly from the local clone bundle.

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

This actually is a missing feature — I wish hg had it. We use it at work
in the integration with Jenkins.

> There are many more tools for interacting with Git than Mercurial:
>
> All text editors have Git integration, either natively or in the form of
> plugins including Emacs (magit plugin), Vim (fugitive.git plugin), VS Code
> (builtin), and Atom (builtin).

Isn’t this the same with hg (since they allow plugins)?

> Almost all integrated development environments (IDEs) also ship with Git
> integration out-of-the-box, including IntelliJ (builtin), Eclipse
> (builtin), NetBeans (builtin), and Visual Studio (builtin).

Isn’t hg supported via plugins there?

> There are multiple desktop clients available for interacting with Git
> repositories locally.

Same for hg?

> Lastly, there are many options available for hosting Git repositories,
> whether self-hosted or hosted as a service.

This one sadly is true — more so with the loss of BitBucket. Atlassian
buying BitBucket was really bad news :-(

So the only valid points come down to:

- renames are still expensive in hg
- no shallow clones
- less hosting options

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1076 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191116/b2cd1972/attachment.asc>