Bugzilla 2.18 and on use contrib/sendbugmail.pl, not processmail. During 2.17, Bugzilla ditched the old 'processmail' script. With 2.18 contrib/sendbugmail.pl arrived in its place. For notification emails to work properly, sendbugmail.pl requires as its second parameter the Bugzilla user who made the commit. Otherwise the user will not be recognised as the committer, and will receive notification emails about the commit regardless of their preference about being notified on their own commits. This parameter should be given to processmail also, but wasn't for historical reasons. Add new config with the local Bugzilla install directory, and provide defaults for the notify string which should work for most setups. Still permit notify string to be specified, and for backwards compatibility with any extant notify strings try first interpolating notify string with old-style single bug ID argument. Add new 2.18 support version to introduce sendbugmail.pl. In other words, this update should be backwards-compatible with existing installations, but offers simplified setup in most cases. And as a bonus Bugzilla notification emails will be dispatched correctly; notifiers will not receive an email unless configured to do so.

merge with -stable

use enumerate instead of zip

patch: export shouldn't close files received as a parameter We rely on __del__ to close the fd instead. Patchbomb was relying on this behaviour, fix it. Thanks to Manuel Barkhau for reporting it.

mq: make qnew patch format consistent with qrefresh (issue1457)

monoblue: fix child revision display in file diff page

web: use the correct filectx in filelog

convert: display child command output if --debug (fix 878466138b57)

convert: print darcs error messages iff --debug

convert: check for darcs-2-compatible path

merge with -stable

merge with crew-stable

zeroconf: add extension documentation

1 file changed, 7 insertions(+), 9 deletions(-) hgext/purge.py | 16 +++++++--------- purge: clarify behavior with regard to ignored files The purge documentation previously said that purge would delete ignored files. This is only true if purge is passed the --all option, which is now stated explicitly. A few trivial grammar errors were also fixed.

tests: shrink wait interval for test-convert-bzr-merges

Merge with crew-stable

tests: try to prevent different ordering in test-convert-bzr-merges

merge with crew

lowercase prompts The prompts are interactive and not meant for scripts.

lowercase ui.debug and assert output This does not effect the log or status commands and should be okay according to the compatibility rules.

lowercase help output Changes docstrings to begin with a lowercase word. Only docstrings used in help output is changed. Scripts are not expected to grep the output of 'hg help' so this change should pose no problem with regard to the compatibility rules.

mq, i18n: mark strings for translation

commands: remove redundant paragraph from tags help

Merge with crew-stable

test: added testcase for cvsps log message lookahead

cvsps: cvs log loop uses lookahead to avoid misleading text Changes cvsps.py's cvs log reader to use a one-line lookahead, so that possibly misleading log messages can be disambiguated. In particular I have past committers who used cvs log's 28-character row of hyphens within commit messages; this throws cvsps and disrupts conversion. The only alternative in this case is to edit the cvs ,v file by hand, which bloodies mercurial's "don't change history" principle.

convert/gnuarch: recode cat-log parts to utf-8 to be hg.description friendly

convert/gnuarch: add cat-log payload to commit description

bisect: improve hg bisect -c (relative paths, error handling) hg bisect -c failed with a relative path or when the executable wasn't found. Use util.find_exe()+os.spawnl() instead of os.spawnlp() and improve the handling of errors (killed process, exe not found). Thanks to Georg Brandl for reporting it.

merge with crew-stable

convert/gnuarch: correct indentation

merge with crew

test-audit-path: add one more test (issue 1450)

convert/gnuarch: follow continuation-of revisions Built on top of previous patches: - continuation-of parsing - registered archives retrieval - use of fully qualified revisions This allows the converter scanning for more source revisions following the tree versions 'leaked' through the continuation-of informations. Coupled with the registered archives retrieval, this makes possible to decide to follow such a hint or stop scanning for more revisions. This also implies some changes in the retrieval of some base-0 revisions when they're continuation-of other revisions, in that case a 'replay' will work where a simple 'get' fails because the dir exists already. I found the code dealing with 'replay' quite good as it has already a fallback to 'get' in the error path.

convert/gnuarch: retrieve known archive names list This will make possible in a followup patch to prevent following history that is not reachable because an archive is unknown to the user.

convert/gnuarch: parse continuation-of revisions in gnuarch source In GNU Arch, continuation-of was often used for: - tagging revisions - continue working on a project in a new archive, because arch was scaling poorly in revision numbers (cat-logs were slow to be parsed and scanned through) - very similar to the previous point, fork his own branch of a project. Parsing this header information will allow to 'follow' new history because it often hints at older/forked/personal revision trees. This patch however just implements the parsing of the continuation-of header. A followup patch will implement the proper use of this new information.

convert/gnuarch: use fully qualified revisions There is no need loosing information in the conversion process. This could lead to wrong shamap mappings if different archives used the same 'version' naming.

convert/gnuarch: keep track of original revision in extra headers It seems to be standard to populate the .rev attribute of a commit to keep track of original SCM revision names. Just do it(tm).

convert/gnuarch: robustify cat-log retrieval GNU Arch used to scale very poorly when revision number was increasing. This was mostly caused by the huge amount of cat-log it has to scan/read through to keep track of all patches that were merged in a given revision. In order to improve things, cat-log prunning was a common admin task that would accelerate cat-log parsing at the expense of unreachabe locally stored cat-logs. However, these missing cat-logs are still available in the archive. So try to get them from the archive as a fallback solution.

convert/gnuarch: set prefered locale for str conversions Seems necessary, as a test on my archives goes further with this.

convert/gnuarch: fix cat-log parsing cat-log parsing was very wrong. It assumed the Summary header was comming last, which is wrong. Plus the code was buggy because it was concatenating all headers in the summary. As parsing GNU Arch isn't trivial, and python email code does it so well... just use that ;-)

convert/gnuarch: remove unused code Debug stuff ? Wipe it.

Merge with crew-stable

hgweb: fix long line lengths introduced in 2dc868712dcc

tests: use killdaemons.py in test-pull-http

cvsps: kill some more trailing whitespace

merge with crew-stable

Merge with crew-stable