- create error.py for exception classes to reduce demandloading
- move revlog exceptions to it
- change users to import error and drop revlog import if possible
This extension produces quite a lot of informational messages during
its normal operation and it is hard to say which strings can be
changed and which cannot.
This should be faster and more future-proof. Calls where the result is to be
sorted using util.sort() have been left unchanged. Calls to .items() on
configparser objects have been left as-is, too.
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.
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.
Copy information was saved in a common loop, then refined in a git-only block.
The problem was the latter did filter out renames occuring in the current
patch and irrelevant to commit. In the non-git case, copy records still existed
in the dirstate, referencing removed files, making the commit to fail. Git and
non-git copy handling paths are now separated for simplicity.
Reported by Gary Bernhardt
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.
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.
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.