[Python-Dev] Mercurial? (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Tue Apr 7 08:03:05 CEST 2009

Alexandre Vassalotti writes:

This makes me remember that we will have to decide how we will reorganize our workflow. For this, we can either be conservative and keep the current CVS-style development workflow--i.e., a few main repositories where all developers can commit to.

That was the original idea of PEP 374, that was a presumption under which I wrote my part of it, I think we should stick with it. As people develop personal workflows, they can suggest them, and/or changes in the public workflow needed to support them. But there should be a working sample implementation before thinking about changes to the workflow.

Simply allowing more people to work effectively offline is going to speed things up perceptibly. Improved branching will add to that impact. The current workflow is pretty clean. Let's not mess it up or all that will be achieved is to speed up the mess.

Or we could drink the kool-aid and go with a kernel-style development workflow--i.e., each developer maintains his own branch and pull changes from each others.

Can you give examples of projects using Mercurial that do that? All of the Mercurial projects I've seen "up close" have relatively centralized workflows, which Mercurial encourages because of the way it likes to automatically merge. I wouldn't want to try the kernel style with Mercurial because its named branch support doesn't work the way it should. In my experience, to deal with external branches, you have to maintain a separate workspace per external branch you want to follow.

You'd also need to provide a users' guide to things like rebasing, which become very important in a kernel-style workflow, but which the Mercurial developers opposed on principle, at least at first.

However if we go kernel-style, I will need to designate someone (i.e., an integrator) that will maintain the main branches, which will tested by buildbot and used for the public releases. These are issues I would like to address in the PEP.

IMHO, that's new PEP. This is not part of the PEP 374 decision to go to a dVCS, nor part of the requirements for implementation, whether that is considered an extension of 374 or a new PEP in itself.

More information about the Python-Dev mailing list