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

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

cmdutil: add class to restore dirstate during unexpected failure...
cmdutil: add class to restore dirstate during unexpected failure Before this patch, after "dirstate.write()" execution, there was no way to restore dirstate to the original status before "dirstate.write()". In some code paths, "dirstate.invalidate()" is used as a kind of "restore .hg/dirstate to the original status", but it just avoids writing changes in memory out, and doesn't actually restore the ".hg/dirstate" file. To fix the issue that the recent (in memory) dirstate isn't visible to external processes (e.g. "precommit" hooks), "dirstate.write()" should be invoked before invocation of external processes. But at the same time, ".hg/dirstate" should be restored to its content before "dirstate.write()" during an unexpected failure in some cases. This patch adds the class "dirstateguard" to easily restore ".hg/dirstate" during unexpected failures. Typical usecase of it is: # (1) build dirstate up .... # (2) write dirstate out, and backup ".hg/dirstate" dsguard = dirstateguard(repo, 'scopename') try: # (3) execute somethig to do: # this may imply making some additional changes on dirstate .... # (4) unlink backed-up dirstate file at the end of dsguard scope dsguard.close() finally: # (5) if execution is aborted before "dsguard.close()", # ".hg/dirstate" is restored from the backup dsguard.release() For this kind of issue, an "extending transaction" approach (in https://titanpad.com/mercurial32-sprint) seems to not be suitable, because: - transaction nesting occurs in some cases (e.g. "shelve => rebase"), and - "dirstate" may be already modified since the beginning of OUTER transaction scope, then - dirstate should be backed up into the file other than "dirstate.journal" at the beginning of INNER transaction scope, but - such alternative backup files are useless for transaction itself, and increases complication of its implementation "transaction" and "dirstateguard" differ from each other also in "what it should do for .hg/dirstate" in cases other than success. ============== ======= ======== ============= type success fail "hg rollback" ============== ======= ======== ============= transaction keep keep restore dirstateguard keep restore (not implied) ============== ======= ======== ============= Some collaboration between transaction and dirstate will probably be introduced in the future. But this layer is needed in all cases.
Jordi Gutiérrez Hermoso - - Load All Authors

File last commit:

r19296:da16d21c stable
r24991:4169a4f8 default
Show More
extensions.txt
35 lines | 1.2 KiB | text/plain | TextLexer
/ mercurial / help / extensions.txt
History | Annotation | Raw |Copy content |Copy permalink
Mercurial has the ability to add new features through the use of
extensions. Extensions may add new commands, add options to
existing commands, change the default behavior of commands, or
implement hooks.
To enable the "foo" extension, either shipped with Mercurial or in the
Python search path, create an entry for it in your configuration file,
like this::
[extensions]
foo =
You may also specify the full path to an extension::
[extensions]
myfeature = ~/.hgext/myfeature.py
See :hg:`help config` for more information on configuration files.
Extensions are not loaded by default for a variety of reasons:
they can increase startup overhead; they may be meant for advanced
usage only; they may provide potentially dangerous abilities (such
as letting you destroy or modify history); they might not be ready
for prime time; or they may alter some usual behaviors of stock
Mercurial. It is thus up to the user to activate extensions as
needed.
To explicitly disable an extension enabled in a configuration file of
broader scope, prepend its path with !::
[extensions]
# disabling extension bar residing in /path/to/extension/bar.py
bar = !/path/to/extension/bar.py
# ditto, but no path was supplied for extension baz
baz = !