Georg and I have been working on converting the SVN repository to
Mercurial. We can now present you a test repository (actually, two).
CPython repository: http://hg.python.org/cpython/
This is the main conversion repository. It contains all history of
trunk and py3k (since 1990!) up to now, including all maintenance
branches starting from 2.0 up to 3.2.
If you are a core developer, get your local clone of the repository
$ hg clone ssh://email@example.com/cpython
(this uses the same SSH key as your Subversion access; for more
information about Mercurial and SSH keys, see the converted development
FAQ: http://potrou.net/hgdevguide/faq.html#faq )
If you are not a core developer:
$ hg clone http://hg.python.org/cpython
Your clone will contain the following branches:
$ hg branches
The branch "default" is the current py3k branch from SVN. The branch
"trunk" represents SVN trunk history until 2.7 was branched for
The full list of tags is too long to print here, but you can get it
$ hg tags
The size of the repository on-disk is (depending on your filesystem):
$ du -hs .hg
(the size of the network transfer is estimated to be around 80MB)
You can commit and even push to this repository (the latter if you are a
core developer). Since this is a test repository, whatever you push
will be discarded when we do the final conversion.
CPython with extra history: http://hg.python.org/cpythonextrahist/
This repository is bigger, and has a much more complicated topology. It
is a superset of the other repository, and contains the totality of the
branches from the SVN repository (it has more than 450 repository
heads, of which 87 non-closed). It also weighs quite a bit more:
$ du -hs .hg
This repository is unnecessary for development work, since even for
history-digging purposes the normal repository has the necessary
information. This repository is only to preserve historical record of
some of the non-trunk development work from the SVN repository (such
as orphaned/deleted feature branches).
Development guide: http://potrou.net/hgdevguide/
This is the development guide adapted for Mercurial. You can get its
sources from the branch "hg_transition" in
http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I was asking whether it would be useful to make a survey of past contributors, as in:
First, we did a survey of all our past developers who had left
the project, asking them why they had left. This was just a
free-form survey, allowing people to answer any way they wanted.
(from the quoted article in the thread linked above)
Since I didn't get any answer, I wonder if the idea simply got
overlooked, or if there's no need at all.
Is Rietveld or Review Board being used within the Python core development
community? I looked at the dev guide but didn't see anything obvious about
code reviews. I don't see how to search the Rietveld instance at
codereview.appspot.com looking just for Python core review requests.
My aim here is to provide some examples to a colleague at work. I wanted to
give him some examples related to code with which I'm familiar.
Some months ago, I proposed a patch to display the Python backtrace on a
segfault. The API was not stable, it was too for Python 3.2, and it was
enabled by default. I wrote a module instead of a patch so it can be
used on any version of Python, and it has a better API. And now I would
like to include the module into Python directly to use it more easily.
See http://bugs.python.org/issue11393 for the details. The module:
It is now possible to dump the backtrace on an user signal (eg. SIGUSR1)
or after a delay in seconds (it may be useful for buildbot hangs without
user interaction). You can choose to display the current thread or all
threads, and in which file the trace is written.
So, what do you think?
On Fri, Mar 4, 2011 at 2:10 AM, giampaolo.rodola
> Author: giampaolo.rodola
> Date: Thu Mar 3 17:10:51 2011
> New Revision: 88729
> Issue 11351 - apply patch by Steffen Daode Nurpmeso which should fix TestSendfile.test_headers failure on OSX.
NEWS entry and a new name in ACKS?
(the query regarding the lack of a NEWS entry applies to your other
recent commits as well).
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
I am looking at --help of test runner and asking the question: what is
the use case for -c, --catch option? It doesn't look like it should be
present in generic runner. I also can't find reasons to waste short
option for it. There will be big problems with people complaining
about BC break even if this option is not used by anyone.
Usage: tests.py [options] [test] [...]
-h, --help Show this message
-v, --verbose Verbose output
-q, --quiet Minimal output
-f, --failfast Stop on first failure
-c, --catch Catch control-C and display results
-b, --buffer Buffer stdout and stderr during test runs