I'm not sure if it's intended to be a supported workflow, but I personally have come to like using "mq" for projects where I am an outsider submitting small changes as patches. However, this appears to be a broken workflow due to way getbuildinfo module choose to limit the buildinfo string to 50 characters:

$ hg qnew dummy-patch
$ echo "/* dummy change */" >> Modules/getbuildinfo.c
$ ./python -c 'import sys; print(sys.version)' 
3.3a0 (dummy-patch qbase qtip tip:191f047a07b4+, Mar  9 ) 
[GCC 4.4.5]

This breaks the platform module and therefore breaks the regrtest code, which makes it a show-stopper for using mq to manage your workflow. Is there any reason that length of buildinfo can't be chosen at compile-time based on the sizeof(HGTAG)?

I don't seem to be able to reproduce the failure in test_platform. Nevertheless, the behaviour is broken. Here's a patch that should fix it without allocating too much extra space.

Ah, now I see - the code that fails isn't test_platform, it's the regrtest code that prints out the version info at the beginning of the test results. This doesn't get displayed when you explicitly tell regrtest what tests to run ("./python [...] -m test test_platform"), which is why I didn't see it at first.

New changeset 0f9e5042907c by Antoine Pitrou in branch '3.1':
Issue #11450: Don't truncate hg version info in Py_GetBuildInfo() when
http://hg.python.org/cpython/rev/0f9e5042907c

New changeset 605c74139754 by Antoine Pitrou in branch '3.2':
Merge fix for issue #11450
http://hg.python.org/cpython/rev/605c74139754

New changeset 1e00b161f5f5 by Antoine Pitrou in branch 'default':
Merge fix for issue #11450
http://hg.python.org/cpython/rev/1e00b161f5f5

New changeset a7412744822d by Antoine Pitrou in branch '2.7':
Issue #11450: Don't truncate hg version info in Py_GetBuildInfo() when
http://hg.python.org/cpython/rev/a7412744822d

Thanks you for the patch! Fixed now.