On Sun, Nov 2, 2008 at 17:08, Gustavo Niemeyer <[EMAIL PROTECTED]> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
