http: minor tweaks to long arg handling x-arg -> x-hgarg replace itertools.count(1)

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'.

statichttprepo: make the opener a subclass of abstractopener

add filteropener abstraction for store openers

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: unify log -G revset translation

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.

graphlog: escape log -G single value option arguments

graphlog: fix log -G --removed Current version was mispelled and processed like a valued argument.

graphlog: fix log -G option types when translating to revset For instance, --keyword is a multiple value option while it was processed as a single value option.

revset: add tests for multiple and mixed ^ and ~ operators

extensions: obsolete and remove parentrevspec extension As of 305c97670d7a, revsets implements the ^ and ~ operators that this extension provides, so it's no longer necessary.