[Python-Dev] Looking for VCS usage scenarios (original) (raw)

Gustavo Niemeyer gustavo at niemeyer.net
Mon Nov 3 02:08:11 CET 2008

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

More information about the Python-Dev mailing list