[Python-Dev] Using feature branches for local development

"Martin v. Löwis" martin at v.loewis.de
Sun Mar 13 13:47:29 CET 2011


Am 13.03.11 07:25, schrieb Nick Coghlan:
> I'm experimenting with creating some local branches for things I'd
> like to work on during the sprints this week, and have a couple of
> questions about the associated workflow.
>
> 1. While the feature branches are active, is it correct that I can't
> use a bare "hg push" any more, since I don't want to push the feature
> branches to hg.python.org?

Despite what anybody told so far: yes, you can continue to use a bare
"hg push". In the clone, edit .hg/hgrc, and have "default" point to the
remote repository you want to push to. As the remote repository, you
can use one of those you created with a remote clone.

If you want to continue to pull from cpython to merge upstream
changes, set up a default-push path in .hg/hgrc. Then pull will
get incoming changes cpython, outgoing changes go to the sandbox
repository.

> 2. Once I'm done with the feature branch, I need to nuke it somehow
> (e.g. by enabling the mq extension to gain access to "hg strip"
> command)

I think this will need reconsidertion. Apparently, the recommendation
is that you need to flatten all changes into a single commit when
integrating is. The way I would do it is to produce a diff, and apply
a patch to cpython. One way of producing the patch is to use "hg 
outgoing", another is to use a named branch in your clone and do
"hg diff default feature".

The mercurial-recommended way is that you just push your changes to 
cpython when done, which puts all your individual commits into Python's 
history.

I tried to find an official statement on which way it should be in the 
devguide, but couldn't find anything.

Regards,
Martin


More information about the Python-Dev mailing list