Mercurial > hg
view tests/test-convert-cvs-synthetic.t @ 20742:3681de20b0a7
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.
author | Chris Jerdonek <chris.jerdonek@gmail.com> |
---|---|
date | Wed, 04 Dec 2013 20:38:27 -0800 |
parents | b349e476a622 |
children | 7a9cbb315d84 |
line wrap: on
line source
This feature requires use of builtin cvsps! $ "$TESTDIR/hghave" cvs112 || exit 80 $ echo "[extensions]" >> $HGRCPATH $ echo "convert = " >> $HGRCPATH create cvs repository with one project $ mkdir cvsrepo $ cd cvsrepo $ CVSROOT=`pwd` $ export CVSROOT $ CVS_OPTIONS=-f $ export CVS_OPTIONS $ cd .. $ cvscall() > { > cvs -f "$@" > } output of 'cvs ci' varies unpredictably, so just discard it $ cvsci() > { > sleep 1 > cvs -f ci "$@" >/dev/null > } $ cvscall -d "$CVSROOT" init $ mkdir cvsrepo/proj $ cvscall -q co proj create file1 on the trunk $ cd proj $ touch file1 $ cvscall -Q add file1 $ cvsci -m"add file1 on trunk" file1 create two branches $ cvscall -q tag -b v1_0 T file1 $ cvscall -q tag -b v1_1 T file1 create file2 on branch v1_0 $ cvscall -Q up -rv1_0 $ touch file2 $ cvscall -Q add file2 $ cvsci -m"add file2" file2 create file3, file4 on branch v1_1 $ cvscall -Q up -rv1_1 $ touch file3 $ touch file4 $ cvscall -Q add file3 file4 $ cvsci -m"add file3, file4 on branch v1_1" file3 file4 merge file2 from v1_0 to v1_1 $ cvscall -Q up -jv1_0 $ cvsci -m"MERGE from v1_0: add file2" cvs commit: Examining . Step things up a notch: now we make the history really hairy, with changes bouncing back and forth between trunk and v1_2 and merges going both ways. (I.e., try to model the real world.) create branch v1_2 $ cvscall -Q up -A $ cvscall -q tag -b v1_2 T file1 create file5 on branch v1_2 $ cvscall -Q up -rv1_2 $ touch file5 $ cvs -Q add file5 $ cvsci -m"add file5 on v1_2" cvs commit: Examining . create file6 on trunk post-v1_2 $ cvscall -Q up -A $ touch file6 $ cvscall -Q add file6 $ cvsci -m"add file6 on trunk post-v1_2" cvs commit: Examining . merge file5 from v1_2 to trunk $ cvscall -Q up -A $ cvscall -Q up -jv1_2 file5 $ cvsci -m"MERGE from v1_2: add file5" cvs commit: Examining . merge file6 from trunk to v1_2 $ cvscall -Q up -rv1_2 $ cvscall up -jHEAD file6 U file6 $ cvsci -m"MERGE from HEAD: add file6" cvs commit: Examining . cvs rlog output $ cvscall -q rlog proj | egrep '^(RCS file|revision)' RCS file: $TESTTMP/cvsrepo/proj/file1,v revision 1.1 RCS file: $TESTTMP/cvsrepo/proj/Attic/file2,v revision 1.1 revision 1.1.4.2 revision 1.1.4.1 revision 1.1.2.1 RCS file: $TESTTMP/cvsrepo/proj/Attic/file3,v revision 1.1 revision 1.1.2.1 RCS file: $TESTTMP/cvsrepo/proj/Attic/file4,v revision 1.1 revision 1.1.2.1 RCS file: $TESTTMP/cvsrepo/proj/file5,v revision 1.2 revision 1.1 revision 1.1.2.1 RCS file: $TESTTMP/cvsrepo/proj/file6,v revision 1.1 revision 1.1.2.2 revision 1.1.2.1 convert to hg (#1) $ cd .. $ hg convert --datesort proj proj.hg initializing destination proj.hg repository connecting to $TESTTMP/cvsrepo scanning source... collecting CVS rlog 15 log entries creating changesets 9 changeset entries sorting... converting... 8 add file1 on trunk 7 add file2 6 MERGE from v1_0: add file2 5 file file3 was initially added on branch v1_1. 4 add file3, file4 on branch v1_1 3 add file5 on v1_2 2 add file6 on trunk post-v1_2 1 MERGE from HEAD: add file6 0 MERGE from v1_2: add file5 hg log -G output (#1) $ hg -R proj.hg log -G --template "{rev} {desc}\n" o 8 MERGE from v1_2: add file5 | | o 7 MERGE from HEAD: add file6 | | o | 6 add file6 on trunk post-v1_2 | | | o 5 add file5 on v1_2 | | | | o 4 add file3, file4 on branch v1_1 | | | o | | 3 file file3 was initially added on branch v1_1. |/ / | o 2 MERGE from v1_0: add file2 |/ | o 1 add file2 |/ o 0 add file1 on trunk convert to hg (#2: with merge detection) $ hg convert \ > --config convert.cvsps.mergefrom='"^MERGE from (\S+):"' \ > --datesort \ > proj proj.hg2 initializing destination proj.hg2 repository connecting to $TESTTMP/cvsrepo scanning source... collecting CVS rlog 15 log entries creating changesets 9 changeset entries sorting... converting... 8 add file1 on trunk 7 add file2 6 MERGE from v1_0: add file2 5 file file3 was initially added on branch v1_1. 4 add file3, file4 on branch v1_1 3 add file5 on v1_2 2 add file6 on trunk post-v1_2 1 MERGE from HEAD: add file6 0 MERGE from v1_2: add file5 hg log -G output (#2) $ hg -R proj.hg2 log -G --template "{rev} {desc}\n" o 8 MERGE from v1_2: add file5 | | o 7 MERGE from HEAD: add file6 | | o | 6 add file6 on trunk post-v1_2 | | | o 5 add file5 on v1_2 | | | | o 4 add file3, file4 on branch v1_1 | | | o | | 3 file file3 was initially added on branch v1_1. |/ / | o 2 MERGE from v1_0: add file2 |/ | o 1 add file2 |/ o 0 add file1 on trunk