Sun, 05 Jun 2016 23:36:23 +0200 url: extract password database from password manager
liscju <piotr.listkiewicz@gmail.com> [Sun, 05 Jun 2016 23:36:23 +0200] rev 29377
url: extract password database from password manager So far password manager was keeping authentication information so opening new connection and creating new password manager made all saved authentication information lost. This commit separates password manager and password database to make it possible to reuse saved authentication information. This commit violates code checker because it adds add_password method (name with underscore) to passwordmgr object to provide method required by urllib2.
Wed, 01 Jun 2016 22:58:57 +0200 bookmarks: add 'hg pull -B .' for pulling the active bookmark (issue5258)
liscju <piotr.listkiewicz@gmail.com> [Wed, 01 Jun 2016 22:58:57 +0200] rev 29376
bookmarks: add 'hg pull -B .' for pulling the active bookmark (issue5258)
Sun, 19 Jun 2016 02:17:33 +0900 demandimport: delay loading for "from a import b" with absolute_import
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 19 Jun 2016 02:17:33 +0900] rev 29375
demandimport: delay loading for "from a import b" with absolute_import Before this patch, "from a import b" doesn't delay loading module "b", if absolute_import is enabled, even though "from . import b" does. For example: - it is assumed that extension X has "from P import M" for module M under package P with absolute_import feature - if importing module M is already delayed before loading extension X, loading module M in extension X is delayed until actually referring util, cmdutil, scmutil or so of Mercurial itself should be imported by "from . import M" style before loading extension X - otherwise, module M is loaded immediately at loading extension X, even if extension X itself isn't used at that "hg" command invocation Some minor modules (e.g. filemerge or so) of Mercurial itself aren't imported by "from . import M" style before loading extension X. And of course, external libraries aren't, too. This might cause startup performance problem of hg command, because many bundled extensions already enable absolute_import feature. To delay loading module for "from a import b" with absolute_import feature, this patch does below in "from a (or .a) import b" with absolute_import case: 1. import root module of "name" by system built-in __import__ (referred as _origimport) 2. recurse down the module chain for hierarchical "name" This logic can be shared with non absolute_import case. Therefore, this patch also centralizes it into chainmodules(). 3. and fall through to process elements in "fromlist" for the leaf module of "name" Processing elements in "fromlist" is executed in the code path after "if _pypy: .... else: ..." clause. Therefore, this patch replaces "if _pypy:" with "elif _pypy:" to share it. At 4f1144c3c72b introducing original "work around" for "from a import b" case, elements in "fromlist" were imported with "level=level". But "level" might be grater than 1 (e.g. level=2 in "from .. import b" case) at demandimport() invocation, and importing direct sub-module in "fromlist" with level grater than 1 causes unexpected result. IMHO, this seems main reason of "errors for unknown reason" described in 4f1144c3c72b, and we don't have to worry about it, because this issue was already fixed by 78d05778907b. This is reason why this patch removes "errors for unknown reasons" comment.
Sun, 19 Jun 2016 02:15:09 +0900 import-checker: increase portability for python 2.6.x
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 19 Jun 2016 02:15:09 +0900] rev 29374
import-checker: increase portability for python 2.6.x Before this patch, fromlocalfunc() assumes that "module" attribute of ast.ImportFrom is None for "from . import a", and Python 2.7.x satisfies this assumption. On the other hand, with Python 2.6.x, "module" attribute of ast.ImportFrom is an empty string for "from . import a", and this causes failure of test-check-module-imports.t.
Fri, 17 Jun 2016 20:06:09 +0100 scmutil: allow access to filecache descriptor on class
Martijn Pieters <mjpieters@fb.com> [Fri, 17 Jun 2016 20:06:09 +0100] rev 29373
scmutil: allow access to filecache descriptor on class To make it easier to patch the wrapped function, make it possible to access the filecache descriptor directly on the class (rather than have to use ClassObject.__dict__['attributename']). Returning `self` when the first argument to `__get__` is `None` makes the descriptor behave the same way `property` objects do.
Fri, 17 Jun 2016 16:59:08 +0100 rebase: do not abort if all changesets have equivalents in the destination
Kostia Balytskyi <ikostia@fb.com> [Fri, 17 Jun 2016 16:59:08 +0100] rev 29372
rebase: do not abort if all changesets have equivalents in the destination
Thu, 16 Jun 2016 15:15:33 -0700 changegroup: don't send empty subdirectory manifest groups
Martin von Zweigbergk <martinvonz@google.com> [Thu, 16 Jun 2016 15:15:33 -0700] rev 29371
changegroup: don't send empty subdirectory manifest groups When grafting/rebasing, it is common for multiple changesets to make the same change to a subdirectory. When writing the revlog for the directory, the revlog code already takes care of not writing the entry again. In 0c2a088ffcc5 (changegroup: prune subdirectory dirlogs too, 2016-02-12), I added the corresponding code in changegroup (not sending entries the client already has), but I forgot to avoid sending the entire changegroup if no nodes remained in the pruned set. Although that's harmless besides the wasted network traffic, the receiving side was checking for it (copied from the changegroup code for handling files). This resulted in the client crashing with: abort: received dir revlog group is empty Fix by simply not emitting a changegroup for the directory if there were no changes is it. This matches how files are handled.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip