[Python-Dev] Mercurial migration: progress report (PEP 385)

[Dirkjan Ochtman]

On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull<stephen at xemacs.org> wrote:
> I'll have to try them again now that 1.3 is out, but I found Mercurial
> named branches fundamentally unsuited to release management.

Can you explain why, please? It's not clear from what you say below.

> Ditto named branches.  The problem is that (unless the internal
> implementation has changed very recently) a Mercurial revision can be
> on exactly one named branch (or on the trunk).

That's still true.

> Which defeats the purpose of having named branches, really.  (I mean
> the version control purpose; obviously it still can save disk space.)

Why does it defeat the purpose? What, in your opinion, is the purpose?

> Unless you're really short on space, though, that's not a big deal.
> What would be more important to me (not that I matter for the purpose
> of Python, but in XEmacs -- also a Mercurial shop -- I do :-) would be
> the other way around: pulling an external branch into a named branch.
> I have a feeling that working with such a repository with others would
> be a little difficult.

Can you give an example?

> Stick with the CPython notation.  At XEmacs, continuity of tags has
> made our beta testers happy.  (Well, the two of them who bothered to
> mention it, anyway. :-)

Right; Benjamin also mentioned that processing the tags just to be
consistent with the recent tagging scheme would probably be the best
solution.

> As others (MvL, I think) have commented, this isn't really relevant to
> Python which generally has four mainlines going at once.  I don't see
> why the requirements are going to change with the shift to hg, and I
> see no reason why hg won't handle the existing workflow just fine.

It will handle it, for sure, but I think it would all go easier if we
could work with stricter subset branches (and leave the effective
cherrypicking for the occasional problem).

Cheers,

Dirkjan