[Python-Dev] Looking for VCS usage scenarios

[Gustavo Niemeyer]

Hi Brett,

> At this point I am looking for any suggestions for fundamental usage
> scenarios that I am missing from the PEP. If you think the few already
> listed are missing some core part of a VCS, please let me know.

As an initial disclaimer, I use bzr in my daily routine.  That said,
I'm sending below a few mostly unbiased high-level ideas, just based
on useful ways we explore the DVCS-aspect on our normal daily
workflow.

== Coordinated development with dependent features ==

A variation on coordinated development, which is actually one of the
main motivators for DVCS.  Branch A is evolving out of the mainline,
and it depends on a feature that is on branch B which is also not yet
integrated.  Parallel development of both should be nicely supported.
I'm sure all DVCS will do that in a decent form, but figuring how this
works may be instructive and worth mentioning.

== Centralization of feature-specific development ==

That's a curious one when we're talking about distributed development,
isn't it? :-)   Think about the following scenario: 5 people working
in parallel on a tricky feature which will take a while to get to the
mainline.  Each developer works on a specific aspect of the feature
for a few hours/days in their own branch, and then merges to and from
what's considered as the feature-mainline.  In essence, the problem is
that it's messy to just go towards the "everyone merges from everyone"
route when working in a common problem.  We've found that being able
to use an svn-like approach for the *feature* mainline (a branch that
is shared by all defining the status quo) is a handy way to handle
that.  I'm sure there are other approaches to solve the same problem,
but it's interesting to consider what they are for each tool since in
our experience the problem will show up eventually, and supporting it
nicely makes a big difference on the outcome.

== Attaching of history-carrying diffs ==

This one may feel weird as well, and I'm guessing some people might
react as "just send a URL to a branch".  In practice, it is handy many
times to just attach something to the bug tracker, for instance.  This
means that the "branch" is kept in the history of the bug.  Also, with
something like this, someone external to the development process may
very easily provide his changes in the bug or in a mail without having
to set up any infrastructure/accounts/whatever at all to provide his
branch.


That's it for now.  If I can think of any other use cases from our
routine that might serve as things to explore in such a comparison,
I'll let you know.

-- 
Gustavo Niemeyer
http://niemeyer.net