mercurial: Changelog

inotify: _inotify.c: bugfix: remove_watch has to return PyNone on success We are not currently using that API function in inotify, hence the reason for the "silent" bug. But returning NULL here causes the interpreter to crash. Let's keep code clean for reusers :) The whole "bail" logic was unneeded here.

parsers.c: parse_manifest: fixing refcount of flags When flags was DECREF'ed, scope was referencing to the outer variable, outside of the block. It was in fact always NULL: the real Python object was never decref'ed.

test-highlight: remove redundant test Changeset 799373ff2554 is testing how a EUC-JP encoded Japanese file is treated in different encodings, so the ISO-8859-1 encoded German file is no longer needed.

Merge with crew-stable

highlight: fixes garbled text in non-UTF-8 environment This patch treats all files inside repository as encoded by locale's encoding when pygmentize. We can assume that most files are written in locale's encoding, but current implementation treats them as UTF-8. So there's no way to specify the encoding of files. Current implementation, db7557359636 (issue1341): 1. Convert original `text`, which is treated as UTF-8, to locale's encoding. `encoding.tolocal()` is the method to convert from internal UTF-8 to local. If original `text` is not UTF-8, e.g. Japanese EUC-JP, some characters become garbled here. 2. pygmentize, with no UnicodeDecodeError. This patch: 1. Convert original `text`, which is treated as locale's encoding, to unicode. Pygments prefers unicode object than raw str. [1]_ If original `text` is not encoded by locale's encoding, some characters become garbled here. 2. pygmentize, also with no UnicodeDecodeError :) 3. Convert unicode back to raw str, which is encoded by locale's. .. [1] http://pygments.org/docs/unicode/

Make distinct lookup error for localrepo.lookup This allows clone/share to correctly distinguish lookup errors from corruption errors and catch only the former.

doc: add TOC to hg.1.html and hgrc.5.html

log: prevent negative date range from displaying entire log (issue1805)

manifest/revlog: do not let the revlog cache mutable objects If a buffer of an mutable object is passed to revlog.addrevision(), the revlog will happily store it in its cache. Later when the revlog reuses the cached entry, if the manifest modified the object in-between, all kind of bugs appears. We fix it by: - passing immutable objects to addrevision() if they are already available - only storing the text in the cache if it's of str type Then we can remove the conversion of the cache entry to str() during retrieval. That was probably just there hiding the bug for the common cases but not really fixing it.