##// END OF EJS Templates
lfs: verify lfs object content when transferring to and from the remote store...
lfs: verify lfs object content when transferring to and from the remote store This avoids inserting corrupt files into the usercache, and local and remote stores. One down side is that the bad file won't be available locally for forensic purposes after a remote download. I'm thinking about adding an 'incoming' directory to the local lfs store to handle the download, and then move it to the 'objects' directory after it passes verification. That would have the additional benefit of not concatenating each transfer chunk in memory until the full file is transferred. Verification isn't needed when the data is passed back through the revlog interface or when the oid was just calculated, but otherwise it is on by default. The additional overhead should be well worth avoiding problems with file based remote stores, or buggy lfs servers. Having two different verify functions is a little sad, but the full data of the blob is mostly passed around in memory, because that's what the revlog interface wants. The upload function, however, chunks up the data. It would be ideal if that was how the content is always handled, but that's probably a huge project. I don't really like printing the long hash, but `hg debugdata` isn't a public interface, and is the only way to get it. The filelog and revision info is nowhere near this area, so recommending `hg verify` is the easiest thing to do.

File last commit:

r34952:fb7f58da stable
r35492:417e8e04 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