[Python-Dev] Decisions about workflow (original) (raw)
Nick Coghlan ncoghlan at gmail.com
Sun Apr 3 04:41:24 CEST 2011
- Previous message: [Python-Dev] Decisions about workflow
- Next message: [Python-Dev] Decisions about workflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Decisions about workflow
- Next message: [Python-Dev] Decisions about workflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]