This patch makes sure that either "tmpl" or "mapfile" is exclusively set,
which is the same behavior as common log-like templates and formatter outputs.
See the previous patch for why.
A repo pattern for any notify configuration contains a glob matching the
path to the repo. Additionally, it may now contain a revset spec, separated
from the glob by '#'.
Example:
[reposubs]
*/widgets#branch(release) = qa-team@example.com
This sends to ``qa-team@example.com`` whenever a changeset on the ``release``
branch triggers a notification in any repository ending in ``widgets``.
This patch was completely done by David Champion <dgc@uchicago.edu> with me
making tiny changes to his tests.
according to configuration example below, and direction of changeset
transference, this paragraph should describe about "changegroup" hook.
[hooks]
# one email for each incoming changeset
incoming.notify = python:hgext.notify.hook
# one email for all incoming changesets
changegroup.notify = python:hgext.notify.hook
# one email for all outgoing changesets
outgoing.notify = python:hgext.notify.hook
Change the behavior so that the sender (the "From" header in the notification
mail) in case of the "changegroup" hook is the user that did the first commit
in the changegroup. The option is configurable, if you set "notify.fromauthor"
to "True" in your config, the new behavior is activated. If you do not set the
option, the behavior is as before. The commit adds to an existing test to show
various aspects of the changed behavior.
Globbing is usually used for filenames, so on windows it is reasonable and very
convenient that glob patterns accepts '\' or '/' when the pattern specifies
'/'.
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.)
The main intent is to turn the reference help into a configuration walkthrough.
It also fix several things:
- Do not suggest to use it for commit notifications, it cannot work
- Fix notify.strip default value
- Mention that subscriptions can be setup in Mercurial configuration files
- Improve notify.strip and notify.domain documentation
This speeds up the in-memory version of debugbuilddag that I'm
working on considerably for the case where we want to build just
a 00changelog.i (for discovery tests, for instance).
There are a couple of test changes because node ids in tests
have changed.
The changes to the patch names in test-mq-qdelete.t were required
because they could collide with nodeid abbreviations and newly
actually do (patch "c" collides with id "cafe..." for patch "b").
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)
It tries to convert localstr to unicode before truncating.
Because we cannot assume that the given text is encoded in local encoding,
it falls back to raw string in case of unicode error.
