httprepo: long arguments support (
issue2126)
Send the command arguments in the HTTP headers. The command is still part
of the URL. If the server does not have the 'httpheader' capability, the
client will send the command arguments in the URL as it did previously.
Web servers typically allow more data to be placed within the headers than
in the URL, so this approach will:
- Avoid HTTP errors due to using a URL that is too large.
- Allow Mercurial to implement a more efficient wire protocol.
An alternate approach is to send the arguments as part of the request body.
This approach has been rejected because it requires the use of POST
requests, so it would break any existing configuration that relies on the
request type for authentication or caching.
Extensibility:
- The header size is provided by the server, which makes it possible to
introduce an hgrc setting for it.
- The client ignores the capability value after the first comma, which
allows more information to be included in the future.
store: rename the 'opener' argument to 'openertype'
The 'opener' argument wasn't, in fact, an actual opener instance, but
rather something expected to return an opener. The normal argument,
from localrepository, is the scmutil.opener type; hence 'openertype'.
opener: introduce an abstact superclass of it
Currently, this class doesn't do anything useful.
graphlog: use a set for inclusion test
This makes a big difference in performance in the special case where all
revisions are being graphed.
graphmod: restore generator nature of dagwalker
9966c95b8c4f introduced the ability to walk the DAG
given arbitrary revisions, but changed the behaviour of
it to return a list of all nodes (and create a changectx
for each one) rather than doing it lazily.
This has a pretty significant impact on performance for large
repositories (tested on CPython repo, with output disabled):
$ time hg glog
real 0m2.642s
user 0m2.560s
sys 0m0.080s
Before
9966c95b8c4f:
$ time hg glog
real 0m0.143s
user 0m0.112s
sys 0m0.032s
And after this fix:
$ time hg glog
real 0m0.213s
user 0m0.184s
sys 0m0.028s
graphlog: log -G --follow file does not work, forbid it
We do not have revsets to follow file history.
graphlog: fix log -G --prune
follow() revset really means '::.' while we want something based on the passed
argument. Also, ancestors() revset does not include the parent revisions.