[Python-Dev] Mercurial?

["Martin v. Löwis"]

> 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