Tue, 27 Oct 2015 12:34:05 +0800 hgweb: escape class keyword when used as a js object property (issue4913) stable
Anton Shestakov <av6@dwimlabs.net> [Tue, 27 Oct 2015 12:34:05 +0800] rev 26832
hgweb: escape class keyword when used as a js object property (issue4913)
Sat, 24 Oct 2015 18:58:57 +0900 localrepo: discard objects in _filecache at transaction failure (issue4876) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 24 Oct 2015 18:58:57 +0900] rev 26831
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.
Wed, 28 Oct 2015 16:27:09 +0100 demandimport: fix TypeError when importing Python regex library (issue4920) stable
Gábor Stefanik <gabor.stefanik@nng.com> [Wed, 28 Oct 2015 16:27:09 +0100] rev 26830
demandimport: fix TypeError when importing Python regex library (issue4920)
Sat, 24 Oct 2015 00:39:22 +0100 bundle2: attribute remote failures to remote (issue4788) stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Oct 2015 00:39:22 +0100] rev 26829
bundle2: attribute remote failures to remote (issue4788) Before bundle2, hook output from hook failures was prefixed with "remote: ". Up to this point with bundle2, the output was converted to the message to print in an Abort exception. This had 2 implications: 1) It was unclear whether an error message came from the local repo or the remote 2) The exit code changed from 1 to 255 This patch changes the handling of error:abort bundle2 parts during push to prefix the error message with "remote: ". This restores the old behavior. We still preserve the behavior of raising an Abort during bundle2 application failure. This is a regression from pre-bundle2 because the exit code changed. Because we no longer raise an Abort with the remote's message, we needed to insert a message for the new Abort. So, I invented a new error message for that. This is another change from pre-bundle2. However, I like the new error message because it states unambiguously who aborted the push failed, which I think is important for users so they can decide what's next.
Sat, 24 Oct 2015 00:39:26 +0100 tests: add tests for remote hook output (issue4788) stable
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 24 Oct 2015 00:39:26 +0100] rev 26828
tests: add tests for remote hook output (issue4788) The added tests don't agree in their output. This demonstrates a difference in `hg push` behavior between pre-bundle2 and bundle2. A subsequent patch will attempt to restore some of the pre-bundle2 behavior to bundle2.
Sat, 24 Oct 2015 06:59:26 +0100 help: mention alias and revsetalias in description of HGPLAINEXCEPT stable
Yuya Nishihara <yuya@tcha.org> [Sat, 24 Oct 2015 06:59:26 +0100] rev 26827
help: mention alias and revsetalias in description of HGPLAINEXCEPT
Fri, 23 Oct 2015 11:04:53 -0400 debugrevlog: cope with empty revlog files stable
Augie Fackler <augie@google.com> [Fri, 23 Oct 2015 11:04:53 -0400] rev 26826
debugrevlog: cope with empty revlog files I have no idea where it came from, but my clone of Mercurial has an empty filelog for `contrib/hgfixes/__init__.py` - it's *valid*, just contains no nodes. Without this change, debugrevlog crashes with a zero division error.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip