On Mon, Nov 3, 2008 at 10:35, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On Mon, Nov 3, 2008 at 18:57, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> 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. > > Euhm, wut? It hasn't come up during Python's development because Python is > being developed in a VCS with very limited branches :) I'm partial to VCS's > with proper branching (as you know) and I've been using that mode of > development for many years. I've done development and maintenance of > multi-developer projects using both the CVS/SVN nonbranching approach and > the typical DVCS branch-often approach using BitKeeper, Bazaar and Mercurial > (as well as the sort-of one-off-branch Perforce approach where you can > easily 'wrap' a single change but can't really do dependant changes) -- and > whenever possible I use the branch-often approach with dependant branches > all over the place, especially when working on large, complicated changes. > Building them up out of separate 'components' requires a little more > administration (you have to remember which branch to submit to) but it makes > debugging, piecemeal discussion and batchwise integration a *lot* easier. >
I know it isn't used because of what VCSs we have used, which is why I have no experience with it and feel uncomfortable using it as a necessary usage scenario to evaluate whether a DVCS is better than svn, and if so which one. But then again, having one scenario that shows svn's weakness directly wouldn't hurt. I could see a scenario where I start to fix something in branch A, realize that a deeper issue needs to be fixed, leading to branch B, and then have branch A depend on branch B. Is that possible? Or is injecting branch dependencies like that not workable? If it doesn't work, then a branch A/B that a branch C is dependent on would also work as a scenario (e.g. reworking the testing framework where you are doing a bunch of different things at once that are culminating in a single new testing branch that collects everything). Those sound like what you are getting after? -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
