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

["Martin v. Löwis"]

> - First of all, I've got the basic conversion down, I've done it a few
> times now, with progressively better results. You can view some
> results at http://hg.python.org/, which has a preliminary cpython
> repository. *** The changeset hashes for that repo will change, so you
> won't be able to commit or pull from it in the future.***

I'd like to see as much infrastructure going "life" well in advance
of the switch over. Ideally, when we do switch, there should be no
surprises (i.e. all problems should be known, and, ideally, be
resolved).

> * Set up hg-ssh infra (should be easy)
> * Set up hooks (should be mostly straightforward)
> * Set up roundup integration (should be made easier by quick revision
> map hgweb extension)
> * Write docs

These are the ones that I was thinking of (and mentioned before, so
they got onto your list :-)

I would drop the roundup integration from the things that need to
be done pre-migration - there currently is no svn integration, so
not having it for hg is not a step backwards.

>     * buildbots: both the regular and the community build masters must
> be notified. Fortunately buildbot includes support for hg. I've also
> implemented this for Mercurial itself, so I don't expect problems
> here.

This should also be setup before the switchover, with a few test
buildslaves (say, a Unix one and a Windows one).

> In a DVCS, the committers are not necessarily the same
> people who push, and so we can't check if the committer is a
> contributor. We could use a hook to check if the committer is a
> contributor if we keep a list of registered contributors.

In the first sentence, you say that it can't actually work - so I
think we should drop the test.

> I propose that the revision identifier will be the short version of
> hg's revision hash, for example 'dd3ebf81af43', augmented with '+'
> (instead of 'M') if the working directory from which it was built was
> modified. This mirrors the output of the hg id command, which is
> intended for this kind of usage.

I would like to see this well before the switch also. It could be
a patch (unified diff) stored in the tracker, or it could be an actual
branch that then needs to get merged with all active branches (IIUC).

Regards,
Martin