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
