##// END OF EJS Templates
windows: add a method to convert Unix style command lines to Windows style...
windows: add a method to convert Unix style command lines to Windows style This started as a copy/paste of `os.path.expandvars()`, but limited to a given dictionary of variables, converting `foo = foo + bar` to `foo += bar`, and adding 'b' string prefixes. Then code was added to make sure that a value being substituted in wouldn't itself be expanded by cmd.exe. But that left inconsistent results between `$var1` and `%var1%` when its value was '%foo%'- since neither were touched, `$var1` wouldn't expand but `%var1%` would. So instead, this just converts the Unix style to Windows style (if the variable exists, because Windows will leave `%missing%` as-is), and lets cmd.exe do its thing. I then dropped the %% -> % conversion (because Windows doesn't do this), and added the ability to escape the '$' with '\'. The escape character is dropped, for consistency with shell handling. After everything seemed stable and working, running the whole test suite flagged a problem near the end of test-bookmarks.t:1069. The problem is cmd.exe won't pass empty variables to its child, so defined but empty variables are now skipped. I can't think of anything better, and it seems like a pre-existing violation of the documentation, which calls out that HG_OLDNODE is empty on bookmark creation. Future additions could potentially be replacing strong quotes with double quotes (cmd.exe doesn't know what to do with the former), escaping a double quote, and some tilde expansion via os.path.expanduser(). I've got some doubts about replacing the strong quotes in case sh.exe is run, but it seems like the right thing to do the vast majority of the time. The original form of this was discussed about a year ago[1]. [1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-July/100735.html

File last commit:

r32601:01280ec5 stable
r38502:3efadf23 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.