hg clone is unbelievably slow

[Mario Torre]

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/