[Python-Dev] Looking for VCS usage scenarios

[Brett Cannon]

On Thu, Nov 6, 2008 at 16:47, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 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:

Exactly. This is why I asked for only known scenarios we all run into
and every one of them has an example svn way of doing it.

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

Sort of covered.

> - backporting and forward porting patches between 3.x/3.x-1/2.y/2.y-1
> (current workflow based on svnmerge)

Covered.

> - developing and maintaining patches

Covered.

> - reviewing patches

Covered.

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

Covered.

-Brett