On Sat, Jun 13, 2020 at 7:14 PM matthew sporleder <[email protected]> wrote: > > On Fri, Jun 12, 2020 at 6:22 PM Greg A. Woods <[email protected]> wrote: > > > > At Thu, 11 Jun 2020 20:41:58 -0700, bch <[email protected]> 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 <[email protected]> > > date: Sat May 02 11:12:49 2020 +0000 > > summary: Remove unused. > > > > changeset: 931877:42596ac89b6e > > branch: trunk > > > > -- > > Greg A. Woods <[email protected]> > > > > Kelowna, BC +1 250 762-7675 RoboHack <[email protected]> > > Planix, Inc. <[email protected]> Avoncote Farms <[email protected]> > > 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.
