Call for Discussion: New Project: Skara -- sample repacked git repo of JDK 12 sources now available

[Mario Torre]

Nice, however I would not like to rely on GitHub. What if it’s down in the
middle of a security errata?

Cheers,
Mario
On Mon 13. Aug 2018 at 13:40, Remi Forax <forax at univ-mlv.fr> wrote:

> from an island on the atlantic coast of France:
>
> time git clone https://github.com/Project-Skara/jdk.git
> Cloning into 'jdk'...
> remote: Counting objects: 881253, done.
> remote: Compressing objects: 100% (160363/160363), done.
> remote: Total 881253 (delta 665729), reused 881253 (delta 665729),
> pack-reused 0
> Receiving objects: 100% (881253/881253), 258.61 MiB | 1.49 MiB/s, done.
> Resolving deltas: 100% (665729/665729), done.
> Checking out files: 100% (66258/66258), done.
>
> real    3m22.779s
> user    1m9.630s
> sys     0m12.783s
>
> hg clone for me is 24 minutes (when there is no connection reset by peer).
>
> The fact that github as mirrors in Europe is a huge win.
>
> Rémi
>
> ----- Mail original -----
> > De: "Aleksey Shipilev" <shade at redhat.com>
> > À: "joe darcy" <joe.darcy at oracle.com>, "discuss" <
> discuss at openjdk.java.net>
> > Envoyé: Lundi 13 Août 2018 09:51:22
> > Objet: Re: Call for Discussion: New Project: Skara -- sample repacked
> git repo of JDK 12 sources now available
>
> > On 08/13/2018 07:26 AM, joe darcy wrote:
> >> PPS A repacked sample git repo, as alluded to earlier in this thread
> and as
> >> discussed in the Skara
> >> presentation from the OpenJDK Committers’ Workshop, equivalent to a
> recent
> >> snapshot of JDK 12 is
> >> available for browsing and cloning from:
> >>
> >>     git clone https://github.com/Project-Skara/jdk.git
> >>     https://github.com/Project-Skara/jdk
> >>
> >
> > Nice! Some performance data from Germany:
> >
> > $ time git clone https://github.com/Project-Skara/jdk.git
> > Cloning into 'jdk'...
> > remote: Counting objects: 881253, done.
> > remote: Compressing objects: 100% (160363/160363), done.
> > remote: Total 881253 (delta 665729), reused 881253 (delta 665729),
> pack-reused 0
> > Receiving objects: 100% (881253/881253), 258.61 MiB | 5.32 MiB/s, done.
> > Resolving deltas: 100% (665729/665729), done.
> > Checking out files: 100% (66258/66258), done.
> >
> > real  1m25.508s
> > user  1m8.522s
> > sys   0m6.595s
> >
> > For the comparison, pulling the .hg workspace snapshot:
> >
> > $ time (curl https://builds.shipilev.net/workspaces/jdk-jdk.tar.xz |
> tar xJf -;
> > cd jdk-jdk; hg pull;
> > hg up;)
> >  % Total    % Received % Xferd  Average Speed   Time    Time     Time
> Current
> >                                 Dload  Upload   Total   Spent    Left
> Speed
> > 100  752M  100  752M    0     0  5673k      0  0:02:15  0:02:15 --:--:--
> 5737k
> > pulling from http://hg.openjdk.java.net/jdk/jdk
> > searching for changes
> > adding changesets
> > adding manifests
> > adding file changes
> > added 116 changesets with 1065 changes to 858 files
> > new changesets cf34c71ca27c:802f7e5e7e6b
> > (run 'hg update' to get a working copy)
> > 66288 files updated, 0 files merged, 0 files removed, 0 files unresolved
> >
> >
> > real  2m31.941s
> > user  1m35.735s
> > sys   0m22.859s
> >
> > It looks that the limiting factor here is the actual network bandwidth.
> So, the
> > performance is in
> > the same ballpark, and if .hg would be smaller (my experiments saw 1.3x
> > decreases with enabling some
> > Mercurial options), we can get this down to 2 minutes.
> >
> > -Aleksey
>