The devguide recommends using hg update to switch between branches in one repository. This is only practical if you build Python in a custom (sub)directory, otherwise you’d need to either do the configure-make-test dance when merging/porting patches, or skip testing. I’ve always used one clone per Python version, where I can keep the compiled artifacts; it makes it easy to see what a file looks like in any of the three versions, easy to work on different things in the different repos (like fixing something in 3.2 that you noticed while you were adding something to 3.3), it is cheap thanks to hardlinks, fast because you run hg pull instead of hg update to merge a patch from 3.2, and is just the simplest thing that works. I don’t think anyone uses the one-clone-with-update approach, so I think we should rewrite the instructions to talk about one clone per version.
nosy: eric.araujo, ezio.melotti, ncoghlan, pitrou
title: Update cloning guidelines in devguide
I agree, for reasons stated. Having to skip over the wrong instructions made getting started a bit harder for me. I also think TortoiseHG should get more than just a mention. The initial re-creation of the recent DAG for each branch when starting up Workbench takes some time, but having the graph makes it immediately obvious whether the repository is in a proper state -- two heads for default and 2.7, three for 3.2 -- both before starting work after pulling from py.org and again when ready to push changes back.
It is important to note that if you have a 'cpython' as a clone (which pulls and pushed to hg.python.org) and from it you clone '2.7' and '3.2' (as I think it's the most common setup) you first have to pull from cpython and then on the other 2.
Anyhow, is anyone up for preparing a patch? else I'll happily work on it in the coming days.