Wed, 19 Feb 2014 09:28:17 -0800 revset: added min and max methods to baseset and lazyset
Lucas Moscovicz <lmoscovicz@fb.com> [Wed, 19 Feb 2014 09:28:17 -0800] rev 20748
revset: added min and max methods to baseset and lazyset This classes have no particular order so they rely on python min() and max() implementation. This methods will be implemented in every smartset class in future patches. For other classes there are lazy implementations that can be made for this methods.
Fri, 14 Mar 2014 15:47:29 -0700 contrib: make revset benchmark script able to read from stdin
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 15:47:29 -0700] rev 20747
contrib: make revset benchmark script able to read from stdin This help fine control of what we want to benchmark
Fri, 14 Mar 2014 15:43:55 -0700 contrib: have the revset benchmark test script take a revset
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 15:43:55 -0700] rev 20746
contrib: have the revset benchmark test script take a revset The script now selection revision to run benchmark against using a revset query instead of a revision range. It is expected that people benchmarking revset have some knowledge of revset.
Fri, 14 Mar 2014 11:24:59 -0700 contrib: added revset performance benchmarking script
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 11:24:59 -0700] rev 20745
contrib: added revset performance benchmarking script This script takes two arguments (starting revision, ending revision) and tests for each revision in between the entire list of revsets in the script using perfrevset.
Fri, 14 Mar 2014 15:00:15 -0700 contrib: added revset examples for benchmarking performance
Lucas Moscovicz <lmoscovicz@fb.com> [Fri, 14 Mar 2014 15:00:15 -0700] rev 20744
contrib: added revset examples for benchmarking performance Added list of revsets used for benchmarking revset performance so far.
Mon, 17 Feb 2014 07:39:53 +0100 help: filter out deprecated options with untranslated descriptions
Simon Heimberg <simohe@besonet.ch> [Mon, 17 Feb 2014 07:39:53 +0100] rev 20743
help: filter out deprecated options with untranslated descriptions When using a different language than English, deprecated options were only removed from the output of `hg help anycmd` when "DEPRECATED" in the options description was translated.
Wed, 04 Dec 2013 20:38:27 -0800 parsers: fail fast if Python has wrong minor version (issue4110)
Chris Jerdonek <chris.jerdonek@gmail.com> [Wed, 04 Dec 2013 20:38:27 -0800] rev 20742
parsers: fail fast if Python has wrong minor version (issue4110) This change causes an informative ImportError to be raised when importing the parsers extension module if the minor version of the currently-running Python interpreter doesn't match that of the Python used when compiling the extension module. This change also exposes a parsers.versionerrortext constant in the C implementation of the module. Its presence can be used to determine whether this behavior is present in a version of the module. The value of the constant is the leading text of the ImportError raised and is set to "Python minor version mismatch". Here is an example of what the new error looks like: Traceback (most recent call last): File "test.py", line 1, in <module> import mercurial.parsers ImportError: Python minor version mismatch: The Mercurial extension modules were compiled with Python 2.7.6, but Mercurial is currently using Python with sys.hexversion=33883888: Python 2.5.6 (r256:88840, Nov 18 2012, 05:37:10) [GCC 4.2.1 Compatible Apple Clang 4.1 ((tags/Apple/clang-421.11.66))] at: /opt/local/Library/Frameworks/Python.framework/Versions/2.5/Resources/ Python.app/Contents/MacOS/Python The reason for raising an error in this scenario is that Python's C API is known not to be compatible from minor version to minor version, even if sys.api_version is the same. See for example this Python bug report about incompatibilities between 2.5 and 2.6+: http://bugs.python.org/issue8118 These incompatibilities can cause Mercurial to break in mysterious, unforeseen ways. For example, when Mercurial compiled with Python 2.7 was run with 2.5, the following crash occurred when running "hg status": http://bz.selenic.com/show_bug.cgi?id=4110 After this crash was fixed, running with Python 2.5 no longer crashes, but the following puzzling behavior still occurs: $ hg status ... File ".../mercurial/changelog.py", line 123, in __init__ revlog.revlog.__init__(self, opener, "00changelog.i") File ".../mercurial/revlog.py", line 251, in __init__ d = self._io.parseindex(i, self._inline) File ".../mercurial/revlog.py", line 158, in parseindex index, cache = parsers.parse_index2(data, inline) TypeError: data is not a string which can be reproduced more simply with: import mercurial.parsers as parsers parsers.parse_index2("", True) Both the crash and the TypeError occurred because the Python C API's PyString_Check() returns the wrong value when the C header files from Python 2.7 are run with Python 2.5. This is an example of an incompatibility of the sort mentioned in the Python bug report above. Failing fast with an informative error message results in a better user experience in cases like the above. The information in the ImportError also simplifies troubleshooting for those on Mercurial mailing lists, the bug tracker, etc. This patch only adds the version check to parsers.c, which is sufficient to affect command-line commands like "hg status" and "hg summary". An idea for a future improvement is to move the version-checking C code to a more central location, and have it run when importing all Mercurial extension modules and not just parsers.c.
Fri, 14 Mar 2014 16:00:11 -0500 debuginstall: change showing to checking for consistency and future checking
Matt Mackall <mpm@selenic.com> [Fri, 14 Mar 2014 16:00:11 -0500] rev 20741
debuginstall: change showing to checking for consistency and future checking
Tue, 31 Dec 2013 00:37:16 -0800 debuginstall: add Python information to debuginstall output (issue4128)
Chris Jerdonek <chris.jerdonek@gmail.com> [Tue, 31 Dec 2013 00:37:16 -0800] rev 20740
debuginstall: add Python information to debuginstall output (issue4128) This change adds to the output of "hg debuginstall" information about the Python being used by Mercurial. It adds both the path to the Python executable (i.e. the value of sys.executable) and the version of Python (specifically the major, minor, and micro versions). Below is an example of what the output looks like after this change. The marked lines are the new output lines: $ hg debuginstall checking encoding (UTF-8)... -->showing Python executable (/Users/chris/.virtualenvs/default/bin/python) -->showing Python version (2.7.6) checking Python lib (/Users/chris/.virtualenvs/default/lib/python2.7)... checking installed modules (/Users/chris/mercurial)... checking templates (/Users/chris/mercurial/templates)... checking commit editor... checking username... no problems detected Note that we use the word "showing" without an ellipsis for the new lines because, unlike the other lines (except for "Python lib" which will be adjusted in a subsequent commit), no check follows the display of this information.
Fri, 14 Mar 2014 10:57:04 -0700 revset: add documentation and comment for _generatorset
Pierre-Yves David <pierre-yves.david@fb.com> [Fri, 14 Mar 2014 10:57:04 -0700] rev 20739
revset: add documentation and comment for _generatorset (clean up some old irrelevant comment in the process)
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip