stephen at xemacs
Jul 7, 2009, 7:19 PM
Post #81 of 83
(706 views)
Permalink
|
|
Re: Mercurial migration: progress report (PEP 385)
[In reply to]
|
|
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 [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com
|
