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.
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 /.
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.
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.
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.
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.
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.
Denis Laxalde <denis@laxalde.org> [Sat, 15 Apr 2017 11:29:42 +0200] rev 31998
revset: properly parse "descend" argument of followlines()
We parse "descend" symbol as a Boolean using getboolean (prior extraction by
getargsdict already checked that it is a symbol).
In tests, check for error cases and vary Boolean values here and there.
Denis Laxalde <denis@laxalde.org> [Sat, 15 Apr 2017 11:26:09 +0200] rev 31997
revsetlang: add a getboolean helper function
This will be used to parse followlines's "descend" argument.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 28 Mar 2017 10:15:02 +0200] rev 31996
track-tags: write all tag changes to a file
The tag changes information we compute is now written to disk. This gives
hooks full access to that data.
The format picked for that file uses a 2 characters prefix for the action:
-R: tag removed
+A: tag added
-M: tag moved (old value)
+M: tag moved (new value)
This format allows hooks to easily select the line that matters to them without
having to post process the file too much. Here is a couple of examples:
* to select all newly tagged changeset, match "^+",
* to detect tag move, match "^.M",
* to detect tag deletion, match "-R".
Once again we rely on the fact the tag tests run through all possible
situations to test this change.