When loading a python hook with file syntax fails, there is no
information that this happened while loading a hook. When the python
file does not exist even the file name is not printed. (Only that a
file is missing.)
This patch adds this information and a test for loading a non existing file and
a directory not being a python module.
Currently we have the following return codes if nothing is found:
commit incoming outgoing pull push
intended 1 1 1 1 1
documented 1 1 1 0 1
actual 1 1 1 0 1
This makes pull agree with the rest of the table and makes it easy to
detect "nothing was pulled" in scripts.
New tags were written to .hgtags / .hglocaltags without updating or
invalidating the localrepo cache.
Before 462e6cfb1bac a lock was acquired soon after the new tags had been
written, and that invalidated the cache so the new tags for example could be
seen in pretxncommit hooks. With 462e6cfb1bac the lock had already been
acquired at this point and the missing cache invalidation was exposed.
The tag caches will now explicitly and immediately be invalidated when new tags
are added.
As of Mercurial 1.3, hooks are sorted in the order they are read into
Mercurial. There are many instances when someone may want the hooks
sorted in a specific order; this patch allows prioritizing hooks, while
maintaining the existing enumeration for hooks without a priority.
If the working dir parent was destroyed by rollback, then the old
behaviour is perfectly reasonable: restore dirstate, branch, and
bookmarks. That way the working dir moves back to an existing
changeset rather than becoming an orphan.
But if the working dir parent was unaffected -- say, you updated to an
older changeset and then did rollback -- then it's silly to restore
dirstate and branch. So don't do that. Leave the status of the working
dir alone. (But always restore bookmarks, because that file refers to
changeset IDs that may have been destroyed.)
Adds a new discovery method based on repeatedly sampling the still
undecided subset of the local node graph to determine the set of nodes
common to both the client and the server.
For small differences between client and server, it uses about the same
or slightly fewer roundtrips than the old tree-based discovery. For
larger differences, it typically reduces the number of roundtrips
drastically (from 150 to 4, for instance).
The old discovery code now lives in treediscovery.py, the new code is
in setdiscovery.py.
Still missing is a hook for extensions to contribute nodes to the
initial sample. For instance, Augie's remotebranches could contribute
the last known state of the server's heads.
Credits for the actual sampler and computing common heads instead of
bases go to Benoit Boissinot.
Since bookmarks are no longer merged with repo.tags() as of
8e2d23f4bd25, they don't show up in `hg id` as they used to. This adds
them back into the summary that `hg id` prints, and adds a
-B/--bookmarks flag alongside the -t/--tags and -b/--branch options.
Note this introduces a slight backwards-incompatibility: the summary
printed by `hg id` now separates bookmarks from tags with a space, as
seen below, instead of running it into the tags list.
Default summary output:
$ hg id
db815d6d32e6 tip/tag1 bm1/bm2
Output with --bookmarks:
$ hg id --bookmarks
bm1 bm2
See also 5672c9e8202d which adds bookmarks back into `hg summary`.
Previously, when rolling back a transaction, some users could be confused
between the level to which the store is rolled back, and the new parents
of the working directory.
$ hg rollback
rolling back to revision 4 (undo commit)
With this change:
$ hg rollback
repository tip rolled back to tip revision 4 (undo commit)
working directory now based on revision 2 and 1
So now the user can realize that the store has been rolled back to an older
tip, but also that the working directory may not on the tip (here we are
rolling back the merge of the heads 2 and 1)
The actual order of dictionary items is implementation-defined in
Python, and differs between CPython and PyPy. With this change,
test-hooks.t passes with PyPy.
Currently, cmdutil.make_file() will return a freshly made file handle,
except when given a pattern of '-'. If callers would want to close the
handle, they would have to make sure that it's neither sys.stdin or
sys.stdout. Instead, returning a duplicate of either of the two
ensures that make_file() lives up to its name and creates a new
file handle regardless of the input.
This adds a " (glob)" marker that works like a simpler version of
(re): "*" is converted to ".*", and "?" is converted to ".".
Both special characters can be escaped using "\", and the backslash
itself can be escaped as well.
Other glob-style syntax, like "**", "[chars]", or "[!chars]", isn't
supported.
Consider this test:
$ hg glog --template '{rev}:{node|short} "{desc}"\n'
@ 2:20c4f79fd7ac "3"
|
| o 1:38f24201dcab "2"
|/
o 0:2a18120dc1c9 "1"
Because each line beginning with "|" can be compiled as a regular
expression (equivalent to ".*|"), they will match any output.
Similarly:
$ echo foo
The blank output line can be compiled as a regular expression and will
also match any output.
With this patch, none of the above output lines will be matched as
regular expressions. A line must end in " (re)" in order to be matched
as one.
Lines are still matched literally first, so the following will pass:
$ echo 'foo (re)'
foo (re)
Many tests fixed the commit date of their changesets at '1000000 0' or
similar. However testing with "Mon Jan 12 13:46:40 1970 +0000" is not
better than testing with "Thu Jan 01 00:00:00 1970 +0000", which is
the default run-tests.py installs.
Removing the unnecessary flag removes some clutter and will hopefully
make it clearer what the tests are really trying to test. Some tests
did not even change their output when the dates were changed, in which
case the -d flag was truly irrelevant.
Dates used in sequence (such as '0 0', '1 0', etc...) were left alone
since they may make the test easier to understand.
