Wed, 16 Sep 2015 22:30:36 +0800 highlight: add highlightfiles config option which takes a fileset (issue3005)
Anton Shestakov <av6@dwimlabs.net> [Wed, 16 Sep 2015 22:30:36 +0800] rev 26249
highlight: add highlightfiles config option which takes a fileset (issue3005) Highlight extension lacked a way to limit files by size, by extension, and/or by any other part of file path. A good solution would be to use a fileset, since it can check file path, extension and size (and more) in one expression. So this change introduces such an option, highlighfiles, which takes a fileset and on each request decides if the requested file should be highlighted. The default "size('<5M')" is, in a way, suggested in issue3005. checkfctx() limits the amount of work to just one file (subset kwarg in fileset.matchctx()). Monkey-patching works around issue4568, otherwise using filesets here while running hgweb in directory mode would say, for example, "Abort: **.py not under root", but this fix is very local and probably far from ideal. I suspect there to be a way to fix this for the whole hgweb and resolve the issue, but I don't know how to do it.
Fri, 04 Sep 2015 11:15:02 -0400 posix: shellquote do not require quoting for "+" (issue4818)
timeless@mozdev.org [Fri, 04 Sep 2015 11:15:02 -0400] rev 26248
posix: shellquote do not require quoting for "+" (issue4818)
Sat, 12 Sep 2015 12:16:39 -0700 hgweb: consume generator inside context manager (issue4756)
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 12 Sep 2015 12:16:39 -0700] rev 26247
hgweb: consume generator inside context manager (issue4756) If code inside a context manager returns a generator, the context manager exits before the generator is iterated. hgweb was using a context manager to control thread safe access to a localrepository instance. But it was returning a generator, so there was a race condition between a previous request streaming a response to the client and a new request obtaining the released but in use repository. By iterating the generator inside the context manager, we ensure we don't release the repo instance until after the response has finished. With this change, hgweb finally appears to have full localrepository isolation between threads. I can no longer reproduce the 2 exceptions reported in issue4756. test-hgweb-non-interactive.t has been modified to consume the output of calling into a WSGI application. Without this, execution of the WSGI application stalls because of the added yield statement.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip