[Python-Dev] Looking for VCS usage scenarios

[Nick Coghlan]

Barry Warsaw wrote:
> On Nov 5, 2008, at 8:36 PM, Stephen J. Turnbull wrote:
> 
>> You need not feel that way.  It's not you---the flexibility of dVCS
>> means that until the Powers That Be promulgate a Workflow, this will
>> be ambiguous.
> 
> You're absolutely right.  Adopting a dvcs opens up a much larger world
> of possible workflows and best practices, both for an individual and for
> a project.  It's a case of too much choice, so I feel strongly that
> Python should adopt and explain exactly one preferred workflow that will
> work for most people and use cases.  People can still experiment and
> find alternatives if they want.

This is an area where I think the initial DVCS PEP shouldn't be too
ambitious, and focus mainly on the improvements to things we currently
do with Subversion and Roundup:
- individuals suspending work on one task (e.g. a new feature) to switch
to something else (e.g. fixing a bug) (current workflow is multiple
checkouts or dumping your first task in a patch file, reverting, working
on the second task, dumping or committing it, then patching back to the
first task)
- backporting and forward porting patches between 3.x/3.x-1/2.y/2.y-1
(current workflow based on svnmerge)
- developing and maintaining patches
- reviewing patches
- collaboration amongst multiple developers on complex patches (current
workflow is either forking the standard library and creating a project
in the sandbox or somewhere else like Google Code, or else posting and
downloading a series of patches on the tracker, or, if all developers
involved have SVN access, creating a SVN branch and maintaining it with
SVN merge)

There's a lot of room for improvement just in those areas, even before
we start getting into the potential alternate workflows that a DVCS may
enable.

Cheers,
Nick.

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