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

Stephen J. Turnbull stephen at xemacs.org
Fri Jul 3 15:29:41 CEST 2009


Dirkjan Ochtman writes:

 > Mercurial has two basic ways of using branches: cloned branches, where
 > each branch is kept in a separate repository, and named branches,
 > where each revision keeps metadata to note on which branch it belongs.
 > The former makes it easier to distinguish branches, at the expense of
 > requiring more disk space on the client. The latter makes it a little
 > easier to switch between branches, but often has somewhat unintuitive
 > results for people (though this has been getting better in recent
 > versions of Mercurial).

I'll have to try them again now that 1.3 is out, but I found Mercurial
named branches fundamentally unsuited to release management.

 > I'm still a bit on the fence about whether Python should adopt cloned
 > branches and named branches. Since it usually makes more sense to tag
 > releases on the maintenance branch, for example, mainline history
 > would not contain release tags if we used cloned branches.

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).

 > A disadvantage might be that the used clones will be a good bit larger
 > (since they essentially contain all other branches as well). This can
 > me mitigated by keeping non-release (feature) branches in separate
 > clones.

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

 > Also note that it's still possible to clone a single named
 > branch from a combined clone, by specifying the branch as in hg clone
 > http://hg.python.org/main/#2.6-maint.

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.

 > too many problems. For example, Mercurial itself just uses '1.2.1' as
 > a tag, where CPython would currently use r121.

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. :-)

 > code.python.org was also proposed as the hostname. Personally, I think
 > that using the VCS name in the hostname is good because it prevents
 > confusion: it should be clear that you can't use svn or bzr for
 > hg.python.org.

Agreed, although "can't" is a little too strong.  It might work (there
are a lot of places where http://ftp.example.com works just fine, for
example), but we don't want people to expect it to, and
"http://REPOHOST.python.org/" should take your browser or your client
to the official repo (which will be the hg repo), not to some index of
repos that happen to live on the same host.

 > Mercurial itself has a stable branch which is a ''strict'' subset of
 > the unstable branch.

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.

Note that PEP 374 was written on the assumption that the existing
workflow will *not* change until the committers have gotten used to
Mercurial, and then it will change in the natural way.  Ie, some one
will say, "you know, this bit of red tape isn't needed any more if we
do X, so let's do X", and after a cascade of 100*"+1 " we do X. :-)

Other than that, looks to be shaping up well.  (Note: I don't have any
comments on subversion-specific aspects, as XEmacs went directly from
CVS to Mercurial).


More information about the Python-Dev mailing list