[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    Re: [Python-Dev] Mercurial?
From:       "Stephen J. Turnbull" <stephen () xemacs ! org>
Date:       2009-04-07 5:58:27
Message-ID: 873aclt2zq.fsf () xemacs ! org
[Download RAW message or body]

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.

_______________________________________________
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/python-dev%40progressive-comp.com
[prev in list] [next in list] [prev in thread] [next in thread]