Sun, 06 Dec 2015 22:12:07 -0800 tests/dumbhttp: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:12:07 -0800] rev 27282
tests/dumbhttp: use absolute_import
Sun, 06 Dec 2015 22:10:10 -0800 tests/autodiff.py: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:10:10 -0800] rev 27281
tests/autodiff.py: use absolute_import
Sun, 06 Dec 2015 22:07:13 -0800 tests/test-ancestor: use absolute_import
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:07:13 -0800] rev 27280
tests/test-ancestor: use absolute_import
Sun, 06 Dec 2015 22:39:12 -0800 tests: add test for Python 3 compatibility
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 06 Dec 2015 22:39:12 -0800] rev 27279
tests: add test for Python 3 compatibility Python 3 is inevitable. There have been incremental movements towards converting the code base to be Python 3 compatible. Unfortunately, we don't have any tests that look for Python 3 compatibility. This patch changes that. We introduce a check-py3-compat.py script whose role is to verify Python 3 compatibility of the files passed in. We add a test that calls this script with all .py files from the source checkout. The script currently only verifies that absolute_import and print_function are used. These are the low hanging fruits for Python compatbility. Over time, we can include more checks, including verifying we're able to load each Python file with Python 3. You have to start somewhere. Accepting this patch means that all new .py files must have absolute_import and print_function (if "print" is used) to avoid a new warning about Python 3 incompatibility. We've already converted several files to use absolute_import and print_function is in the same boat, so I don't think this is such a radical proposition.
Mon, 07 Dec 2015 18:06:13 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Mon, 07 Dec 2015 18:06:13 -0600] rev 27278
merge with stable
Sat, 05 Dec 2015 23:14:49 -0800 localrepo: reinstate localrepo.parents with a deprecation warning
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:14:49 -0800] rev 27277
localrepo: reinstate localrepo.parents with a deprecation warning The function was dropped in 3fe8cb40c9c5. This API drop brokes three of my extensions including some critical to my workflow like tortoisehg. Lets mark this API for death and give people time to fix their code.
Sat, 05 Dec 2015 23:34:07 -0800 bookmark: deprecate 'bmstore.write' method
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:34:07 -0800] rev 27276
bookmark: deprecate 'bmstore.write' method This function does not collaborate with the transaction and must disappear. As we have likely a lot of third party users, we make it deprecated to let them some time to upgrade their code. Thanks goes to Laurent Charignon for cleanup the last remains of the 'write' method.
Sat, 05 Dec 2015 23:05:49 -0800 ui: add a 'deprecwarn' helper to issue deprecation warnings
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:49 -0800] rev 27275
ui: add a 'deprecwarn' helper to issue deprecation warnings As discussed on the list, we are adding an official way to keep old API around for a short time in order to help third party developer to catch up. The deprecated API will issue developer warning (issued by default during test runs) to warn extensions authors that they need to upgrade their code without instantaneously breaking tool chains and normal users. The version is passed as an explicit argument so that developer think about it and a potential future script can automatically check for it. This is not build as a decorator because accessing the 'ui' instance will likely be different each time. The message is also free form because deprecated API are replaced in a variety of ways. I'm not super happy about the final rendering of that message, but this is a developer oriented warning and I would like to move forward.
Sat, 05 Dec 2015 23:05:33 -0800 ui: add a 'stacklevel' argument to 'develwarn'
Pierre-Yves David <pierre-yves.david@fb.com> [Sat, 05 Dec 2015 23:05:33 -0800] rev 27274
ui: add a 'stacklevel' argument to 'develwarn' This allows helper functions (like deprecation warning) to prepare a devel warning for higher up in the stack. The argument is named after the one in the Python's 'warning,warn' function.
Sun, 06 Dec 2015 14:28:35 +0900 import-checker: tell which symbol causes "direct symbol import"
Yuya Nishihara <yuya@tcha.org> [Sun, 06 Dec 2015 14:28:35 +0900] rev 27273
import-checker: tell which symbol causes "direct symbol import" This would be sometimes useful to understand why import-checker.py complains about it.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip