On Sun, Apr 3, 2011 at 4:25 AM, Laura Creighton <l...@openend.se> wrote: > In a message of Sat, 02 Apr 2011 12:56:13 CDT, s...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
