view mercurial/help/internals/config.txt @ 40178:46a40bce3ae0

wireprotov2: define and implement "filesdata" command

Previously, the only way to access file revision data was the
"filedata" command. This command is useful to have. But, it only
allowed resolving revision data for a single file. This meant that
clients needed to send 1 command for each tracked path they were
seeking data on. Furthermore, those commands would need to enumerate
the exact file nodes they wanted data for.

This approach meant that clients were sending a lot of data to
remotes in order to request file data. e.g. if there were 1M
file revisions, we'd need at least 20,000,000 bytes just to encode
file nodes! Many clients on the internet don't have that kind of
upload capacity.

In order to limit the amount of data that clients must send, we'll
need more efficient ways to request repository data.

This commit defines and implements a new "filesdata" command. This
command allows the retrieval of data for multiple files by specifying
changeset revisions and optional file patterns. The command figures
out what file revisions are "relevant" and sends them in bulk.

The logic around choosing which file revisions to send in the case of
haveparents not being set is overly simple and will over-send files. We
will need more smarts here eventually. (Specifically, the client will
need to tell the server which revisions it knows about.) This work
is deferred until a later time.

Differential Revision: https://phab.mercurial-scm.org/D4981

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
value when accessing the config option. This is useful for default values that
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
other properties. In this case, use the ``dynamicdefault`` object as the value
for the ``default`` parameter. A default value is then explicitly required when
reading the option::

    # registration
    coreconfigitem('web', 'name',
        default=dynamicdefault,
    )

    # usage
    ui.config('web', 'name', dirname)

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,
    )

The ``priority`` parameter controls the order used to match the generic pattern
(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``.

Supporting older versions
-------------------------

The registrar was introduced in Mercurial 4.3, and the ``generic`` parameter was
introduced in 4.4. Starting with Mercurial 4.4, all core options were registered
and developer warnings are emitted when accessing unregistered option.

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.

As reminder, here are the default values for each config type:
- config:      None
- configbool:  False
- configbytes: 0
- configdate:  None
- configint:   None
- configlist:  []
- configpath:  None