Mon, 18 May 2015 15:38:24 -0500 recover: catch any exception, not just Exception
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 15:38:24 -0500] rev 25183
recover: catch any exception, not just Exception We want recover to be rock solid.
Mon, 18 May 2015 15:33:21 -0500 exchange: catch down to BaseException when handling bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 15:33:21 -0500] rev 25182
exchange: catch down to BaseException when handling bundle2 We can now catch more things.
Mon, 18 May 2015 13:23:14 -0500 bundle2: use BaseException in bundle2
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 13:23:14 -0500] rev 25181
bundle2: use BaseException in bundle2 We can ensure we fail over properly in more cases.
Mon, 18 May 2015 13:20:19 -0500 check-code: drop ban of BaseException
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 13:20:19 -0500] rev 25180
check-code: drop ban of BaseException Lets go back to the basic. It is available in Python 2.6.
Mon, 18 May 2015 13:25:07 -0500 wireproto: turn an 'except' into a 'finally' as suggest by the comment
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 13:25:07 -0500] rev 25179
wireproto: turn an 'except' into a 'finally' as suggest by the comment Look! More hidden footprints!
Mon, 18 May 2015 12:56:59 -0500 check-code: drop the yield inside try/finally ban
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 18 May 2015 12:56:59 -0500] rev 25178
check-code: drop the yield inside try/finally ban This is now possible with Python 2.6.
Mon, 18 May 2015 15:34:42 -0400 run-tests: resurrect the wifexited polyfill (backout 6ab5a1c9ea3c)
Matt Harbison <matt_harbison@yahoo.com> [Mon, 18 May 2015 15:34:42 -0400] rev 25177
run-tests: resurrect the wifexited polyfill (backout 6ab5a1c9ea3c) Python 2.7.3 on Windows doesn't have os.WIFEXITED, and the test output looked like this before I interrupted it. $ ./run-tests.py --local -j2 -t700 EEEEEEEEEEEEEEEEEEEEEE
Mon, 18 May 2015 02:53:08 +0900 tests: check import cycles in hgext/**.py, too
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:53:08 +0900] rev 25176
tests: check import cycles in hgext/**.py, too It is important to realize existing cycles in hgext/**.py.
Mon, 18 May 2015 02:52:58 +0900 import-checker: don't treat modules as relative one if not found
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:52:58 +0900] rev 25175
import-checker: don't treat modules as relative one if not found The previous patch ensures all module names are recorded in `imports` as absolute names, so we no longer need to treat modules as ones imported relatively from the target source if they appear to not be from the stdlib.
Mon, 18 May 2015 02:52:55 +0900 import-checker: make imported_modules yield absolute dotted_name_of_path
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 18 May 2015 02:52:55 +0900] rev 25174
import-checker: make imported_modules yield absolute dotted_name_of_path This patch makes `imported_modules()` always yield absolute `dotted_name_of_path()`-ed name by strict detection with `fromlocal()`. This change improves circular detection in some points: - locally defined modules, of which name collides against one of standard library, can be examined correctly For example, circular import related to `commands` is overlooked before this patch. - names not useful for circular detection are ignored Names below are also yielded before this patch: - module names of standard library (= not locally defined one) - non-module names (e.g. `node.nullid` of `from node import nullid`) These redundant names decrease performance of circular detection. For example, with files at 1ef96a3b8b89, average loops per file in `checkmod()` is reduced from 165 to 109. - `__init__` can be handled correctly in `checkmod()` For example, current implementation has problems below: - `from xxx import yyy` doesn't recognize `xxx.__init__` as imported - `xxx.__init__` imported via `import xxx` is treated as `xxx`, and circular detection is aborted, because `key` of such module name is not `xxx` but `xxx.__init__` - it is easy to enhance for `from . import xxx` style or so (in the future) Module name detection in `imported_modules()` can use information in `ast.ImportFrom` fully. It is assumed that all locally defined modules are correctly specified to `import-checker.py` at once. Strictly speaking, when `from foo.bar.baz import module1` imports `foo.bar.baz.module1` module, current `imported_modules()` yields only `foo.bar.baz.__init__`, even though also `foo.__init__` and `foo.bar.__init__` should be yielded to detect circular import exactly. But this limitation is reasonable one for improvement in this patch, because current `__init__` files in Mercurial seems to be implemented carefully.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip