scmutil: abort if an empty revision is given to revpair() When using 'extdiff --patch' to check the changes in a rebase, 'precursors(x)' evaluated to an empty set because I forgot the --hidden flag, so the other revision was used as the replacement for the empty set. The result was the patch for the other revision was diffed against itself, and the tool saying there were no differences. That's misleading since the expected diff args were silently changed, so it's better to bail out. The other uses of scmutil.revpair() are commands.diff and commands.status, and it doesn't make sense to allow an empty revision there either. The code here was suggested by Yuya Nishihara.

i18n-pt_BR: synchronized with a9ed5a8fc5e0

i18n-ja: synchronized with 6474b64045fb

packaging: rework version detection and declaration (issue4912) Previously the -rc in our rc tags got dropped, meaning that those packages looked newer to the packaging system than the later release build. This rectifies the issue, though some damage may already have been done on 3.6-rc builds. I'm mostly cargo-culting the RPM version format - there don't appear to be rules for RPM about how to handle this. Hopefully an RPM enthusiast can fix up what I've done as a followup.

hgweb: escape class keyword when used as a js object property (issue4913)

localrepo: discard objects in _filecache at transaction failure (issue4876) 'repo.invalidate()' deletes 'filecache'-ed properties by 'filecache.__delete__()' below via 'delattr(unfiltered, k)'. But cached objects are still kept in 'repo._filecache'. def __delete__(self, obj): try: del obj.__dict__[self.name] except KeyError: raise AttributeError(self.name) If 'repo' object is reused even after failure of command execution, referring 'filecache'-ed property may reuse one kept in 'repo._filecache', even if reloading from a file is expected. Executing command sequence on command server is a typical case of this situation (5c0f5db65c6b also tried to fix this issue). For example: 1. start a command execution 2. 'changelog.delayupdate()' is invoked in a transaction scope This replaces own 'opener' by '_divertopener()' for additional accessing to '00changelog.i.a' (aka "pending file"). 3. transaction is aborted, and command (1) execution is ended After 'repo.invalidate()' at releasing store lock, changelog object above (= 'opener' of it is still replaced) is deleted from 'repo.__dict__', but still kept in 'repo._filecache'. 4. start next command execution with same 'repo' 5. referring 'repo.changelog' may reuse changelog object kept in 'repo._filecache' according to timestamp of '00changelog.i' '00changelog.i' is truncated at transaction failure (even though this truncation is unintentional one, as described later), and 'st_mtime' of it is changed. But 'st_mtime' doesn't have enough resolution to always detect this truncation, and invalid changelog object kept in 'repo._filecache' is reused occasionally. Then, "No such file or directory" error occurs for '00changelog.i.a', which is already removed at (3). This patch discards objects in '_filecache' other than dirstate at transaction failure. Changes in 'invalidate()' can't be simplified by 'self._filecache = {}', because 'invalidate()' should keep dirstate in 'self._filecache' 'repo.invalidate()' at "hg qpush" failure is removed in this patch, because now it is redundant. This patch doesn't make 'repo.invalidate()' always discard objects in '_filecache', because 'repo.invalidate()' is invoked also at unlocking store lock. - "always discard objects in filecache at unlocking" may cause serious performance problem for subsequent procedures at normal execution - but it is impossible to "discard objects in filecache at unlocking only at failure", because 'releasefn' of lock can't know whether a lock scope is terminated normally or not BTW, using "with" statement described in PEP343 for lock may resolve this ? After this patch, truncation of '00changelog.i' still occurs at transaction failure, even though newly added revisions exist only in '00changelog.i.a' and size of '00changelog.i' isn't changed by this truncation. Updating 'st_mtime' of '00changelog.i' implied by this redundant truncation also affects cache behavior as described above. This will be fixed by dropping '00changelog.i' at aborting from the list of files to be truncated in transaction.

demandimport: fix TypeError when importing Python regex library (issue4920)