##// END OF EJS Templates
wireprotov2: implement commands as a generator of objects...
wireprotov2: implement commands as a generator of objects Previously, wire protocol version 2 inherited version 1's model of having separate types to represent the results of different wire protocol commands. As I implemented more powerful commands in future commits, I found I was using a common pattern of returning a special type to hold a generator. This meant the command function required a closure to do most of the work. That made logic flow more difficult to follow. I also noticed that many commands were effectively a sequence of objects to be CBOR encoded. I think it makes sense to define version 2 commands as generators. This way, commands can simply emit the data structures they wish to send to the client. This eliminates the need for a closure in command functions and removes encoding from the bodies of commands. As part of this commit, the handling of response objects has been moved into the serverreactor class. This puts the reactor in the driver's seat with regards to CBOR encoding and error handling. Having error handling in the function that emits frames is particularly important because exceptions in that function can lead to things getting in a bad state: I'm fairly certain that uncaught exceptions in the frame generator were causing deadlocks. I also introduced a dedicated error type for explicit error reporting in command handlers. This will be used in subsequent commits. There's still a bit of work to be done here, especially around formalizing the error handling "protocol." I've added yet another TODO to track this so we don't forget. Test output changed because we're using generators and no longer know we are at the end of the data until we hit the end of the generator. This means we can't emit the end-of-stream flag until we've exhausted the generator. Hence the introduction of 0-sized end-of-stream frames. Differential Revision: https://phab.mercurial-scm.org/D4472

File last commit:

r35187:aef2b98d merge default
r39595:07b58266 default
Show More
environment.txt
121 lines | 4.2 KiB | text/plain | TextLexer
HG
Path to the 'hg' executable, automatically passed when running
hooks, extensions or external tools. If unset or empty, this is
the hg executable's name if it's frozen, or an executable named
'hg' (with %PATHEXT% [defaulting to COM/EXE/BAT/CMD] extensions on
Windows) is searched.
HGEDITOR
This is the name of the editor to run when committing. See EDITOR.
(deprecated, see :hg:`help config.ui.editor`)
HGENCODING
This overrides the default locale setting detected by Mercurial.
This setting is used to convert data including usernames,
changeset descriptions, tag names, and branches. This setting can
be overridden with the --encoding command-line option.
HGENCODINGMODE
This sets Mercurial's behavior for handling unknown characters
while transcoding user input. The default is "strict", which
causes Mercurial to abort if it can't map a character. Other
settings include "replace", which replaces unknown characters, and
"ignore", which drops them. This setting can be overridden with
the --encodingmode command-line option.
HGENCODINGAMBIGUOUS
This sets Mercurial's behavior for handling characters with
"ambiguous" widths like accented Latin characters with East Asian
fonts. By default, Mercurial assumes ambiguous characters are
narrow, set this variable to "wide" if such characters cause
formatting problems.
HGMERGE
An executable to use for resolving merge conflicts. The program
will be executed with three arguments: local file, remote file,
ancestor file.
(deprecated, see :hg:`help config.ui.merge`)
HGRCPATH
A list of files or directories to search for configuration
files. Item separator is ":" on Unix, ";" on Windows. If HGRCPATH
is not set, platform default search path is used. If empty, only
the .hg/hgrc from the current repository is read.
For each element in HGRCPATH:
- if it's a directory, all files ending with .rc are added
- otherwise, the file itself will be added
HGPLAIN
When set, this disables any configuration settings that might
change Mercurial's default output. This includes encoding,
defaults, verbose mode, debug mode, quiet mode, tracebacks, and
localization. This can be useful when scripting against Mercurial
in the face of existing user configuration.
In addition to the features disabled by ``HGPLAIN=``, the following
values can be specified to adjust behavior:
``+strictflags``
Restrict parsing of command line flags.
Equivalent options set via command line flags or environment
variables are not overridden.
See :hg:`help scripting` for details.
HGPLAINEXCEPT
This is a comma-separated list of features to preserve when
HGPLAIN is enabled. Currently the following values are supported:
``alias``
Don't remove aliases.
``color``
Don't disable colored output.
``i18n``
Preserve internationalization.
``revsetalias``
Don't remove revset aliases.
``templatealias``
Don't remove template aliases.
``progress``
Don't hide progress output.
Setting HGPLAINEXCEPT to anything (even an empty string) will
enable plain mode.
HGUSER
This is the string used as the author of a commit. If not set,
available values will be considered in this order:
- HGUSER (deprecated)
- configuration files from the HGRCPATH
- EMAIL
- interactive prompt
- LOGNAME (with ``@hostname`` appended)
(deprecated, see :hg:`help config.ui.username`)
EMAIL
May be used as the author of a commit; see HGUSER.
LOGNAME
May be used as the author of a commit; see HGUSER.
VISUAL
This is the name of the editor to use when committing. See EDITOR.
EDITOR
Sometimes Mercurial needs to open a text file in an editor for a
user to modify, for example when writing commit messages. The
editor it uses is determined by looking at the environment
variables HGEDITOR, VISUAL and EDITOR, in that order. The first
non-empty one is chosen. If all of them are empty, the editor
defaults to 'vi'.
PYTHONPATH
This is used by Python to find imported modules and may need to be
set appropriately if this Mercurial is not installed system-wide.