Draft PEP 385: Migrating from svn to Mercurial
So, a while ago Martin von Löwis asked who would champion the migration to Mercurial, and I volunteered. He asked me to produce a PEP outlining which steps to take, which I've been working on. The PEP is numbered 385, and is just about ready for your review. I'd really welcome any sort of feedback or questions about Mercurial and surrounding tools relevant to the migration project (I'm happy to answer other questions as well, but maybe python-dev is not the appropriate forum for that -- instead, try mercurial@selenic.com and/or #mercurial on freenode). http://www.python.org/dev/peps/pep-0385/ In particular, you may want to review (a) branches that you care about and whether they would be migrated under the current proposal, (b) non-release tags that you think are useful and (c) the author map (check if it has a correct email address for you and people you know). Thanks to Antoine, Benjamin, Georg and Martin for early feedback. Cheers, Dirkjan
2009/6/5 Dirkjan Ochtman <dirkjan@ochtman.nl>:
In particular, you may want to review (a) branches that you care about and whether they would be migrated under the current proposal, (b) non-release tags that you think are useful and (c) the author map (check if it has a correct email address for you and people you know).
Thanks very much for doing this! The PEP should talk about tracker migration. ie. how to handle specifying revisions on multiple clones if we choose that path. -- Regards, Benjamin
Dirkjan Ochtman <dirkjan <at> ochtman.nl> writes:
« [cloned branches] makes it easier to distinguish branches, at the expense of requiring more disk space on the client. » This is a bit misleading. Actually, by separating branches into distinct repositories, you can save quite a bit of repository space. It really depends on the structure of the project and your own workflow. « This reflects that the default branch in hg is called 'default' instead of Subversion's 'trunk', and reflects the proposed new tag format. » If we use several distinct repositories, the default branch should instead mirror the repository name (like what is done in the current hg mirrors: "trunk", "py3k", etc.). Regards Antoine.
Antoine Pitrou schrieb:
Dirkjan Ochtman <dirkjan <at> ochtman.nl> writes:
« [cloned branches] makes it easier to distinguish branches, at the expense of requiring more disk space on the client. »
This is a bit misleading. Actually, by separating branches into distinct repositories, you can save quite a bit of repository space. It really depends on the structure of the project and your own workflow.
If you follow the "strict-subset" policy (which I would strongly recommend, from my experience) you'll end up with both branches in the trunk repo anyway.
« This reflects that the default branch in hg is called 'default' instead of Subversion's 'trunk', and reflects the proposed new tag format. »
If we use several distinct repositories, the default branch should instead mirror the repository name (like what is done in the current hg mirrors: "trunk", "py3k", etc.).
+1. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
At PyCon, we discussed moving Jython's svn repository to Python's with Martin von Löwis. I would think that Jython would live in Python's hg repository in the same way as stackless and distutils. Has the parallel project strategy been determined? Will they be separate repositories, separate "forests", something else? Also, Martin suggested we migrate to Python's svn and then go along for the svn->hg ride. Does that still make sense now that some planning has been done? -Frank
Frank Wierzbicki schrieb:
At PyCon, we discussed moving Jython's svn repository to Python's with Martin von Löwis. I would think that Jython would live in Python's hg repository in the same way as stackless and distutils. Has the parallel project strategy been determined? Will they be separate repositories, separate "forests", something else?
It should definitely be a separate repository, repositories tend to be a smaller unit in hg than in SVN, due to the fact that partial clones/checkouts are not supported.
Also, Martin suggested we migrate to Python's svn and then go along for the svn->hg ride. Does that still make sense now that some planning has been done?
I don't think so. It should not matter from which repository the conversion is done, especially since there is no shared history at all. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Also, Martin suggested we migrate to Python's svn and then go along for the svn->hg ride. Does that still make sense now that some planning has been done?
I don't think so. It should not matter from which repository the conversion is done, especially since there is no shared history at all.
Also, I would not merge the Jython SVN into the /projects repository, but instead set up a separate repository (http://svn.python.org/jython, and svn+ssh://jython@svn.python.org/). As discussed at PyCon, we should collect SSH keys for Jython committers in advance of the svn switchover; we would have to do that either way (also for hg), so now might be the right time to start doing it. As for the repository organization: I have now opinion (or, rather, no experience with hg). Regards, Martin
On Mon, Jun 8, 2009 at 16:29, Frank Wierzbicki<fwierzbicki@gmail.com> wrote:
At PyCon, we discussed moving Jython's svn repository to Python's with Martin von Löwis. I would think that Jython would live in Python's hg repository in the same way as stackless and distutils. Has the parallel project strategy been determined? Will they be separate repositories, separate "forests", something else?
I think they should just be separate repositories. The svn.python.org "repository" is more like a collection of actual repositories than a repository in itself.
Also, Martin suggested we migrate to Python's svn and then go along for the svn->hg ride. Does that still make sense now that some planning has been done?
I'd say migrating to Python's svn doesn't make a whole lot of sense at this point, but I'll leave that to Martin (since he has to do the work). For the conversion, I can just as well take the Jython repo from your current server. I've started a svnsync job with your repo so I can run some test conversions. It's a relatively small repository, so it shouldn't be much of a problem. Cheers, Dirkjan
On Mon, Jun 8, 2009 at 11:32 AM, Dirkjan Ochtman<dirkjan@ochtman.nl> wrote:
I'd say migrating to Python's svn doesn't make a whole lot of sense at this point, but I'll leave that to Martin (since he has to do the work). For the conversion, I can just as well take the Jython repo from your current server. I've started a svnsync job with your repo so I can run some test conversions. It's a relatively small repository, so it shouldn't be much of a problem. Great! Thanks for giving this a try!
For my part I'm fine either way (and I agree that Martin should decide based on what is best for him). -Frank
Frank Wierzbicki schrieb:
On Mon, Jun 8, 2009 at 11:32 AM, Dirkjan Ochtman<dirkjan@ochtman.nl> wrote:
I'd say migrating to Python's svn doesn't make a whole lot of sense at this point, but I'll leave that to Martin (since he has to do the work). For the conversion, I can just as well take the Jython repo from your current server. I've started a svnsync job with your repo so I can run some test conversions. It's a relatively small repository, so it shouldn't be much of a problem. Great! Thanks for giving this a try!
For my part I'm fine either way (and I agree that Martin should decide based on what is best for him).
For CPython, we still need SVN, e.g. for the website repo, and several others like it that probably won't get converted (yet), and also for reference since we won't convert every old branch to hg. If that isn't necessary for Jython, I see no reason for moving into svn.python.org first. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
For my part I'm fine either way (and I agree that Martin should decide based on what is best for him).
See my other message. We need to collect SSH keys, and I don't mind moving the Jython repository. OTOH, if the Jython repository gets converted into hg right away, it's certainly (a little) less work. Of course, the Jython committers would need to relocate their svn sandboxes now, and then completely abandon them and re-checkout from hg in a few months, so if you can wait a few months until the hg conversion is ready, it's also less work for your committers. FWIW, I really think that PEP 385 should really grow a timeline pretty soon. Are we going to switch this year, next year, or 2011? Regards, Martin
On Mon, Jun 8, 2009 at 21:57, "Martin v. Löwis"<martin@v.loewis.de> wrote:
See my other message. We need to collect SSH keys, and I don't mind moving the Jython repository. OTOH, if the Jython repository gets converted into hg right away, it's certainly (a little) less work.
Yeah, I guess if you move it to a separate repo on the svn.python.org server that might be nice. But it's not a big deal either way.
FWIW, I really think that PEP 385 should really grow a timeline pretty soon. Are we going to switch this year, next year, or 2011?
Sorry, I should've been clearer. I fully intend to complete the conversion in a few months, say by October 1st or sooner. That would be between 3.1 and whatever the next release will end up being, I hope? It's just hard to be very specific at this point. BTW, I tried my hand at rewriting the revlog for the manifest, as described in the PEP, and it made the full conversion *much* (as in 70%) smaller. I've also been looking at what branches we should keep and will ask for definitive feedback on that point soonish. Cheers, Dirkjan
participants (7)
-
"Martin v. Löwis" -
Alexandre Vassalotti -
Antoine Pitrou -
Benjamin Peterson -
Dirkjan Ochtman -
Frank Wierzbicki -
Georg Brandl