##// END OF EJS Templates
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.

File last commit:

r20532:f1a3ae7c default
r24991:4169a4f8 default
Show More
patterns.txt
62 lines | 2.2 KiB | text/plain | TextLexer
Dan Villiom Podlaski Christiansen
setup: install translation files as package data...
r9999 Mercurial accepts several notations for identifying one or more files
at a time.
By default, Mercurial treats filenames as shell-style extended glob
patterns.
Alternate pattern notations must be specified explicitly.
FUJIWARA Katsunori
doc: add note about pattern rooted/unrooted cases to "hgignore" and "patterns"...
r16504 .. note::
Simon Heimberg
help: remove last occurrences of ".. note::" without two newlines...
r20532
Mads Kiilerich
check-code: check txt files for trailing whitespace
r18960 Patterns specified in ``.hgignore`` are not rooted.
Mads Kiilerich
docs: don't use :hg: at the beginning of lines in notes (issue3397)...
r16510 Please see :hg:`help hgignore` for details.
FUJIWARA Katsunori
doc: add note about pattern rooted/unrooted cases to "hgignore" and "patterns"...
r16504
Dan Villiom Podlaski Christiansen
setup: install translation files as package data...
r9999 To use a plain path name without any pattern matching, start it with
``path:``. These path names must completely match starting at the
current repository root.
To use an extended glob, start a name with ``glob:``. Globs are rooted
at the current directory; a glob such as ``*.c`` will only match files
in the current directory ending with ``.c``.
The supported glob syntax extensions are ``**`` to match any string
across path separators and ``{a,b}`` to mean "a or b".
To use a Perl/Python regular expression, start a name with ``re:``.
Regexp pattern matching is anchored at the root of the repository.
Steve Borho
match: support reading pattern lists from files
r13218 To read name patterns from a file, use ``listfile:`` or ``listfile0:``.
The latter expects null delimited patterns while the former expects line
feeds. Each string read from the file is itself treated as a file
pattern.
FUJIWARA Katsunori
doc: add description about pattern matching against directories...
r20290 All patterns, except for ``glob:`` specified in command line (not for
FUJIWARA Katsunori
doc: fix mistake about matching against directories in "pattern.txt"...
r20329 ``-I`` or ``-X`` options), can match also against directories: files
under matched directories are treated as matched.
FUJIWARA Katsunori
doc: add description about pattern matching against directories...
r20290
Dan Villiom Podlaski Christiansen
setup: install translation files as package data...
r9999 Plain examples::
path:foo/bar a name bar in a directory named foo in the root
of the repository
path:path:name a file or directory named "path:name"
Glob examples::
glob:*.c any name ending in ".c" in the current directory
*.c any name ending in ".c" in the current directory
**.c any name ending in ".c" in any subdirectory of the
current directory including itself.
foo/*.c any name ending in ".c" in the directory foo
foo/**.c any name ending in ".c" in any subdirectory of foo
including itself.
Regexp examples::
re:.*\.c$ any name ending in ".c", anywhere in the repository
Steve Borho
match: support reading pattern lists from files
r13218
File examples::
listfile:list.txt read list from list.txt with one file pattern per line
listfile0:list.txt read list from list.txt with null byte delimiters
Matt Mackall
fileset: add a help topic...
r14686
See also :hg:`help filesets`.