##// END OF EJS Templates
upstream » mercurial-mirror
RSS

Clone from https://www.mercurial-scm.org/repo/hg-all

streamclone: define first iteration of version 2 of stream format...
streamclone: define first iteration of version 2 of stream format (This patch is based on a first draft from Gregory Szorc, with deeper rework) Version 1 of the stream clone format was invented many years ago and suffers from a few deficiencies: 1) Filenames are stored in store-encoded (on filesystem) form rather than in their internal form. This makes future compatibility with new store filename encodings more difficult. 2) File entry "headers" consist of a newline of the file name followed by the string file size. Converting strings to integers is avoidable overhead. We can't store filenames with newlines (manifests have this limitation as well, so it isn't a major concern). But the big concern here is the necessity for readline(). Scanning for newlines means reading ahead and that means extra buffer allocations and slicing (in Python) and this makes performance suffer. 3) Filenames aren't compressed optimally. Filenames should be compressed well since there is a lot of repeated data. However, since they are scattered all over the stream (with revlog data in between), they typically fall outside the window size of the compressor and don't compress. 4) It can only exchange stored based content, being able to exchange caches too would be nice. 5) It is limited to a stream-based protocol and isn't suitable for an on-disk format for general repository reading because the offset of individual file entries requires scanning the entire file to find file records. As part of enabling streaming clones to work in bundle2, #2 proved to have a significant negative impact on performance. Since bundle2 provides the opportunity to start fresh, Gregory Szorc figured he would take the opportunity to invent a new streaming clone data format. The new format devised in this series addresses #1, #2, and #4. It punts on #3 because it was complex without yielding a significant gain and on #5 because devising a new store format that "packs" multiple revlogs into a single "packed revlog" is massive scope bloat. However, this v2 format might be suitable for streaming into a "packed revlog" with minimal processing. If it works, great. If not, we can always invent stream format when it is needed. This patch only introduces the bases of the format. We'll get it usable through bundle2 first, then we'll extend the format in future patches to bring it to its full potential (especially #4).
Rodrigo Damazio Bovendorp - - Load All Authors

File last commit:

r35036:b0262b25 default
r35774:cfdccd56 default
Show More
flags.txt
104 lines | 2.8 KiB | text/plain | TextLexer
/ mercurial / help / flags.txt
History | Annotation | Raw |Copy content |Copy permalink
Most Mercurial commands accept various flags.
Flag names
==========
Flags for each command are listed in :hg:`help` for that command.
Additionally, some flags, such as --repository, are global and can be used with
any command - those are seen in :hg:`help -v`, and can be specified before or
after the command.
Every flag has at least a long name, such as --repository. Some flags may also
have a short one-letter name, such as the equivalent -R. Using the short or long
name is equivalent and has the same effect.
Flags that have a short name can also be bundled together - for instance, to
specify both --edit (short -e) and --interactive (short -i), one could use::
hg commit -ei
If any of the bundled flags takes a value (i.e. is not a boolean), it must be
last, followed by the value::
hg commit -im 'Message'
Flag types
==========
Mercurial command-line flags can be strings, numbers, booleans, or lists of
strings.
Specifying flag values
======================
The following syntaxes are allowed, assuming a flag 'flagname' with short name
'f'::
--flagname=foo
--flagname foo
-f foo
-ffoo
This syntax applies to all non-boolean flags (strings, numbers or lists).
Specifying boolean flags
========================
Boolean flags do not take a value parameter. To specify a boolean, use the flag
name to set it to true, or the same name prefixed with 'no-' to set it to
false::
hg commit --interactive
hg commit --no-interactive
Specifying list flags
=====================
List flags take multiple values. To specify them, pass the flag multiple times::
hg files --include mercurial --include tests
Setting flag defaults
=====================
In order to set a default value for a flag in an hgrc file, it is recommended to
use aliases::
[alias]
commit = commit --interactive
For more information on hgrc files, see :hg:`help config`.
Overriding flags on the command line
====================================
If the same non-list flag is specified multiple times on the command line, the
latest specification is used::
hg commit -m "Ignored value" -m "Used value"
This includes the use of aliases - e.g., if one has::
[alias]
committemp = commit -m "Ignored value"
then the following command will override that -m::
hg committemp -m "Used value"
Overriding flag defaults
========================
Every flag has a default value, and you may also set your own defaults in hgrc
as described above.
Except for list flags, defaults can be overridden on the command line simply by
specifying the flag in that location.
Hidden flags
============
Some flags are not shown in a command's help by default - specifically, those
that are deemed to be experimental, deprecated or advanced. To show all flags,
add the --verbose flag for the help command::
hg help --verbose commit