OpenJDK (Java) migrating from Mercurial?

[Craig Ozancin]

On Sat, Nov 16, 2019 at 3:02 PM Arne Babenhauserheide <arne_bab at web.de>
wrote:

>
> 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.
>
>
I know that this was a big issue for Facebook and the reason for creating
remotefilelog.


> > 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?
>
>
A quick google search on mercurial and netbeans takes you to the netbeans
page that discusses enabling mercurial support. I haven't used Netbeans for
quite a few years, but when I did, the support was on par with the git
support.


> > 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
>
> What git doesn't provide:

- revsets
- hg phases
- hg evolve

These save me considerable amount of time and frustration and make
the workflow so much smother.

Git doesn't even come close on these.

Git does provide plumbing commands from the command line which
gives new users the ability to completely corrupt the repository. :)


> Best wishes,
> Arne
> --
> Unpolitisch sein
> heißt politisch sein
> ohne es zu merken
> _______________________________________________
> Mercurial mailing list
> Mercurial at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20191117/ae11532d/attachment-0002.html>