##// END OF EJS Templates
changegroup: fix treemanifests on merges...
changegroup: fix treemanifests on merges The current code for generating treemanifest revisions takes the list of files in the changeset and finds the directories from them. This does not work for merges, since a merge may pick file A from one side and file B from another and neither of them would appear in the changeset's "files" list, but the manifest would still change. Fix this by instead walking the root manifest log for all needed revisions, storing all needed file and subdirectory revisions, then recursively visiting the subdirectories. This also turns out to be faster: cloning a version of hg core converted to treemanifests went from ~28s to ~19s (timing somewhat unfair: before this patch, timed until crash; after this patch, timed until manifests complete). The new algorithm is used only on treemanifest repos. Although it works equally well on flat manifests, we leave the iteration over files in the changeset for flat manifests for now.

File last commit:

r25284:7072b91c default
r28240:1ac8ce13 default
Show More
patterns.txt
74 lines | 2.8 KiB | text/plain | TextLexer
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.
.. note::
Patterns specified in ``.hgignore`` are not rooted.
Please see :hg:`help hgignore` for details.
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.
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.
To read a set of patterns from a file, use ``include:`` or ``subinclude:``.
``include:`` will use all the patterns from the given file and treat them as if
they had been passed in manually. ``subinclude:`` will only apply the patterns
against files that are under the subinclude file's directory. See :hg:`help
hgignore` for details on the format of these files.
All patterns, except for ``glob:`` specified in command line (not for
``-I`` or ``-X`` options), can match also against directories: files
under matched directories are treated as matched.
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
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
See also :hg:`help filesets`.
Include examples::
include:path/to/mypatternfile reads patterns to be applied to all paths
subinclude:path/to/subignorefile reads patterns specifically for paths in the
subdirectory