On Sun, Apr 5, 2009 at 5:06 AM, "Martin v. Löwis" <mar...@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 h...@branch-name (e.g, bf94293b1...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com