This allows using
application = hgwebdir(...)
application.motd = (string or object with __str__ method)
in WSGI (like it is possible in CGI).
Changed web.motd in the config file is still read with this, because
hgwebdir.templater.motd() does not store the config value.
Before this patch, the only way to get hgwebdir to honor the recursive paths
was to create a config object or a config file with the recursive paths in it.
This patch makes hgwebdir treat paths the same whether passed in as a list,
tuple, config or however hgwebdir supports passing paths.
The old default behaviour of hgwebdir was to maintain a list of
repositories permanently. This interacted badly with persistent
application hosting software such as WSGI containers. If a new repository
was published, it would potentially never appear in the top-level list
of repositories.
This change causes the hgwebdir configuration and list of repositories
served to be refreshed periodically (at most every 20 seconds).
Before this patch, hgwebdir suddenly showed up empty for a webdir-conf file
that was for some reason not trusted. This was previously not a problem because
the trust mechanism wasn't required for the very separate webdir-conf.
This cleans up code and allows specification of values more globally. For
example, it's now possible to specify web.contact in webdir-conf for all
repositories without a specified contact set.
collections: direct child repos only
paths *: direct child repos only (like collections)
paths **: recursive discovery
When ** is used, the mq repository (if any) is also shown.
This feature somehow duplicates [collections] but it is simpler to use and has
less issues under Windows where using absolute path as configuration file key
is not supported.
Suggested by Dirkjan Ochtman <dirkjan@ochtman.nl>
Currently hgweb is not streaming its output -- it accumulates the
entire response before sending it. This patch restores streaming
behaviour. To avoid having to synchronously write many tiny fragments,
this patch also adds buffering to the template generator. Local
testing of a fetch of a 100,000 line file with wget produces a slight
slowdown overall (up from 6.5 seconds to 7.2 seconds), but instead of
waiting 6 seconds for headers to arrive, output begins immediately.
This is a new version of b6b16fec2a60 (which was backed out in faf83e1e40f5),
with an extra line removed to fix problems with hg serve. hg's internal web
server contains checking if the app isn't trying to write more bytes than
specified by the Content-Length header. The first try still contained an old
line that wrote the response, so the response was sent twice.
