Gregory Szorc <gregory.szorc@gmail.com> [Mon, 05 Mar 2018 00:18:07 -0500] rev 36966
commands: don't check for merge.update() truthiness
AFAICT ``stats`` is always a tuple in these cases. We don't
need to check if the variable has a truthy value.
Differential Revision: https://phab.mercurial-scm.org/D2691
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 07 Mar 2018 19:57:50 -0800] rev 36965
httppeer: alias url as urlmod
"url" is a common variable name. We do this aliasing elsewhere to
avoid shadowing.
Differential Revision: https://phab.mercurial-scm.org/D2724
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Mar 2018 11:52:35 -0700] rev 36964
util: prefer "bytesio" to "stringio"
The io.BytesIO and io.StringIO types enforce the type of
data being operated on. On Python 2, we use cStringIO.StringIO(),
which is lax about mixing types. On Python 3, we actually use
io.BytesIO. Ideally, we'd use io.BytesIO on Python 2. But I believe
its performance is poor compared to cString.StringIO().
Anyway, we canonically define our pycompat type as "stringio."
That name is misleading, especially on Python 3.
This commit renames the canonical symbols to "bytesio."
"stringio" is preserved as an alias for API compatibility. There
are a lot of callers in the repo and I hesitate to take away the
old name. I also don't feel like changing everything at this time.
But at least new callers can use a "proper" name.
Differential Revision: https://phab.mercurial-scm.org/D2868
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 14:05:45 -0400] rev 36963
contrib: fix a subtle bug in check-code's regex rewriting
We rewrite `\s` to `[ \t]` when preparing our regular expressions, but
we previously weren't working to avoid having nested sets. Previously,
Python let this slide without incident, but in Python 3.7 wants to
make sure you meant an actual [ in a set, and so this warns. This
appears to be fortunate for us, because `[\s(]` was getting rewritten
to be `[[ \t](]` which doesn't actually match what we expected. See
preceding changes that were revealed to be necessary after
implementing this fix.
Differential Revision: https://phab.mercurial-scm.org/D2866
Augie Fackler <augie@google.com> [Tue, 13 Mar 2018 17:55:03 -0400] rev 36962
remotenames: work around move of ABCs in collections
This starts warning in Python 3.7, and will break in 3.8. The import
is performed in a curious place because `import collections.abc`
explodes badly on Python 2.7, and `from collections import abc` flunks
our import checker.
Differential Revision: https://phab.mercurial-scm.org/D2847
Anton Shestakov <av6@dwimlabs.net> [Mon, 26 Feb 2018 20:44:21 +0800] rev 36961
hgweb: explain instabilities of unstable changesets
Anton Shestakov <av6@dwimlabs.net> [Mon, 26 Feb 2018 20:44:01 +0800] rev 36960
debug: add debugwhyunstable that explains instabilities
This is a port of evolve's feature of listing all unstable changesets in detail
(`hg evolve --list`).
Anton Shestakov <av6@dwimlabs.net> [Tue, 13 Mar 2018 20:34:38 +0800] rev 36959
obsolete: move marker flags to obsutil
Evolve extension expects to have obsolete.bumpedfix (imported in
hgext3rd/evolve/evolvecmd.py), so we provide it.
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:21:10 +0100] rev 36958
debugupdatecache: also warm rev branch cache
We add basic code to have `debugupdatecache` ensure that the rev branch cache
is fully warmed. This only affects the `debugupdatecache` command, not normal
transaction operation.
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:16:56 +0100] rev 36957
debugbundle: do not display detailed part data in --quiet mode
This changeset makes `hg debugbundle` respect --quiet and only display data
about part headers.
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 15:44:53 -0400] rev 36956
tests: clean up two wayward `python` invocations
These are also fallout from the check-code regex rewriting bug.
Differential Revision: https://phab.mercurial-scm.org/D2865
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 15:42:23 -0400] rev 36955
contrib: open a hole in the open().read() ban for open().close()
It turns out open().close() is both fine and something we occasionally
do to verify something can be written. The few cases in the codebase
were getting missed due to a regular expression bug (which I discussed
in my previous change), but since I'm about to fix the bug, I need to
fix the patterns.
Differential Revision: https://phab.mercurial-scm.org/D2864
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 15:39:28 -0400] rev 36954
cleanup: fix some latent open(path).read() et al calls we previously missed
This pattern was banned by check-code way back in 1b4b82063ce2 (may of
2011), but due to a regular expression rewriting bug in check-code
these particular callsites were never detected. Python 3.7 caught the
bug, which then exposed these errors.
Differential Revision: https://phab.mercurial-scm.org/D2863
Martin von Zweigbergk <martinvonz@google.com> [Wed, 14 Mar 2018 11:16:45 -0700] rev 36953
uncommit: fix unaligned indentation
Differential Revision: https://phab.mercurial-scm.org/D2861
Boris Feld <boris.feld@octobus.net> [Fri, 09 Mar 2018 18:39:48 +0100] rev 36952
util: clear debugstacktrace call
During the renaming of datestr, it seems that I have forget a debugstacktrace
in util.py. Remove it.
Differential Revision: https://phab.mercurial-scm.org/D2838
Boris Feld <boris.feld@octobus.net> [Mon, 05 Mar 2018 11:48:28 -0500] rev 36951
peer-request: include more details about batch commands
A batch commands encapsulate multiple other commands. We display a bit more
details about what is actually batched if peer request tracking is set.
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 15:56:34 -0400] rev 36950
tests: fix test-wireproto.py to work around serverrepo() not having a ui
This started failing recently, but it doesn't look important as no
actual ui objects have been in play.
Differential Revision: https://phab.mercurial-scm.org/D2867
Augie Fackler <augie@google.com> [Tue, 13 Mar 2018 22:53:49 -0400] rev 36949
tests: add a cat of `error.log` in subrepo test
This made some debugging a lot less painful when something was broken,
and it costs us almost nothing, so I figure we may as well leave it
in.
Differential Revision: https://phab.mercurial-scm.org/D2853
Augie Fackler <augie@google.com> [Tue, 13 Mar 2018 18:13:37 -0400] rev 36948
hghave: fix hardlink-whitelisted check on Python 3
Differential Revision: https://phab.mercurial-scm.org/D2846
Augie Fackler <augie@google.com> [Tue, 13 Mar 2018 18:05:49 -0400] rev 36947
hghave: fix xdiff check on Python 3
Differential Revision: https://phab.mercurial-scm.org/D2845
Augie Fackler <augie@google.com> [Tue, 13 Mar 2018 18:04:37 -0400] rev 36946
commandserver: prefer first-party selectors module from Python 3 to backport
Caught by some deprecation warnings on Python 3.7.
Differential Revision: https://phab.mercurial-scm.org/D2844
Sushil khanchi <sushilkhanchi97@gmail.com> [Sat, 10 Mar 2018 12:33:19 +0530] rev 36945
forget: add --dry-run mode
Boris Feld <boris.feld@octobus.net> [Fri, 09 Mar 2018 15:53:41 +0100] rev 36944
push-discovery: extract the bookmark comparison logic in its own function
This will help extensions to alter the behavior as they see fit.
Boris Feld <boris.feld@octobus.net> [Fri, 09 Mar 2018 16:31:35 +0100] rev 36943
push-discovery: don't turn use generator when comparing bookmarks
We want extensions to be able to implement their own logic. Generators can be
consume only once, impractical for this purpose.
Jun Wu <quark@fb.com> [Tue, 13 Mar 2018 16:56:13 -0700] rev 36942
xdiff: move stdint.h to xdiff.h
It's more correct to put it in xdiff.h since that file actually uses int64_t
etc and xdiff.h is included by xinclude.h.
This should fix the oss-fuzz build. Thanks durin42 for discovering the
issue.
Test Plan:
`make local` and xdiff related tests still work.
Differential Revision: https://phab.mercurial-scm.org/D2848
Yuya Nishihara <yuya@tcha.org> [Mon, 12 Mar 2018 20:37:08 +0900] rev 36941
annotate: correct parameter name of decorate() function
Yuya Nishihara <yuya@tcha.org> [Tue, 13 Mar 2018 21:22:14 +0900] rev 36940
pycompat: name maplist() and ziplist() for better traceback message
Martin von Zweigbergk <martinvonz@google.com> [Sun, 04 Mar 2018 09:07:06 -0800] rev 36939
rebase: move constant expressions out of inner loop in _performrebase()
Differential Revision: https://phab.mercurial-scm.org/D2811
Martin von Zweigbergk <martinvonz@google.com> [Fri, 02 Mar 2018 15:38:20 -0800] rev 36938
rebase: inline _performrebasesubset()
Now that most of _performrebasesubset() has been moved into
_rebasenode(), it's simple enough that we can inline it.
Differential Revision: https://phab.mercurial-scm.org/D2810
Martin von Zweigbergk <martinvonz@google.com> [Mon, 12 Mar 2018 10:39:42 -0700] rev 36937
rebase: extract function for rebasing a single node
We currently have _performrebase() and _performrebasesubset(), but we
don't have a method for rebasing a single node (that's inside a loop
in _performrebasesubset()). I think it makes sense to have such a
method, so that's what this patch does. I think it may simplify future
patches I'm working on that have to do with transactions, but I think
this patch makes sense on its own whether or not that future work
happens.
Differential Revision: https://phab.mercurial-scm.org/D2809
Martin von Zweigbergk <martinvonz@google.com> [Fri, 09 Mar 2018 12:48:00 -0800] rev 36936
rebase: use configoverride context manager for ui.forcemerge
Differential Revision: https://phab.mercurial-scm.org/D2761
Martin von Zweigbergk <martinvonz@google.com> [Fri, 09 Mar 2018 12:45:50 -0800] rev 36935
rebase: also restore "ui.allowemptycommit" value
It looks like this was lost when the code was converted to the
ui.configoverride() context manager in f255b1811f5e (rebase: get rid
of ui.backupconfig, 2017-03-16). (And then the bad example was
duplicated in 228916ca12b5 (rebase: add concludememorynode(), and call
it when rebasing in-memory, 2017-12-07).)
Differential Revision: https://phab.mercurial-scm.org/D2760
Martin von Zweigbergk <martinvonz@google.com> [Thu, 08 Mar 2018 14:17:24 -0800] rev 36934
rebase: fix issue 5494 also with --collapse
Differential Revision: https://phab.mercurial-scm.org/D2759
Martin von Zweigbergk <martinvonz@google.com> [Fri, 09 Mar 2018 10:35:48 -0800] rev 36933
rebase: also include commit of collapsed commits in single transaction
When rebase.singletransaction is set, we still used to create a second
transaction when committing with --collapse. It's simpler to create a
single transaction.
Note that in the affected .t file, the test that uses --collapse still
appears to create two transactions (it prints "rebase status stored"
twice). However, only a single transaction is actually created and the
second printout comes from cmdutil.commitforceeditor() that explicitly
calls tr.writepending().
Also note the that we now roll back any commits if the user closes the
commit message editor with an error code (or leaves the message
empty). That might be unfortunate, but it's consistent with how we
behave in the --no-collapse case (if the user passed --edit). If we
want to change that, I think it should be done consistently in a
separate patch.
Differential Revision: https://phab.mercurial-scm.org/D2728
Matt Harbison <matt_harbison@yahoo.com> [Mon, 12 Mar 2018 23:08:47 -0400] rev 36932
lfs: debug print HTTP headers and JSON payload received from the server
This has been extremely valuable to show divergences between `hg serve` and
`lfs-test-server`. Once the `hg serve` code lands, there will be a certain
amount of conditionalizing that needs to be done, because `lfs-test-server`
doesn't always follow its spec.
The $ISO_8601_DATE_TIME$ pattern masks the fact that `lfs-test-serve` is sending
out an expires_at value of "0001-01-01T00:00:00Z". `hg serve` will (probably)
use current time + 10 minutes or similar. The $HTTP_DATE$ is the current time.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 12 Mar 2018 22:30:01 -0400] rev 36931
test-lfs: dial up the debugging on commands that interact with the server
This will be useful to let the client print out the HTTP headers and JSON in a
future patch, so we can compare native LFS serving against test-lfs-server
behavior. There tends to be a lot of debug stuff that we don't care about here
in a push, so I was tempted to print this output with a [devel] config. But
this will be useful for field debugging too, so just put up with the extra
output here.
It would have been nice to be able to set ui.debug once, but issue5815 prevents
that.
Matt Harbison <matt_harbison@yahoo.com> [Sat, 24 Feb 2018 15:12:01 -0500] rev 36930
tests: add a substitution pattern for dates in HTTP headers and LFS payload
This will be useful when printing HTTP headers and JSON payload received from an
LFS server. The RFC 1123 date masking has uses elsewhere too.
Matt Harbison <matt_harbison@yahoo.com> [Mon, 12 Mar 2018 21:50:18 -0400] rev 36929
xdiff: fix a hard crash on Windows
The xdiff case of test-diff-antipatience.t started crashing in the C extension
with 882657a9f768 (with 6a71a5ba666b backported so it compiles). There are a
few more instances of 'long', but this resolves the crashing.
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Mar 2018 22:23:02 +0900] rev 36928
templater: split template functions to new module
It has grown enough to be a dedicated module.
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Mar 2018 23:15:09 +0900] rev 36927
templater: move hybrid class and functions to templateutil module
And make _hybrid and _mappable classes public. _showlist() is still marked
as private since it's weird and third-party codes shouldn't depend on it.
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Mar 2018 23:10:46 +0900] rev 36926
templater: move stringify() to templateutil module
As we have a util module, it doesn't make sense to import stringify() from
templatefilters.py.
Yuya Nishihara <yuya@tcha.org> [Wed, 28 Feb 2018 15:20:41 -0500] rev 36925
dagop: move lines() out of annotate()
Yuya Nishihara <yuya@tcha.org> [Wed, 28 Feb 2018 15:19:47 -0500] rev 36924
dagop: extract core algorithm of annotate() from context.py
See the previous patch for why.
Yuya Nishihara <yuya@tcha.org> [Wed, 28 Feb 2018 15:09:05 -0500] rev 36923
dagop: move annotateline and _annotatepair from context.py
The annotate logic is large. Let's move it out of the context module, which
is basically an abstraction layer of repository operations.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 09 Mar 2018 21:59:07 -0500] rev 36922
bdiff: convert more longs to int64_t
MSVC previously flagged these where the function is stored in a pointer:
bdiff.c(284) : warning C4028: formal parameter 1 different from declaration
bdiff.c(284) : warning C4028: formal parameter 2 different from declaration
bdiff.c(284) : warning C4028: formal parameter 3 different from declaration
bdiff.c(284) : warning C4028: formal parameter 4 different from declaration
Matt Harbison <matt_harbison@yahoo.com> [Fri, 09 Mar 2018 21:42:33 -0500] rev 36921
xdiff: silence a 32-bit shift warning on Windows
It's probably harmless, but:
warning C4334: '<<' : result of 32-bit shift implicitly converted to 64 bits
(was 64-bit shift intended?)
Adding a 'ULL' suffix to 1 also works, but I doubt that's portable.
Matt Harbison <matt_harbison@yahoo.com> [Fri, 09 Mar 2018 21:31:57 -0500] rev 36920
xdiff: backport int64_t and uint64_t types to Windows
Sadly, MSVC 2008 lacks stdint.h. These are the only two definitions needed
right now.
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Mar 2018 22:33:24 +0900] rev 36919
templater: extract template evaluation utility to new module
Prepares for splitting template functions to new module.
All eval* functions were moved to templateutil.py, and run* functions had to
be moved as well due to the dependency from eval*s. eval*s were aliased as
they are commonly used in codebase. _getdictitem() had to be made public.
Yuya Nishihara <yuya@tcha.org> [Thu, 08 Mar 2018 22:20:36 +0900] rev 36918
templater: move function table to the "context" object
Prepares for splitting template functions from templater.py.
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 16:29:54 -0700] rev 36917
hgweb: remove wsgirequest (API)
Good riddance.
.. api::
The old ``wsgirequest`` class for handling everything WSGI in hgweb
has been replaced by separate request and response types. Various
high-level functions in the hgweb WSGI applications now receive
these new types as arguments instead of the old ``wsgirequest``
type.
Differential Revision: https://phab.mercurial-scm.org/D2832
Pulkit Goyal <7895pulkit@gmail.com> [Sat, 10 Mar 2018 15:24:24 +0530] rev 36916
tweakdefaults: add commands.status.verbose to tweakefaults
commands.status,verbose if set to True, shows conflict information in `hg
status`. It shows which unresolved state you are in, which are the unresolved
files and how to continue the unresolved state. That sounds like a very good
candidate for tweakdefaults.
bisect is added to commands.status.skipstates because people generally leave
unresolved bisect state and we should skip that in morestatus output.
Differential Revision: https://phab.mercurial-scm.org/D2806
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 16:19:20 -0700] rev 36915
hgweb: store the raw WSGI environment dict
We need this so we can construct a new request instance
from the original dict.
Differential Revision: https://phab.mercurial-scm.org/D2831
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:55:38 -0700] rev 36914
hgweb: remove dead wsgirequest code
All responses now go through our modern response type. All code related
to response handling can be deleted.
Differential Revision: https://phab.mercurial-scm.org/D2830
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:40:58 -0700] rev 36913
hgweb: port to new response API
These were the last consumers of wsgirequest.respond() \o/
Differential Revision: https://phab.mercurial-scm.org/D2829
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:35:03 -0700] rev 36912
hgweb: pass modern request type into templater()
Only a handful of consumers of wsgirequest remaining in this
file...
Differential Revision: https://phab.mercurial-scm.org/D2828
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:37:59 -0700] rev 36911
hgweb: use modern response type for index generation
Differential Revision: https://phab.mercurial-scm.org/D2827
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:29:38 -0700] rev 36910
hgweb: don't pass wsgireq to makeindex and other functions
We only ever access attributes that are available on our newer
request type. So we no longer need this argument.
Differential Revision: https://phab.mercurial-scm.org/D2826
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:18:29 -0700] rev 36909
hgweb: replace PATH_INFO with dispatchpath
This was the last consumer of wsgireq.env from our WSGI applications!
(Although indirect consumers of this attribute exist in
wsgirequest.respond().)
Differential Revision: https://phab.mercurial-scm.org/D2825
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:15:02 -0700] rev 36908
hgweb: rewrite path generation for index entries
I think this code is easier to read. But the real reason to do this
is to eliminate a consumer of wsgirequest.
Differential Revision: https://phab.mercurial-scm.org/D2824
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:08:36 -0700] rev 36907
hgweb: construct {url} with req.apppath
This is how the hgweb WSGI application does it. Let's make the
behavior consistent.
Differential Revision: https://phab.mercurial-scm.org/D2823
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:33:56 -0700] rev 36906
hgweb: support constructing URLs from an alternate base URL
The web.baseurl config option allows server operators to define a
custom URL for hosted content.
The way it works today is that hgwebdir parses this config
option into URL components then updates the appropriate
WSGI environment variables so the request "lies" about its
details. For example, SERVER_NAME is updated to reflect the
alternate base URL's hostname.
The WSGI environment should not be modified because WSGI
applications may want to know the original request details (for
debugging, etc).
This commit teaches our request parser about the existence of
an alternate base URL. If defined, the advertised URL and other
self-reflected paths will take the alternate base URL into account.
The hgweb WSGI application didn't use web.baseurl. But hgwebdir
did. We update hgwebdir to alter the environment parsing
accordingly. The old code around environment manipulation
has been removed.
With this change, parserequestfromenv() has grown to a bit
unwieldy. Now that practically everyone is using it, it is
obvious that there is some unused features that can be trimmed.
So look for this in follow-up commits.
Differential Revision: https://phab.mercurial-scm.org/D2822
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 13:55:13 -0700] rev 36905
hgweb: clarify that apppath begins with a forward slash
Differential Revision: https://phab.mercurial-scm.org/D2821
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 13:38:56 -0700] rev 36904
hgweb: change how dispatch path is reported
When I implemented the new request object, I carried forward some
ugly hacks until I could figure out what was happening. One of those
was the handling of PATH_INFO to determine how to route hgweb
requests.
Essentially, if we have PATH_INFO data, we route according to
that. But if we don't, we route by the query string. I question
if we still need to support query string routing. But that's for
another day, I suppose.
In this commit, we clean up the ugly "havepathinfo" hack and
replace it with a "dispatchpath" attribute that can hold None or
empty string to differentiate between the presence of PATH_INFO.
This is still a bit hacky. But at least the request parsing
and routing code is explicit about the meaning now.
Differential Revision: https://phab.mercurial-scm.org/D2820
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 13:11:13 -0700] rev 36903
hgweb: refactor repository name URL parsing
The hgwebdir WSGI application detects when a requested URL is for
a known repository and it effectively forwards the request to the
hgweb WSGI application.
The hgweb WSGI application needs to route the request based on the
base URL for the repository. The way this normally works is
SCRIPT_NAME is used to resolve the base URL and PATH_INFO
contains the path after the script.
But with hgwebdir, SCRIPT_NAME refers to hgwebdir, not the base
URL for the repository. So, there was a hacky REPO_NAME environment
variable being set to convey the part of the URL that represented
the repository so hgweb could ignore this path component for
routing purposes.
The use of the environment variable for passing internal state
is pretty hacky. Plus, it wasn't clear from the perspective of
the URL parsing code what was going on.
This commit improves matters by making the repository name an
explicit argument to the request parser. The logic around
handling of this value has been shored up. We add various checks
that the argument is used properly - that the repository name
does represent the prefix of the PATH_INFO.
Differential Revision: https://phab.mercurial-scm.org/D2819
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 12:53:47 -0700] rev 36902
tests: add test coverage for parsing WSGI requests
A subsequent commit will need to make this code more complicated
in order to support alternate base URLs. Let's establish some test
coverage before we diverge too far from PEP 3333.
As part of this, a minor bug related to a missing SCRIPT_NAME
key has been squashed.
Differential Revision: https://phab.mercurial-scm.org/D2818
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 10:51:14 -0700] rev 36901
hgweb: construct static URL like hgweb does
hgwebdir has a bit of code for constructing URLs. This reinvents wheels
from our parsedrequest instance. And sometimes the behavior varies
from what hgweb does. We'll want to converge that behavior.
This commit changes hgwebdir so its staticurl template keyword
is constructed the same way as hgweb's. There's probably room
to factor this into a shared function. But let's solve the
problem of divergence first.
Differential Revision: https://phab.mercurial-scm.org/D2817
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 10:38:46 -0700] rev 36900
hgweb: remove unused **map argument
It was unused before the recent code refactoring AFAICT.
Differential Revision: https://phab.mercurial-scm.org/D2816
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 10:37:25 -0700] rev 36899
hgweb: extract entries() to standalone function
There was some real wonkiness going on here. Essentially, the
inline function was being executed with default arguments because
a function reference was passed as-is into the templater. That
seemed odd. So now we pass an explicit generator of the function
result.
Moving this code out of makeindex() makes makeindex() small enough
to reason about. This makes it easier to see weird things, like the
fact that we're calling self.refresh() twice. Why, I'm not sure.
I'm also not sure why we need to call updatereqenv() to possibly
update the SERVER_NAME, SERVER_PORT, and SCRIPT_NAME variables as
part of rendering an index. I'll dig into these things in subsequent
commits.
Differential Revision: https://phab.mercurial-scm.org/D2815
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 10:24:46 -0700] rev 36898
hgweb: move rawentries() to a standalone function
It was only accessing a few variables from the outer scope. Let's
make it standalone so there is better clarity about what the inputs
are.
Differential Revision: https://phab.mercurial-scm.org/D2814
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 10:17:58 -0700] rev 36897
hgweb: move archivelist to standalone function
This doesn't need to exist as an inline function in a method.
Minor formatting changes were made as part of the move.
Differential Revision: https://phab.mercurial-scm.org/D2813
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 10:15:33 -0700] rev 36896
hgweb: move readallowed to a standalone function
hgwebdir s kind of large. Let's make the class smaller by
moving things that don't need to be there.
Differential Revision: https://phab.mercurial-scm.org/D2812
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 11 Mar 2018 15:51:13 -0700] rev 36895
hgweb: remove some use of wsgireq in hgwebdir
While we're here, rename a method so abide by our style policy,
since otherwise check-commit would complain.
Differential Revision: https://phab.mercurial-scm.org/D2805
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:54:44 -0800] rev 36894
hgweb: fix a bug due to variable name typo
It looks like the "sort" query string parameter was not being
honored properly.
Differential Revision: https://phab.mercurial-scm.org/D2804
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:51:46 -0800] rev 36893
hgweb: stop passing req and tmpl into @webcommand functions (API)
We have effectively removed all consumers of the old wsgirequest
type. The templater can be accessed on the requestcontext passed
into the @webcommand function.
For the most part, these arguments are unused. They only exist to
provide backwards compatibility. And in the case of wsgirequest,
use of that object could actively interfere with the new request
object.
So let's stop passing these objects to @webcommand functions.
With this commit, wsgirequest is practically dead from the hgweb
WSGI application. There are still some uses in hgwebdir though...
.. api::
@webcommand functions now only receive a single argument. The
request and templater instances can be accessed via the
``req`` and ``templater`` attributes of the first argument.
Note that the request object is different from previous Mercurial
releases and consumers of the previous ``req`` 2nd argument
will need updating to use the new API.
Differential Revision: https://phab.mercurial-scm.org/D2803
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 19:57:08 -0800] rev 36892
hgweb: pass modern request type into various webutil functions (API)
Our march towards killing wsgirequest continues.
.. api::
Various functions in hgweb.webutil now take a modern request
object instead of ``wsgirequest``.
Differential Revision: https://phab.mercurial-scm.org/D2802
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 19:46:54 -0800] rev 36891
hgweb: don't redundantly pass templater with requestcontext (API)
The requestcontenxt has a ``tmpl`` attribute to access the
templater. We don't need to pass the templater explicitly when
passing a requestcontext instance.
.. api::
Various helper functions in hgweb.webutil no longer accept a
templater instance. Access the templater through the
``web`` argument instead.
Differential Revision: https://phab.mercurial-scm.org/D2801
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:38:28 -0800] rev 36890
hgweb: use templater on requestcontext instance
After this commit, all @webcommand function no longer use their
"tmpl" argument. Instead, they use the templater attached to the
requestcontext.
This is the same exact object. So there should be no difference in
behavior.
Differential Revision: https://phab.mercurial-scm.org/D2800
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 19:41:18 -0800] rev 36889
hgweb: add a sendtemplate() helper function
This pattern is common. Let's make a helper function to reduce
boilerplate.
We store the "global" template on the requestcontext instance and
use it. The templater used by the helper function is the same
templater that's passed in as an argument to the @webcommand
functions. It needs to be this way because various commands are
accessing and mutating the defaults on the templater instance.
Differential Revision: https://phab.mercurial-scm.org/D2799
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 19:11:41 -0800] rev 36888
hgweb: use web.req instead of req.req
We now have access to the modern request type on the
requestcontext instance. Let's access it from there.
While we're here, remove an unused argument from _search().
Differential Revision: https://phab.mercurial-scm.org/D2798
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 19:08:58 -0800] rev 36887
hgweb: stop setting headers on wsgirequest
All commands now go through the new response API. This is dead code.
Differential Revision: https://phab.mercurial-scm.org/D2797
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:35:35 -0800] rev 36886
hgweb: always return iterable from @webcommand functions (API)
We had to hack up this function to support our transition to the
new response API. Now that we're done with the transition (!!),
we can return to returning an iterator of content chunks from
these functions.
It is tempting to return a normal object and not a generator.
However, as the keyword extension demonstrates, extensions may
wish to wrap commands and have a try..finally block around
execution. Since there is a generator producing content and
that generator could be executing code, the try..finally needs
to live for as long as the generator is running. That means we
have to return a generator so wrappers can consume the generator
inside a try..finally.
.. api::
hgweb @webcommand functions must use the new response object
passed in via ``web.res`` to initiate sending of a response.
The hgweb WSGI application will no longer start sending the
response automatically.
Differential Revision: https://phab.mercurial-scm.org/D2796
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 18:51:32 -0800] rev 36885
hgweb: send errors using new response API
Our slow march off of wsgirequest continues.
Differential Revision: https://phab.mercurial-scm.org/D2795
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 18:42:00 -0800] rev 36884
hgweb: refactor 304 handling code
We had generic code in wsgirequest for handling HTTP 304 responses.
We also had a special case for it in the catch all exception handler
in the WSGI application.
We only ever raise 304 in one place. So, we don't need to treat it
specially in the catch all exception handler.
But it is useful to validate behavior of 304 responses. We port the
code that sends a 304 to use the new response API. We then move the
code for screening 304 sanity into the new response API.
As part of doing so, we discovered that we would send
Content-Length: 0. This is not allowed. So, we fix our response code
to not emit that header for empty response bodies.
Differential Revision: https://phab.mercurial-scm.org/D2794
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 18:19:27 -0800] rev 36883
hgweb: transition permissions hooks to modern request type (API)
We're trying to remove ``wsgirequest``. The permissions hooks don't
do anything they can't do with our new request type. So let's
pass that in.
This was the last use of ``wsgirequest`` in the wire protocol code!
.. api::
hgweb.hgweb_mod.permhooks no longer take a ``wsgirequest`` instance
as an argument.
Differential Revision: https://phab.mercurial-scm.org/D2793
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:16:20 -0800] rev 36882
hgweb: port archive command to modern response API
Well, I tried to go with PEP 3333's recommendations and only allow
our WSGI application to emit data via a response generator.
Unfortunately, the "archive" command calls into the zipfile and
tarfile modules and these operator on file objects and must send
their data to an object with write(). There's no easy way turn
these write() calls into a generator.
So, we teach our response type how to expose a file object like
object that can be used to write() output. We try to keep the API
consistent with how things work currently: callers must call a
setbody*(), then sendresponse() to trigger sending of headers,
and only then can they get a handle on the object to perform
writing.
This required overloading the return value of @webcommand functions
even more. Fortunately, we're almost completely ported off the
legacy API. So we should be able to simplify matters in the near
future.
A test relying on this functionality has also been updated to use
the new API.
Differential Revision: https://phab.mercurial-scm.org/D2792
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 16:17:51 -0800] rev 36881
hgweb: refactor fake file object proxy for archiving
Python's zip file writer operates on a file object. When doing work,
it periodically calls write(), flush(), and tell() on that object.
In WSGI contexts, the start_response function returns a write()
function. That's a function to write data, not a full file object.
So, when the archival code was first introduced in 2b03c6733efa in
2006, someone invented a proxy "tellable" type that wrapped a file
object like object and kept track of write count so it could
implement tell() and satisfy zipfile's needs.
When our archival code runs, it attempts to tell() the destination
and if that fails, converts it to a "tellable" instance. Our WSGI
application passes the "wsgirequest" instance to the archival
function. It fails the tell() test and is converted to a "tellable."
It's worth noting that "wsgirequest" implements flush(), so
"tellable" doesn't.
This hackery all seems very specific to the WSGI code. So this commit
moves the "tellable" type and the conversion of the destination file
object into the WSGI code. There's a chance some other caller may be
passing a file object like object that doesn't implement tell(). But
I doubt it.
As part of the refactor, our new type implements flush() and doesn't
implement __getattr__. Given the intended limited use of this type,
I want things to fail fast if there is an attempt to access attributes
because I think it is important to document which attributes are being
used for what purposes.
Differential Revision: https://phab.mercurial-scm.org/D2791
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 16:27:01 -0800] rev 36880
tests: additional test coverage of archive web command
This command is special in a few ways. First, it is the only command
using the write() function from WSGI's start_response() function.
Second, it is setting a custom content-disposition header.
We change the test so it prints out full details of the HTTP
response. We also save the response body to a file so we can
verify its size and hash. The hash check will help ensure that
archive generation is deterministic.
Differential Revision: https://phab.mercurial-scm.org/D2790
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 15:46:29 -0800] rev 36879
hgweb: port static file handling to new response API
hgwebdir_mod hasn't received as much porting effort. So we had to
do some minor plumbing to get it to match hgweb_mod and to support
the new response object.
Differential Revision: https://phab.mercurial-scm.org/D2789
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 15:37:29 -0800] rev 36878
hgweb: remove one-off routing for file?style=raw
Now that both functions are using the same API, we can unify how
the command is called and perform command-specific behavior in the
command itself instead of in the high-level router.
Differential Revision: https://phab.mercurial-scm.org/D2788
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 20:36:34 -0800] rev 36877
hgweb: port most @webcommand to use modern response type
This only focused on porting the return value.
raw file requests are wonky because they go through a separate code
path at the dispatch layer. Now that everyone is using the same
API, we could clean this up.
It's worth noting that wsgirequest.respond() allows sending the
Content-Disposition header, but the only user of that feature was
removed as part of this change (with the setting of the header
now being performed inline).
A few @webcommand are not as straightforward as the others and
they have not been ported yet.
Differential Revision: https://phab.mercurial-scm.org/D2787
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 17:02:57 -0800] rev 36876
hgweb: support using new response object for web commands
We have a "requestcontext" type for holding state for the current
request. Why we pass in the wsgirequest and templater instance
to @webcommand functions, I don't know.
I like the idea of standardizing on using "requestcontext" for passing
all state to @webcommand functions because that scales well without
API changes every time you want to pass a new piece of data. So,
we add our new request and response instances to "requestcontext" so
@webcommand functions can access them.
We also teach our command dispatcher to recognize a new calling
convention. Instead of returning content from the @webcommand
function, we return our response object. This signals that this
response object is to be used for sending output. The keyword
extension was wrapping various @webcommand and assuming the output
was iterable, so we had to teach it about the new calling convention.
To prove everything works, we convert the "filelog" @webcommand
to use the new convention.
The new calling convention is a bit wonky. I intend to improve this
once all commands are ported to use the new response object.
Differential Revision: https://phab.mercurial-scm.org/D2786
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 14:19:27 -0800] rev 36875
hgweb: inline caching() and port to modern mechanisms
We only had one consumer of this simple function. While it could be
a generic function, let's not over abstract the code.
As part of inlining, we port it off wsgirequest, fix some Python 3
issues, and set a response header on our new response object so it
is ready once we start using it to send responses.
Differential Revision: https://phab.mercurial-scm.org/D2785
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 14:06:58 -0800] rev 36874
hgweb: expose repo name on parsedrequest
I'm not a fan of doing this because I want to find a better solution to
the REPO_NAME hack. But this change gets us a few steps closer to
eliminating use of wsgirequest. We can worry about fixing REPO_NAME
once wsgirequest is gone.
Differential Revision: https://phab.mercurial-scm.org/D2784
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 14:00:40 -0800] rev 36873
hgweb: expose URL scheme and REMOTE_* attributes
These are consulted by the HTTP wire protocol handler by reading from
the env dict. Let's expose them as attributes instead.
With the wire protocol handler updates to use the new attributes, we
no longer have any consumers of the legacy wsgirequest type in the
wire protocol code (outside of a proxied call to the permissions
checker). So, we remove most references to it.
Differential Revision: https://phab.mercurial-scm.org/D2783
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 12:31:11 -0800] rev 36872
hgweb: remove wsgirequest.form (API)
Now that everything is ported to consume from parsedrequest.qsparams,
we no longer have a need for wsgirequest.form. Let's remove all
references to it.
.. api::
The WSGI request object no longer exposes a ``form`` attribute
containing parsed query string data. Use the ``qsparams`` attribute
instead.
Differential Revision: https://phab.mercurial-scm.org/D2782
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 10 Mar 2018 12:36:36 -0800] rev 36871
hgweb: perform all parameter lookup via qsparams
I think I managed to update all call sites using wsgirequest.form
to use parsedrequest.qsparams.
Since behavior of qsparams is to retrieve last value, behavior will
change if a parameter was specified multiple times. But I think this
is acceptable.
I'm not a fan of the `req.req.qsparams` pattern. And some of the
modified code could be written better. But I was aiming for a
straight port with this change. Cleanup can come later.
Differential Revision: https://phab.mercurial-scm.org/D2781