[Python-Dev] Mercurial?

[Alexandre Vassalotti]

On Sun, Apr 5, 2009 at 5:06 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>> Off the top of my head, the following is needed for a successful migration:
>>
>>    - Verify that the repository at http://code.python.org/hg/ is
>> properly converted.
>
> I see that this has four branches. What about all the other branches?
> Will they be converted, or not? What about the stuff outside /python?
>

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

> In particular, the Stackless people have requested that they move along
> with what core Python does, so their code should also be converted.
>

Noted.

>>    - Add Mercurial support to the issue tracker.
>
> Not sure what this means. There is currently svn support insofar as the
> tracker can format rNNN references into ViewCVS links; this should be
> updated if possible (removed if not). There would also be a possibility
> to auto-close issues from the commit messages. This is not done
> currently, so I would not make it a prerequisite for the switch.
>

Yes, I was referring to the rNNN references. Actually, I am not sure
how this could be implemented, since with Mercurial we lose atomic
revision IDs. We could use something like hash at branch-name (e.g,
bf94293b1932 at py3k) referring to specific revision.

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.

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

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

>>    - Update the release.py script.
>>
>> There is probably some other things that I missed
>
> Here are some:
>
> - 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

> - come up with a strategy for /external (also relevant for
>  the buildbot slaves)

Since the directories in /external are considered read-only, we could
simply a new Mercurial repository and copy the content of /external in
it. When a new release needs to be added, just create a new directory
and commit.

> - decide what to do with the bzr mirrors
>

I don't see much benefits to keep them. So, I say, archive the
branches there unless someone step-up to maintain them.

-- Alexandre