##// END OF EJS Templates
repository: define manifest interfaces...
repository: define manifest interfaces The long march towards declaring interfaces for repository primitives continues. This commit essentially defines interfaces based on the following types: * manifest.manifestdict -> imanifestdict * manifest.manifestlog -> imanifestlog * manifest.memmanifestctx -> imanifestrevisionwritable * manifest.manifestctx -> imanifestrevisionstored * manifest.memtreemanifestctx -> imanifestrevisionwritable * manifest.treemanifestctx -> imanifestrevisionstored * util.dirs -> idirs The interfaces are thoroughly documented. Their documentation is now better than the documentation in manifest.py in many cases. With the exception of util.dirs, classes have been annotated with their interfaces. (I didn't feel like util.dirs needed the proper interface treatment.) Tests have been added demonstrating that all classes and instances conform to their interfaces. This work was much easier than filelogs. That's because Durham did an excellent job formalizing the manifest API a while back. There are still some minor kludges with the interfaces that should probably be addressed. But the primary goal with interface declarations is getting something established. Once we have an interface, we can modify it later easily enough. Differential Revision: https://phab.mercurial-scm.org/D3869

File last commit:

r32601:01280ec5 stable
r38549:c82ea938 default
Show More
bundlespec.txt
84 lines | 2.6 KiB | text/plain | TextLexer
Gregory Szorc
help: document bundle specifications...
r31793 Mercurial supports generating standalone "bundle" files that hold repository
data. These "bundles" are typically saved locally and used later or exchanged
between different repositories, possibly on different machines. Example
commands using bundles are :hg:`bundle` and :hg:`unbundle`.
Generation of bundle files is controlled by a "bundle specification"
("bundlespec") string. This string tells the bundle generation process how
to create the bundle.
A "bundlespec" string is composed of the following elements:
type
A string denoting the bundle format to use.
compression
Denotes the compression engine to use compressing the raw bundle data.
parameters
Arbitrary key-value parameters to further control bundle generation.
A "bundlespec" string has the following formats:
<type>
The literal bundle format string is used.
<compression>-<type>
Matt Harbison
help: spelling fixes
r32139 The compression engine and format are delimited by a hyphen (``-``).
Gregory Szorc
help: document bundle specifications...
r31793
Optional parameters follow the ``<type>``. Parameters are URI escaped
``key=value`` pairs. Each pair is delimited by a semicolon (``;``). The
first parameter begins after a ``;`` immediately following the ``<type>``
value.
Available Types
===============
The following bundle <type> strings are available:
v1
Produces a legacy "changegroup" version 1 bundle.
This format is compatible with nearly all Mercurial clients because it is
the oldest. However, it has some limitations, which is why it is no longer
the default for new repositories.
``v1`` bundles can be used with modern repositories using the "generaldelta"
storage format. However, it may take longer to produce the bundle and the
resulting bundle may be significantly larger than a ``v2`` bundle.
``v1`` bundles can only use the ``gzip``, ``bzip2``, and ``none`` compression
formats.
v2
Produces a version 2 bundle.
Version 2 bundles are an extensible format that can store additional
repository data (such as bookmarks and phases information) and they can
store data more efficiently, resulting in smaller bundles.
Version 2 bundles can also use modern compression engines, such as
``zstd``, making them faster to compress and often smaller.
Available Compression Engines
=============================
The following bundle <compression> engines can be used:
.. bundlecompressionmarker
Examples
========
``v2``
Produce a ``v2`` bundle using default options, including compression.
``none-v1``
Wagner Bruna
help: fix typos
r32601 Produce a ``v1`` bundle with no compression.
Gregory Szorc
help: document bundle specifications...
r31793
``zstd-v2``
Produce a ``v2`` bundle with zstandard compression using default
settings.
``zstd-v1``
This errors because ``zstd`` is not supported for ``v1`` types.