[Python-Dev] Mercurial?

[Alexandre Vassalotti]

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