##// END OF EJS Templates
exchangev2: fetch file revisions...
exchangev2: fetch file revisions Now that the server has an API for fetching file data, we can call into it to fetch file revisions. The implementation is relatively straightforward: we examine the manifests that we fetched and find all new file revisions referenced by them. We build up a mapping from file path to file nodes to manifest node. (The mapping to first manifest node allows us to map back to first changelog node/revision, which is used for the linkrev.) Once that map is built up, we iterate over it in a deterministic manner and fetch and store file data. The code is very similar to manifest fetching. So similar that we could probably extract the common bits into a generic function. With file data retrieval implemented, `hg clone` and `hg pull` are effectively feature complete, at least as far as the completeness of data transfer for essential repository data (changesets, manifests, files, phases, and bookmarks). We're still missing support for obsolescence markers, the hgtags fnodes cache, and the branchmap cache. But these are non-essential for the moment (and will be implemented later). This is a good point to assess the state of exchangev2 in terms of performance. I ran a local `hg clone` for the mozilla-unified repository using both version 1 and version 2 of the wire protocols and exchange methods. This is effectively comparing the performance of the wire protocol overhead and "getbundle" versus domain-specific commands. Wire protocol version 2 doesn't have compression implemented yet. So I tested version 1 with `server.compressionengines=none` to remove compression overhead from the equation. server before: user 220.420+0.000 sys 14.420+0.000 after: user 321.980+0.000 sys 18.990+0.000 client before: real 561.650 secs (user 497.670+0.000 sys 28.160+0.000) after: real 1226.260 secs (user 944.240+0.000 sys 354.150+0.000) We have substantial regressions on both client and server. This is obviously not desirable. I'm aware of some reasons: * Lack of hgtagsfnodes transfer (contributes significant CPU to client). * Lack of branch cache transfer (contributes significant CPU to client). * Little to no profiling / optimization performed on wire protocol version 2 code. * There appears to be a memory leak on the client and that is likely causing swapping on my machine. * Using multiple threads on the client may be counter-productive because Python. * We're not compressing on the server. * We're tracking file nodes on the client via manifest diffing rather than using linkrev shortcuts on the server. I'm pretty confident that most of these issues are addressable. But even if we can't get wire protocol version 2 on performance parity with "getbundle," I still think it is important to have the set of low level data-specific retrieval commands that we have implemented so far. This is because the existence of such commands allows flexibility in how clients access server data. Differential Revision: https://phab.mercurial-scm.org/D4491

File last commit:

r34952:fb7f58da stable
r39676:039bf1ed default
Show More
config.txt
108 lines | 3.1 KiB | text/plain | TextLexer
Boris Feld
internal-doc: document the config register mechanism...
r34933 All config options used within Mercurial should be registered.
Config Option in Core
=====================
Config options used by Mercurial core are registered in the
``mercurial.configitems`` module.
Simple entry
------------
A registration entry typically looks like::
coreconfigitem('section', 'option',
default=MyDefaultValue,
)
Once registered, Mercurial will know that ``section.option`` is a legitimate
config option and that ``MyDefaultValue`` should be used if no other values are
defined in configuration files.
Complex default value
---------------------
If the default provided is a callable, it is called to retrieve the default
Matt Harbison
help: minor copy editing for grammar
r34950 value when accessing the config option. This is useful for default values that
Boris Feld
internal-doc: document the config register mechanism...
r34933 are mutable like the empty list::
coreconfigitem('pager', 'ignore',
default=list,
)
In addition, there are cases where the default is not fixed, but computed from
Matt Harbison
help: minor copy editing for grammar
r34950 other properties. In this case, use the ``dynamicdefault`` object as the value
for the ``default`` parameter. A default value is then explicitly required when
Boris Feld
internal-doc: document the config register mechanism...
r34933 reading the option::
# registration
coreconfigitem('web', 'name',
default=dynamicdefault,
)
# usage
Matt Harbison
help: minor copy editing for grammar
r34950 ui.config('web', 'name', dirname)
Boris Feld
internal-doc: document the config register mechanism...
r34933
Free form options
-----------------
Some config sections use free form options (e.g. ``paths``). You can register
them using the ``generic`` parameters::
coreconfigitem('paths', '.*',
default=None,
generic=True,
)
When ``generic=True`` is set, the option name is matched as a regular expression
(rooted to string start). It can be used to select specific sub parameters::
coreconfigitem('merge-tools', br'.*\.args$',
default="$local $base $other",
generic=True,
priority=-1,
)
Matt Harbison
help: minor copy editing for grammar
r34950 The ``priority`` parameter controls the order used to match the generic pattern
Boris Feld
internal-doc: document the config register mechanism...
r34933 (lower first).
Config Option in Extensions
===========================
General case
------------
Extensions should register config items through the ``registrar`` API (also used
for commands and others)::
configtable = {}
configitem = registrar.configitem(configtable)
configitem('blackbox', 'dirty',
default=False,
)
The ``dynamicdefault`` object is then available as
``configitem.dynamicdefault``.
Matt Harbison
help: minor copy editing for grammar
r34950 Supporting older versions
-------------------------
Boris Feld
internal-doc: document the config register mechanism...
r34933
Kevin Bullock
internals: copy-edit "register" -> "registrar" in configitem docs
r34952 The registrar was introduced in Mercurial 4.3, and the ``generic`` parameter was
Boris Feld
internal-doc: document the config register mechanism...
r34933 introduced in 4.4. Starting with Mercurial 4.4, all core options were registered
and developer warnings are emitted when accessing unregistered option.
Matt Harbison
help: minor copy editing for grammar
r34950 Extensions supporting versions older than Mercurial 4.3 cannot rely on the
default value being registered. The simplest way to register an option while
still supporting an older version is to use ``dynamicdefault`` for options
requiring a default value. The existing code passing an explicit default can
then stay in use until compatibility with Mercurial 4.2 is dropped.
Boris Feld
internal-doc: document the config register mechanism...
r34933
Matt Harbison
help: minor copy editing for grammar
r34950 As reminder, here are the default values for each config type:
Boris Feld
internal-doc: document the config register mechanism...
r34933 - config: None
- configbool: False
- configbytes: 0
- configdate: None
- configint: None
- configlist: []
Matt Harbison
help: minor copy editing for grammar
r34950 - configpath: None