Sun, 01 Dec 2013 18:26:42 -0200 i18n-pt_BR: synchronized with 734ff413eb7e stable
Wagner Bruna <wbruna@yahoo.com> [Sun, 01 Dec 2013 18:26:42 -0200] rev 20157
i18n-pt_BR: synchronized with 734ff413eb7e
Sun, 01 Dec 2013 14:10:53 -0600 merge with stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Dec 2013 14:10:53 -0600] rev 20156
merge with stable
Fri, 29 Nov 2013 12:36:28 -0800 parsers: fail fast if Python has wrong minor version (issue4110)
Chris Jerdonek <chris.jerdonek@gmail.com> [Fri, 29 Nov 2013 12:36:28 -0800] rev 20155
parsers: fail fast if Python has wrong minor version (issue4110) This change causes an informative ImportError to be raised when importing the extension module parsers if the minor version of the currently-running Python interpreter doesn't match that of the Python that was used when compiling the extension module. 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 will result in a better user experience in cases like the above. The information in the ImportError will also simplify 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.
Sun, 01 Dec 2013 13:53:24 -0600 hgk: fix tag list parser (issue4101) stable
Andrew Shadura <andrew@shadura.me> [Sun, 01 Dec 2013 13:53:24 -0600] rev 20154
hgk: fix tag list parser (issue4101) As tags may have embedded spaces, and "hg tags" command doesn't escape them, the output of the command doesn't make a well-formed list, so we can't just iterate over it. Instead, apply a simple regexp to transform it to a list which we actually use. Line boundary matching should be enabled.
Sun, 01 Dec 2013 13:45:00 -0600 merge with i18n stable
Matt Mackall <mpm@selenic.com> [Sun, 01 Dec 2013 13:45:00 -0600] rev 20153
merge with i18n
Wed, 27 Nov 2013 22:47:32 +0900 i18n: add the tool to check Mercurial specific translation problems in *.po stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 27 Nov 2013 22:47:32 +0900] rev 20152
i18n: add the tool to check Mercurial specific translation problems in *.po Existing tool like "msgfmt --check" can check typical translation problems (missing "%s" in msgstr, for example), but can't check Mercurial specific ones. For example, "msgfmt --check" can't check whether the translated string given to "ui.promptchoice()" is correct or not, even though problems like below cause run-time error or unexpected behavior: - less or more choices than msgid, - choices without '&', or - choices with '&' followed by none This patch adds the tool to check Mercurial specific translation problems in *.po files.
Wed, 27 Nov 2013 22:32:01 +0100 help: fix backwards bisect help example stable
Santiago Pay=C3=A0 i Miralta <santiagopim@gmail.com> [Wed, 27 Nov 2013 22:32:01 +0100] rev 20151
help: fix backwards bisect help example
Tue, 26 Nov 2013 16:30:52 -0800 unshelve: add tests for unknown files stable
Durham Goode <durham@fb.com> [Tue, 26 Nov 2013 16:30:52 -0800] rev 20150
unshelve: add tests for unknown files Adds a basic test for shelving/unshelving with an unknown file present. Adds a test for unshelving on top of an existing unknown file.
Tue, 26 Nov 2013 16:23:05 -0800 unshelve: don't commit unknown files during unshelve (issue4113) stable
Durham Goode <durham@fb.com> [Tue, 26 Nov 2013 16:23:05 -0800] rev 20149
unshelve: don't commit unknown files during unshelve (issue4113) Previously, unshelve would temporarily commit unknown files (via addremove) in an attempt to allow unshelving into unknown files. This produced unexpected results, like the file time stamp changing and a .i file being created. This change makes it no longer use addremove. It ignores unknown files completely. If an unshelve would overwrite an unknown file, the unknown file is moved to *.orig The shelve continue/abort format is changed, but it just removes stuff from the end of the file, so it can still read the old format.
Tue, 26 Nov 2013 15:38:33 +0100 largefiles: don't crash on 'local renamed directory' actions stable
Mads Kiilerich <madski@unity3d.com> [Tue, 26 Nov 2013 15:38:33 +0100] rev 20148
largefiles: don't crash on 'local renamed directory' actions a12798938721 introduced splitstandin on all action filenames. It would however crash on 'd' actions where the filename is None. Fix that and add test coverage for that case.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip