hg clone is unbelievably slow

[Thomas Stüfe]

Side question, we would only need to tar the .hg folder, no? And revive the
workspace with hg update?

On Tue, Feb 6, 2018 at 3:10 PM, Mario Torre <neugens.limasoftware at gmail.com>
wrote:

> I think it should probably be done on demand, it may be more expensive
> to keep a commit based tgz otherwise.
>
> In fact the most awesome thing would be to have a special repository
> that we clone but gives us back only the tgz to unpack locally, with
> all the history and correct hg paths.
>
> Cheers,
> Mario
>
> 2018-02-06 15:04 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:
> > +1
> >
> > creating a tgz at each commit doesn't seems that difficult ...
> >
> > Rémi
> >
> > ----- Mail original -----
> >> De: "Andrew Haley" <aph at redhat.com>
> >> À: "jdk-dev" <jdk-dev at openjdk.java.net>
> >> Envoyé: Mardi 6 Février 2018 11:50:07
> >> Objet: hg clone is unbelievably slow
> >
> >> Half an hour or more here.  AFAIK the problem is due to the
> >> inefficiency of Mercurial itself and the hg protocol.
> >>
> >> Aleksey Shipilev has done an experiment whereby trees are regularly
> >> cloned and compressed tarballs created; these can be downloaded in a
> >> couple of minutes.  But really we don't want to depend on the largesse
> >> of one developer: if we could download the OpenJDK trees directly by
> >> means of wget (or something similar) we would reduce the load on the
> >> servers and reduce the time taken to download as well.
> >>
> >> --
> >> Andrew Haley
> >> Java Platform Lead Engineer
> >> Red Hat UK Ltd. <https://www.redhat.com>
> >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>
>
>
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>