[Python-Dev] Mercurial?

Sun Apr 5 19:37:53 CEST 2009

> I am not sure if it would be useful to convert the old branches to
> Mercurial. The simplest thing to do would be to keep the current svn
> repository as a read-only archive. And if people needs to commit to
> these branches, they could request the branch to be imported into a
> Mercurial branch (or a simple to use script could be provided and
> developer could run it directly on the server to create a user
> branch).

I think it should be stated in the PEP what branches get converted,
in what form, and what the further usage of the svn repository should
be.
> An auto-close would be a nice feature, but, as you said, not necessary
> for the migration. The main stumbling block to implement an auto-close
> feature is to define when an issue should be closed. Maybe we could
> add our own meta-data to the commit message. For example:
>> Fix some nasty bug.
>> Close-Issue: 4532
>> When a such commit would arrive in one of the main branches, a commit
> hook would close the issue if all the affected releases have been
> fixed.

I think there is a long tradition of such annotations; we should
try to repeat history here. IIUC, the Debian bugtracker understands
 Closes: #4532
and some other syntaxes. It must be easy to remember, else people
won't use it.
>>> - Setup temporary svn mirrors for the main Mercurial repositories.
>> What is that?
>>>> I think it would be a good idea to host a temporary svn mirrors for
> developers who accesses their VCS via an IDE. Although, I am sure
> anymore if supporting these developers (if there are any) would worth
> the trouble. So, think of this as optional.

Any decision to have or not have such a feature should be stated in
the PEP. I personally don't use IDEs, so I don't care (although
I do notice that the apparent absence of IDE support for Mercurial
indicates maturity of the technology)
>>> - Augment code.python.org infrastructure to support the creation of
>>> developer accounts.
>> One option would be to carry on with the current setup; migrating it
>> to hg might work as well, of course.
>>>> You mean the current setup for svn.python.org? Would you be
> comfortable to let this machine be accessed by core developers through
> SSH? Since with Mercurial, SSH access will be needed for server-side
> clone (or, a script similar to what the Mozilla folk have [1] could be
> added).
>> [1]: https://developer.mozilla.org/en/Publishing_Mercurial_Clones

Ok, I take that back. I assumed that Mercurial could work *exactly*
as Subversion. Apparently, that's not the case (although I have no
idea what a server-side clone is). So I wait for the PEP to explain
how authentication and access control is to be implemented. Creating
individual Unix accounts for committers should be avoided.
>> - integrate with the buildbot
>> Good one. It seems buildbot has support for Mercurial. [2] So, this
> will be a matter of tweaking the right options. The batch scripts in
> Tools/buildbot will also need to be updated.
>> [2]: http://djmitche.github.com/buildbot/docs/0.7.10/#How-Different-VC-Systems-Specify-Sources

I can give you access to the master setup. Ideally, this should
be tested before the switchover (with a single branch). We also
need instructions for the slaves (if any - perhaps installing
a hg binary is sufficient).
> Since the directories in /external are considered read-only, we could
> simply a new Mercurial repository and copy the content of /external in
> it.
>> - decide what to do with the bzr mirrors
>>>> I don't see much benefits to keep them.

Both should go into the PEP.
Regards,
Martin