Sun, 16 Apr 2017 00:37:31 -0400 test-http: add a (glob) for Windows
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Apr 2017 00:37:31 -0400] rev 32008
test-http: add a (glob) for Windows I'm not sure why the glob was ineffective with $TESTTMP here, but replacing it with '*' works.
Sun, 16 Apr 2017 00:29:38 -0400 testlib: move the prune alias into a shell script for Windows
Matt Harbison <matt_harbison@yahoo.com> [Sun, 16 Apr 2017 00:29:38 -0400] rev 32007
testlib: move the prune alias into a shell script for Windows Cramming all of this directly into an alias doesn't play nicely on Windows. Various test-exchange-obsmarkers-case-XX.t were failing with: abort: cannot select revision when creating marker It turned out that inside debugcommands.debugobsolete(), the following differed from Linux (where they were empty, at least in the case I debugged): 'rev': ['.`;'], 'template': "'{node}\\n'"
Sat, 15 Apr 2017 18:13:10 +0200 hidden: extract the code generating "filtered rev" error for wrapping
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Sat, 15 Apr 2017 18:13:10 +0200] rev 32006
hidden: extract the code generating "filtered rev" error for wrapping The goal is to help experimentation in extensions (ie: evolve) around more advance messages.
Sat, 15 Apr 2017 18:05:40 -0400 serve: add support for Mercurial subrepositories
Matt Harbison <matt_harbison@yahoo.com> [Sat, 15 Apr 2017 18:05:40 -0400] rev 32005
serve: add support for Mercurial subrepositories I've been using `hg serve --web-conf ...` with a simple '/=projects/**' [paths] configuration for awhile without issue. Let's ditch the need for the manual configuration in this case, and limit the repos served to the actual subrepos. This doesn't attempt to handle the case where a new subrepo appears while the server is running. That could probably be handled with a hook if somebody wants it. But it's such a rare case, it probably doesn't matter for the temporary serves. The main repo is served at '/', just like a repository without subrepos. I'm not sure why the duplicate 'adding ...' lines appear on Linux. They don't appear on Windows (see 594dd384803c), so they are optional. Subrepositories that are configured with '../path' or absolute paths are not cloneable from the server. (They aren't cloneable locally either, unless they also exist at their configured source, perhaps via the share extension.) They are still served, so that they can be browsed, or cloned individually. If we care about that cloning someday, we can probably just add the extra entries to the webconf dictionary. Even if the entries use '../' to escape the root, only the related subrepositories would end up in the dictionary.
Fri, 31 Mar 2017 23:00:41 -0400 hgwebdir: allow a repository to be hosted at "/"
Matt Harbison <matt_harbison@yahoo.com> [Fri, 31 Mar 2017 23:00:41 -0400] rev 32004
hgwebdir: allow a repository to be hosted at "/" This can be useful in general, but will also be useful for hosting subrepos, with the main repo at /.
Fri, 14 Apr 2017 00:03:30 -0700 httppeer: eliminate decompressresponse() proxy
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 14 Apr 2017 00:03:30 -0700] rev 32003
httppeer: eliminate decompressresponse() proxy Now that the response instance itself is wrapped with error handling, we no longer need this code. This code became dead with the previous patch because the added code catches HTTPException and re-raises as something else.
Fri, 14 Apr 2017 00:33:56 -0700 httppeer: wrap HTTPResponse.read() globally
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 14 Apr 2017 00:33:56 -0700] rev 32002
httppeer: wrap HTTPResponse.read() globally There were a handful of places in the code where HTTPResponse.read() was called with no explicit error handling or with inconsistent error handling. In order to eliminate this class of bug, we globally swap out HTTPResponse.read() with a unified error handler. I initially attempted to fix all call sites. However, after going down that rabbit hole, I figured it was best to just change read() to do what we want. This appears to be a worthwhile change, as the tests demonstrate many of our uncaught exceptions go away. To better represent this class of failure, we introduce a new error type. The main benefit over IOError is it can hold a hint. I'm receptive to tweaking its name or inheritance.
Thu, 13 Apr 2017 22:19:28 -0700 tests: add tests for poorly behaving HTTP server
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 13 Apr 2017 22:19:28 -0700] rev 32001
tests: add tests for poorly behaving HTTP server I've spent several hours over the past few weeks investigating networking failures involving hg.mozilla.org. As part of this, it has become clear that the Mercurial client's error handling when it encounters network failures is far from robust. To prove this is true, I've devised a battery of tests simulating various network failures, notably premature connection closes. To achieve this, I've implemented an extension that monkeypatches the built-in HTTP server and hooks in at the socket level and allows various events to occur based on config options. For example, you can refuse to accept() a client socket or you can close() the socket after N bytes have been sent or received. The latter effectively simulates an unexpected connection drop (and these occur all the time in the real world). The new test file launches servers exhibiting various "bad" behaviors and points a client at them. As the many TODO comments in the test call attention to, Mercurial often displays unhelpful errors when network-related failures occur. This makes it difficult for users to understand what's going on and difficult for server administrators to pinpoint root causes without packet tracing. Upcoming patches will attempt to fix these error handling deficiencies.
Thu, 13 Apr 2017 22:12:04 -0700 phases: emit phases to pushkey protocol in deterministic order
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 13 Apr 2017 22:12:04 -0700] rev 32000
phases: emit phases to pushkey protocol in deterministic order An upcoming test will report exact bytes sent over the wire protocol. Without this change, the ordering of phases listkey data is non-deterministic.
Thu, 13 Apr 2017 18:04:38 -0700 keepalive: send HTTP request headers in a deterministic order
Gregory Szorc <gregory.szorc@gmail.com> [Thu, 13 Apr 2017 18:04:38 -0700] rev 31999
keepalive: send HTTP request headers in a deterministic order An upcoming patch will add low-level testing of the bytes being sent over the wire. As part of developing that test, I discovered that the order of headers in HTTP requests wasn't deterministic. This patch makes the order deterministic to make things easier to test.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip