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

Alexandre Vassalotti alexandre at peadrop.com
Mon Apr 6 06:06:15 CEST 2009

On Sun, Apr 5, 2009 at 1:37 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:

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.

Noted.

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.

That should reasonable. Personally, I don't really care about the syntax we would use as long its consistent and documented.

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)

I know Netbeans has Mercurial support built-in (which makes sense because Sun uses Mercurial for its open-source projects). However, I am not sure if Eclipse has good Mercurial support yet. There are 3rd-party plugins for Eclipse, but I don't know if they work well.

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.

With Subversion, we can do a server-side clone (or copy) using the copy command:

svn copy SRC_URL DEST_URL

This prevents wasting time and bandwidth by doing the copy directly on server. Without this feature, you would need to checkout the remote repository to clone, then push it to a different location. Since upload bandwidth is often limited, creating new branch in a such fashion would be time consuming.

With Mercurial, we will need to add support for server-side clone ourselves. There's few ways to provide this feature. We give Unix user accounts to all core developers and let developers manages their private branches directly on the server. You made clear that this is not wanted. So an alternative approach is to add a interface accessible via SSH. As I previously mentioned, this is the approach used by Mozilla.

Yet another approach would be to add a web interface for managing the repositories. This what OpenSolaris admins opted for. Personnally, I do not think this a good idea because it would requires us to roll our own authentication mechanism which is clearly a bad thing (both security-wise and usability-wise).

This makes me remember that we will have to decide how we will reorganize our workflow. For this, we can either be conservative and keep the current CVS-style development workflow—i.e., a few main repositories where all developers can commit to. Or we could drink the kool-aid and go with a kernel-style development workflow—i.e., each developer maintains his own branch and pull changes from each others.

From what I have heard, the CVS-style workflow has a lower overhead than the kernel-style workflow. However the kernel-style workflow somehow advantageous because changes get reviewed several times before they get in the main branches. Thus, it is less likely that someone manage to break the build. In addition, Mercurial is much better suited at supporting the kernel-style workflow.

However if we go kernel-style, I will need to designate someone (i.e., an integrator) that will maintain the main branches, which will tested by buildbot and used for the public releases. These are issues I would like to address in the PEP.

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

I am not too familiar with our buildbot setup. So, I will to do some reading before actually doing any change. You can give me access to the buildbot master now. However, I would use this access only to study how the current setup works and to plan the changes we need accordingly.

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.

Noted.

Regards, -- Alexandre

More information about the Python-Dev mailing list