Martin von Zweigbergk <martinvonz@google.com> [Thu, 26 Feb 2015 08:16:13 -0800] rev 25220
treemanifest: speed up diff by keeping track of dirty nodes
Since tree manifests have a nodeid per directory, we can avoid diffing
entire directories if they have the same nodeid. The comparison is
only valid for unmodified treemanifest instances, of course, so we
need to keep track of which have been modified. Therefore, let's add a
dirty flag to treemanifest indicating whether its nodeid can be
trusted. We set it when _files or _dirs is modified, and make diff(),
and its cousin filesnotin(), not descend into subdirectories that are
the same on both sides.
On the Mozilla repo, this speeds up 'hg diff -r .^ -r .' from 1.990s
to 1.762s. The improvement will be much larger when we start lazily
loading subdirectory manifests.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 20 May 2015 04:34:27 +0900] rev 25219
localrepo: use correct argument name for pretxnclose hooks (BC)
Before this patch, "the reason for the transaction" is passed to
`pretxnclose` hooks via wrong name argument `xnname` (`HG_XNNAME` for
external hooks)
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 20 May 2015 04:34:27 +0900] rev 25218
localrepo: rename hook argument from TXNID to txnid (BC)
From the first (3.4 or
d283517b260b), `TXNID` is passed to Python
hooks without lowering its name, but it is wrong.
Martin von Zweigbergk <martinvonz@google.com> [Wed, 05 Nov 2014 11:25:57 -0800] rev 25217
test-walk: add more tests for -I/-X
We had very limited testing of -I and -X, especially when combined
with plain file patterns and with each other. This adds some more
protection against regressions as upcoming patches modify the matcher
code. (Originally meant for my own upcoming patches, but now I know
drgott will be sending some patches soon.)
The only noteworthy cases seems to be that both of
hg debugwalk -Xbeans/black beans/black
hg debugwalk -Xbeans beans/black
walk the file. I would personally have expected the -X to trump. I
don't care enough to change it, but I also think it's fair if some
future commit changes the behavior.
Durham Goode <durham@fb.com> [Sat, 16 May 2015 16:06:22 -0700] rev 25216
ignore: use 'include:' rules instead of custom syntax
Now that the matcher supports 'include:' rules, let's change the dirstate.ignore
creation to just create a matcher with a bunch of includes. This allows us to
completely delete ignore.py.
I moved some of the syntax documentation over to readpatternfile in match.py so
we don't lose it.
Durham Goode <durham@fb.com> [Sat, 16 May 2015 15:56:52 -0700] rev 25215
match: add 'include:' syntax
This allows the matcher to understand 'include:path/to/file' style rules. The
files support the standard hgignore syntax and any rules read from the file are
included in the matcher without regard to the files location in the repository
(i.e. if the included file is in somedir/otherdir, all of it's rules will still
apply to the entire repository).
Durham Goode <durham@fb.com> [Mon, 18 May 2015 16:27:56 -0700] rev 25214
match: add optional warn argument
Occasionally the matcher will want to print warning messages instead of throwing
exceptions (like if it encounters a bad syntax parameter when parsing files).
Let's add an optional warn argument that can provide this. The next patch will
actually use this argument.
Durham Goode <durham@fb.com> [Sat, 16 May 2015 15:51:03 -0700] rev 25213
match: add source to kindpats list
Future patches will be adding the ability to recursively include pattern files
in a match rule expression. Part of that behavior will require tracking which
file each pattern came from so we can report errors correctly.
Let's add a 'source' arg to the kindpats list to track this. Initially it will
only be populated by listfile rules.
Matt Mackall <mpm@selenic.com> [Tue, 19 May 2015 08:41:04 -0500] rev 25212
check-code: reintroduce str.format() ban for 3.x porting
In their infinite wisdom, the Python maintainers stripped bytes of its
% and format() methods for 3.x. They've now added % back to 3.5, but
format() is still missing. Since we don't have any particular need for
it, we should keep avoiding it.
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 23:43:36 -0500] rev 25211
util: drop the 'unpacker' helper
It is not helping anything anymore.