##// END OF EJS Templates
state: import the file to write state files from evolve extension...
state: import the file to write state files from evolve extension The current way of writing state files is very obscure with each state file having it's own format to store state files. There is no centralized way to write state files in a good format. Moreover the current state files are not extensible, you cannot add more data to store in state files in reliable ways. To solve the problem, I wrote my own serialization and deserialization format, looked into existing formats like Protobuf, MessagePack, JSON but CBOR looks very promising and is suggested by people in the community. The current interface to store state files is to directly write data in files when things abort. Using the class imported by this commit, we can create objects which has a dict like interface and can store data on the object and store it on the file when things abort. The evolve extension is using the state file for `evolve`, `grab` commands and using it for resolution of orphaness, phase-divergence and content-divergence. The file is moved from changeset e4ac2e2c2086f977afa35e23a62f849e9305a225 of the evolve extension which is also tagged as 7.3.0. The following changes are made to the file while moving to core: * import util from current directory as this file in mercurial/ now * make cmdstate class extend object * removed mutable default value for opts in cmdstate.__init__ * some doc changes to replace out of core things with in-core ones evolve extension can be found at https://bitbucket.org/marmoute/mutable-history Differential Revision: https://phab.mercurial-scm.org/D2591

File last commit:

r32601:01280ec5 stable
r38115:a2f83661 default
Show More
bundlespec.txt
84 lines | 2.6 KiB | text/plain | TextLexer
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>
The compression engine and format are delimited by a hyphen (``-``).
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``
Produce a ``v1`` bundle with no compression.
``zstd-v2``
Produce a ``v2`` bundle with zstandard compression using default
settings.
``zstd-v1``
This errors because ``zstd`` is not supported for ``v1`` types.