[Python-Dev] Decisions about workflow

[Nick Coghlan]

On Sun, Apr 3, 2011 at 4:25 AM, Laura Creighton <lac at openend.se> wrote:
> In a message of Sat, 02 Apr 2011 12:56:13 CDT, skip at pobox.com writes:
>>
>>    Laura> Sphinx lets you embed graphviz.
>>    Laura> http://sphinx.pocoo.org/ext/graphviz.html?highlight=image
>>
>>Cool, thanks.  I'm going to try to reproduce Nick's setup as he described
>>it.  That would certainly be a whole lot easy for me to understand,
>>hopefully for others as well.
>>
>>Skip
>
> *DEFINITELY* for me too!

I'll reproduce it in dodgy ASCII art here, but a real diagram would
definitely help in making the flow of changes clearer:

public sandbox (hg.python.org/sandbox/ncoghlan)
<=> (push and pull)
local sandbox
<= (pull only)
main repository (hg.python.org/cpython)
<=>
local py3k <=> local python27
<=>
local python32
<=>
local python31

Once python31 drops into security-fixes-only mode after the next
maintenance release, I'll likely ditch that local repository.

In the sandbox, I try to leave the default branch as a clean copy of
cpython#default (and ditto for the maintenance branches), with
anything I am working on off in a named branch (usually branched from
default, but I could also branch from an older maintenance branch,
such as 2.7, if the situation called for it).

Having the separate sandbox also allows me to defer the decision on
how far back to apply a change until such time as I am actually
committing the patch to the official repositories.

To commit a fix that applies to 2.7, 3.1 and all subsequent branches
is a matter of doing:

cd python27
hg import --no-commit patch-for-27.diff (I'm still trying to get in
the habit of using this over patch, though)
# build and test
hg commit -m "Fix #123456789: Feed the half a bee"
hg push
cd ../python31
hg import --no-commit patch-for-31.diff
# build and test
hg commit -m "Fix #123456789: Feed the half a bee"
hg push
cd ../python32
hg merge 3.1
# build and quick test
hg commit -m "Merge from 3.1. Fix #123456789"
hg push
cd ../py3k
hg merge 3.2
# build and quick test
hg commit -m "Merge from 3.2. Fix #123456789"
hg push

The final push uploads the whole thing to hg.python.org/cpython as a
single consistent block - no temporary unmerged heads are created on
the maintenance branches.

If someone else has committed changes in the meantime, then I need to
hg pull and merge the changes all the way back down the chain. (This
is somewhat annoying for a full 4-branch commit like the one shown,
but most commits aren't that bad. New features are only on default,
and a lot of other changes are 3.2+default only)

If using the "share" extension, you could drop all of the "hg push"
commands except the last one (since there is only one local repository
in that case, there aren't any push/pull commands needed to
synchronise things).

The other thing I like about this setup is that you can use it as a
basis to explain other possible approaches to managing your local
workflow:

- Using "mq" is essentially an alternative to having a separate local sandbox
- Using "share" means that python27/32/31 become additional working
copies attached to the py3k repository rather than local repositories
in their own right
- You can leave out python27/32/31 entirely, and just do a lot more
switching and rebuilding in the py3k directory

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia