[Python-Dev] Looking for VCS usage scenarios
brett at python.org
Mon Nov 3 18:57:26 CET 2008
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
> == 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
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.
More information about the Python-Dev