On Fri, 19 Nov 2010 12:41:58 -0500 Barry Warsaw <barry@python.org> wrote:
Really? I can understand this for security-only branches (commits there will be rare, and equivalent commits to the Mercurial branches can be made by others than the release managers, in order to keep history consistent).
But having the maintenance branches (by then, that will mostly be 2.7 because 3.1 will go to security-only mode soon) in SVN will be a burden for every developer, since they have to backport bugfixes from Hg to SVN...
Maybe I misremembered Martin's suggestion, and he was only talking about security releases. I think the key thing is whether you're going to backport the vcs related bits to stable releases.
It would be horribly burdensome to use two different VCSes depending on whether you're working on a bugfix branch or a feature branch.
I plan to only do releases for 2.6 from svn, because it's not worth breaking things like sys.subversion, and as you say the number of commits will be small.
But 2.6 is security-fixes only, right? It would really be annoying if the same rules applied for 2.7 and 3.1. I don't understand all the worry about sys.subversion. It's not like it's useful to anybody else than us, and I think it should have been named sys._subversion instead. There's no point in making API-like promises about which DVCS, bug tracker or documentation toolset we use for our workflow. Regards Antoine.