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

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sat, Jun 13, 2020 at 07:14:04PM -0400, matthew sporleder wrote:
> 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.

The "files" stage means it is adding the various deltas, it doesn't mean
it is checking out the working copy. What is happening here is that the
server cuts the connection after some period of inactivity and the
client has to "deal" with the EOF. I know one specific situation in
which I can trigger that problem with a slightly non-default nginx
configuration locally (lowering send_timeout). After all the changesets
are applied locally, the client has to recompute the phase sets. The
current version of the computation is slower than necessary and in
combination with the almost 1 million revisions, it can take a minute or
so in the old version even on faster hardware. What makes debugging
harder is that the actual EOF comes much later, since in my case there
is a MB in the local (kernel) TCP buffer.

Joerg