> 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/Publishing_Mercurial_Clones 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 _______________________________________________ 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
