R. David Murray writes: > On Tue, 7 Jul 2009 at 15:26, M.-A. Lemburg wrote:
> > I've seen a few discussions about this, but no final statement > > of what strategy to follow and whether hg makes this easier (AFAIR, > > that was the main argument for switching to hg). Yes, yes, yes, and no. In reverse order, no: the main argument for switching to hg is that it makes private branching easier. Yes: hg will make public branching easier, too, but that can't be proved until the workflow adjustments get worked out. For that reason, it is essential that the current workflow be supportable essentially without change, and it is. With respect to "how", I'm not a Mercurial geek, but I have been working with Mercurial queues a bit recently in another area, and I think they have some promise for helping organize the workflow. (Although by themselves they're clearly not sufficient, since they're oriented to a single branch.) Yes: there has been no final statement of what strategy to follow because opinions are extremely varied, even as to what is feasible with Mercurial. For example, Dirkjan and Georg want a workflow that makes moving patches among the public branches worry-free Mercurial merges. I believe that means (to the extent it is implemented) essentially gutting the current strategy of cutting maintenance branches and simply lagging the maintenance branches relative to the dev branches, and that it's infeasible for py3k vs. py2. I can't substantiate that; maybe the patch flow would support what they want, I'm not that familiar with how much patches currently morph across branches. And yes: there are a few inconclusive discussions. That's why PEP 374 was written consciously with the intent of postponing the hard issues of workflow across the public branches in favor of picking off the low hanging fruit of private branching and disconnected version control. > I think the main reason for switching was that it would make it easier > for non-core-committers to maintain branches and submit patches (as > changesets core committers can pull). Patches or "bundles" aka merge directives. "Pulling" submissions is probably not going to happen; that's a practice that is common with highly distributed workflows, but Python has a fairly centralized workflow. > but I think it remains to be proven/worked out. And I believe there is > no tool like svnmerge for tracking changesets to be merged, which could > be an issue that needs a resolution. I think that Mercurial queues or some related extension can be adapted to this, but I can't say for sure (after all, I was the git person on the PEP 374 team :-). > IIUC, the discussion about named versus cloned branches is part of > figuring out the workflow.... Peripherally. But actually it's not really relevant to workflow. Anything that can be done with named branches can be done with cloned branches, possibly requiring substantially more space. That discussion really is about whether anything is *lost* by using named branches. I worry that something is lost, but the discussion so far has been inconclusive. _______________________________________________ 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
