Re: "hg clone https://anonhg.netbsd.org/src/" still aborts, but...

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

I've been watching the discussion with interest, as I am not
particularly verse in these topics; perhaps I've done something not
correctly, but on my 6 years old laptop (4c8t, 20GB memory, core-i7
3820-qm) the full ' hg clone https://anonhg.netbsd.org/src/' (on a ZFS
placed on an mSATA device) took some 45-50 minutes; the resulting repo
takes about 5GB. I am cloning xsrc right now and will go through a
full build.


On Fri, 19 Jun 2020 at 11:39, matthew sporleder <msporleder%gmail.com@localhost> wrote:
>
> On Sat, Jun 13, 2020 at 7:14 PM matthew sporleder <msporleder%gmail.com@localhost> wrote:
> >
> > On Fri, Jun 12, 2020 at 6:22 PM Greg A. Woods <woods%planix.ca@localhost> wrote:
> > >
> > > At Thu, 11 Jun 2020 20:41:58 -0700, bch <brad.harder%gmail.com@localhost> wrote:
> > > Subject: Re: "hg clone https://anonhg.netbsd.org/src/"; still aborts, but...
> > > >
> > > > Nb: you’ll want to have an .hg/hgrc w a line:
> > > > default = https://anonhg.netbsd.org/src
> > > >
> > > > ...so that in the future you can just “hg pull” from w/i that repo.
> > >
> > > Thanks for the tip -- I figured something would have to be set like that.
> > >
> > > Looks like it's not quite right though:
> > >
> > >         $ cat .hg/hgrc
> > >         default = https://anonhg.netbsd.org/src
> > >
> > >         $ hg incoming
> > >         abort: repository default not found!
> > >
> > > The manual section for "hg clone" does say:
> > >
> > >        The location of the source is added to the new repository's .hg/hgrc
> > >        file, as the default to be used for future pulls.
> > >
> > > However hgrc(5) suggests the syntax might have to be a bit different,
> > > more like a .git/config.
> > >
> > > Ah ha!  It looks like this has to be in the "[paths]" section, and MUST
> > > NOT be proceeded by a tab or other whitespace (which .git/config allows):
> > >
> > >         $ cat .hg/hgrc
> > >         [paths]
> > >         default = https://anonhg.netbsd.org/src
> > >
> > >         $ hg incoming | head
> > >         comparing with https://anonhg.netbsd.org/src
> > >         searching for changes
> > >         changeset:   931876:26c8f37631b6
> > >         branch:      trunk
> > >         user:        maxv <maxv%NetBSD.org@localhost>
> > >         date:        Sat May 02 11:12:49 2020 +0000
> > >         summary:     Remove unused.
> > >
> > >         changeset:   931877:42596ac89b6e
> > >         branch:      trunk
> > >
> > > --
> > >                                         Greg A. Woods <gwoods%acm.org@localhost>
> > >
> > > Kelowna, BC     +1 250 762-7675           RoboHack <woods%robohack.ca@localhost>
> > > Planix, Inc. <woods%planix.com@localhost>     Avoncote Farms <woods%avoncote.ca@localhost>
> >
> > I have just updated the bundle manifest to use anonhg instead of cdn
> > and *I* get the same issue.
> >
> > I am interested in other peoples' experiences but am glad that I've
> > eliminated fastly from the equation.
> >
> > I've also tried making some changes to the apache config, trying a
> > gzip bundle, and a few other variants.
> >
> > In the end I land on:
> >
> > files [============>
> >                                      ]  59368/440465 3h47mdestination
> > directory: src
> > applying clone bundle from https://anonhg.NetBSD.org/_bundles/src/matt-gzip.hg
> > adding changesets
> > adding manifests
> > adding file changes
> > transaction abort!
> > rollback completed
> > (sent 2 HTTP requests and 434 bytes; received 806 bytes in responses)
> > abort: stream ended unexpectedly  (got 12392 bytes, expected 32768)
> >
> >
> > Why would there be any network activity in the "files" stage at all?
> > This entire bundles extension appears poorly architected or,
> > ironically, poor for less performant systems.
> >
> > I think the curl + extract + pull is probably the only way forward.
>
>
> one more datapoint is that I can't clone the mozilla source repo (also
> a big one and also a big user of the built-in clone extension)
>
> hgtest $ hg clone https://hg.mozilla.org/mozilla-central/ firefox-source -Uv
> applying clone bundle from
> https://hg.cdn.mozilla.net/mozilla-central/fa0afb4328103e7e61b98b3b2706891334eb2926.zstd-max.hg
> adding changesets
> adding manifests
> adding file changes
> transaction abort!
> rollback completed
> (sent 2 HTTP requests and 452 bytes; received 4673 bytes in responses)
>
> So anyway I think it is safe to assume that it might just be hg clone
> not working on small or slow hardware
>
> --
>
> FWIW I *was* able to do a clone without a bundle with this command:
> hg clone --rev $(hg identify https://anonhg.netbsd.org/src/|awk '{
> print $1 }') https://anonhg.netbsd.org/src/
>
> I *think* that does a "shallow"(?) clone as I'm choosing to start at
> the --rev from the last "identify" although I actually don't know what
> I got except that the command finished.
> This is probably much more work on the server side but I didn't measure.



-- 
----