[Python-Dev] Looking for VCS usage scenarios

[Brett Cannon]

On Sun, Nov 2, 2008 at 17:08, Gustavo Niemeyer <gustavo at niemeyer.net> wrote:
> 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.
>

Since I have never seen that come up during Python's development I am
going to leave it out. But I do see the benefit and how it might help
with future work.

> == 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.
>

This one is covered already.

> == 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.

As I mentioned in the doc, the first example allows for whatever the
DVCS does for diffs, whether that is a full-on branch or not.

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

Thanks, Gustavo!

-Brett