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
_______________________________________________
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
