- 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.
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.
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.
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 ;-)
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.
Implemented as two functions: diffstat, which yields lines of text,
formatted as a usual diffstat output, and diffstatdata, which is called
inside diffstat to do real performing and yield file names with
appropriate data (numbers of added and removed lines).
