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

[matthew sporleder <msporleder%gmail.com@localhost>]

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.