[Python-Dev] Mercurial? (original) (raw)

"Martin v. Löwis" martin at v.loewis.de
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/PublishingMercurialClones

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

More information about the Python-Dev mailing list