[Python-Dev] Submitting changes through Mercurial

[Nick Coghlan]

On Wed, Mar 23, 2011 at 1:37 AM,  <skip at pobox.com> wrote:
> Doesn't that just complicate my setup?  Let's just consider the cpython repo
> (is that the right term? maybe branch instead?).  Today, I have a local
> repository named "cpython" which refers to ssh://hg@hg.python.org/cpython as
> its default.  Now you suggest I need to create another public repository.
> So my "chain of command" becomes: local depends on my global, which depends
> on the real cpython global.  Now replicate that for the different active
> branches (2.7, 3.2 at least).

Yes and no.

Historically, you had your local working copy of the SVN repository,
probably a few other working copies for the different maintenance
branches, and then a whole pile of patches for works in progress. If
you had a long running branch you wanted to work on, you probably had
a separate working copy for that as well. A lot of the patches were
probably made publicly available to others by posting them on a
tracker item.

Now, consider my own current hg setup (which I'm reasonably happy with so far):

I have 4 "clean" local repositories which correspond to the active
hg.python.org/cpython branches: py3k=default, python32=3.2,
python31=3.1 and python27=2.7
Of those 4, only py3k actually points at the server by default - the
others either point to py3k (python32, python27) or to python32
(python31).
I have a simple shell script that steps through all 4 branches doing a
"hg pull -u"

This part really isn't all that different from what I had with SVN,
except that it is all a *lot* faster, since everything happens locally
aside from the push/pull steps between my py3k repo and
hg.python.org/cpython.

The big difference is that I now only work in these repositories if I
am getting ready to commit something. Otherwise, I work in a separate
local repository: sandbox.

My public sandbox is a server-side clone of cpython that lives at
hg.python.org/sandbox/ncoghlan
I create feature branches there to work on things that I am developing
myself (when applying patches created by others I'll work in the main
repos)
The default, 3.2, 3.1, etc branches are exact mirrors of the
corresponding branches in cpython
I have an alias set up in .hgrc so that "hg pull cpython" will bring
my sandbox repo up to speed with the latest changes to the main
repository
By pushing changes to my public sandbox, they're not only available
for others to see, but also allow me to easily keep my desktop and
laptop in sync
A simple "hg diff -r default" (or "-r 3.2" etc) from one of my named
branches gives me a patch file I can then import into the main
repositories, ready to commit

I have no need to maintain multiple sandbox repositories, since I just
switch between branches and rebuild as necessary.

Once the named branch support in the roundup integration is working,
I'll never need to manually publish a patch to the tracker again -
I'll just point roundup at the appropriate named branch in my sandbox
and hit the "create patch" button.

And the most interesting part of all this? Someone without push rights
can use the *exact same workflow*, with the only difference being that
their sandbox would be somewhere like bitbucket or Google code, rather
than on hg.python.org.

Instead of dead patches living on the tracker, we instead have
significantly easier to update live branches living in cloned
repositories.

Cheers,
Nick.

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