view mercurial/help/bundlespec.txt @ 35616:706aa203b396

fileset: add a lightweight file filtering language

This patch was inspired by one that Jun Wu authored for the fb-experimental
repo, to avoid using matcher for efficiency[1].  We want a way to specify what
files will be converted to LFS at commit time.  And per discussion, we also want
to specify what files to skip, text diff, or merge in another config option.
The current `lfs.threshold` config option could not satisfy complex needs.  I'm
putting it in a core package because Augie floated the idea of also using it for
narrow and sparse.

Yuya suggested farming out to fileset.parse(), which added support for more
symbols.  The only fileset element not supported here is 'negate'.  (List isn't
supported by filesets either.)  I also changed the 'always' token to the 'all()'
predicate for consistency, and introduced 'none()' to improve readability in a
future tracked file based config.  The extension operator was changed from '.'
to '**', to match how recursive path globs are specified.  Finally, I changed
the path matcher from '/' to 'path:' at Yuya's suggestion, for consistency with
matcher.  Unfortunately, ':' is currently reserved in filesets, so this has to
be quoted to be processed as a string instead of a symbol[2].  We should
probably revisit that, because it's seriously ugly.  But it's only used by an
experimental extension, and I think using a file based config for LFS may drive
some more tweaks, so I'm settling for this for now.

I reserved all of the glob characters in fileset except '.' and '_' for the
extension test because those are likely valid extension characters.

Sample filter settings:

  all()                        # everything
  size(">20MB")                # larger than 20MB
  !**.txt                      # except for .txt files
  **.zip | **.tar.gz | **.7z   # some types of compressed files
  "path:bin"                   # files under "bin" in the project root

[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-December/109387.html
[2] https://www.mercurial-scm.org/pipermail/mercurial-devel/2018-January/109729.html

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.