hg clone is unbelievably slow
neugens.limasoftware at gmail.com
Tue Feb 6 14:10:59 UTC 2018
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.
2018-02-06 15:04 GMT+01:00 Remi Forax <forax at univ-mlv.fr>:
> creating a tgz at each commit doesn't seems that difficult ...
> ----- 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/
Please, support open standards:
More information about the jdk-dev