I don't know whether anybody has done this before, but I just tried to run cvs2svn on the Python repository. The conversion took 7 hours, and the result is now available at http://www.dcl.hpi.uni-potsdam.de/python/branches/ Because of the load that the conversion produces on the machine, I cannot run the entire conversion every day. Reportedly, cvs2svn is able to run in incremental mode, but I haven't tried this out yet. On close inspection, you might notice a few things: - A few branches/tags are missing, namely r16b1|cnri-16-start|descr-branch|release152p1-patches|after-c all-reorg|r22a1|before-call-reorg|release16|r161|r161-branch|r16a2|release152p2 I had to manually exclude these tags, because cvs2svn complained that they (some of them) are tags on some files, and branches on other files. When I excluded these, it then complained that some other tags depend on the excluded ones, so I had to exclude these as well. I suspect that this can be fixed by modifying the CVS repository before the conversion, typically by converting the version tags to branch tags. cvs2svn did not report what files specifically caused the problems, and I don't know the proper cvs/rcs incantation to fix these. So if anybody has done that before, or knows how to, please let me know. - A few tags are useless, most notably the "vendor" branches. I think they should be excluded in the conversion. I don't know where the "unlabeled" branches come from, but they appear to be useless as well. - It has imported the CVSROOT directory as well. I don't know whether this is deliberate/useful. Anyway, this repository is now online for anonymous read-only access. Anybody interested in playing with it is welcome to do so. For those interested in server side issues: the repository is an 1.1.1 fsfs repository. The CVS repository consumes 368MiB; the SVN repository 797MiB. Regards, Martin
On 06 March 2005, "Martin v. Löwis" said:
- It has imported the CVSROOT directory as well. I don't know whether this is deliberate/useful.
This is just an artifact of how SourceForge CVS repositories are
organized. When I converted Optik's CVS to Subversion, I just did this:
cvs2svn -s /home/svn/optik /home/cvs/optik/optik
where /home/cvs/optik is what I got after unpacking the tarball
downloaded from SF.
Presumably for Python's repository, this would work:
cvs2svn -s /home/svn/python /home/cvs/python/python
...except, umm, isn't distutils a separate top-level directory in the
Python repository or something? That'll probably have to be fixed
manually.
Greg
--
Greg Ward
Greg Ward wrote:
Presumably for Python's repository, this would work:
cvs2svn -s /home/svn/python /home/cvs/python/python
...except, umm, isn't distutils a separate top-level directory in the Python repository or something?
Ok. Removing the CVSROOT before the conversion (from CVS) or after the conversion (from svn) would probably work. OTOH, I wonder whether the distutils CVS needs to be converted at all, or whether it would be sufficient to only migrate the python "module" (in which case your approach would be sufficient). Regards, Martin
On 07 March 2005, "Martin v. Löwis" said:
OTOH, I wonder whether the distutils CVS needs to be converted at all, or whether it would be sufficient to only migrate the python "module" (in which case your approach would be sufficient).
The last time I looked (late 2000), there was useful content in
/distutils that was not in /python/dist/src/Lib/distutils.
Greg
--
Greg Ward
On Sun, 2005-03-06 at 14:16, "Martin v. Löwis" wrote:
I don't know whether anybody has done this before, but I just tried to run cvs2svn on the Python repository. The conversion took 7 hours, and the result is now available at
http://www.dcl.hpi.uni-potsdam.de/python/branches/
Because of the load that the conversion produces on the machine, I cannot run the entire conversion every day. Reportedly, cvs2svn is able to run in incremental mode, but I haven't tried this out yet.
I personally have had no success doing this, but the last time I tried was with a fairly old version of svn. BTW, it looks like you just pulled in python/dist right? Did you pull in the trunk? What about nondist, or as Greg mentioned, distutils which is a sibling of the top-level python directory.
- It has imported the CVSROOT directory as well. I don't know whether this is deliberate/useful.
Almost certainly not useful. Even the diff checkin messages are generated with a much simpler script (owing largely to svn being designed to make this kind of thing possible without disgusting hacks).
Anyway, this repository is now online for anonymous read-only access. Anybody interested in playing with it is welcome to do so.
For those interested in server side issues: the repository is an 1.1.1 fsfs repository. The CVS repository consumes 368MiB; the SVN repository 797MiB.
Just curious - why did you choose fsfs instead of the BerkeleyDB backend? Thanks for doing this Martin. I've heard that SF may be offering svn as early as May or June and I would love to see us convert when that's available. -Barry
Barry Warsaw wrote:
I personally have had no success doing this, but the last time I tried was with a fairly old version of svn.
It gives an error message when you try. You then need to interpret the error message, retry, and it gives you another error message. You do this three times, and end up with the command line cvs2svn -q --fs-type=fsfs --encoding=latin1 "--exclude=r16b1|cnri-16-start|descr-branch|release152p1-patches|after-call-reorg|r22a1|before-call-reorg|release16|r161|r161-branch|r16a2|release152p2" -s py.svn.new python
BTW, it looks like you just pulled in python/dist right? Did you pull in the trunk? What about nondist, or as Greg mentioned, distutils which is a sibling of the top-level python directory.
I posted the wrong URL. The right one is http://www.dcl.hpi.uni-potsdam.de/python/ It has distutils right in http://www.dcl.hpi.uni-potsdam.de/python/trunk/distutils/
Just curious - why did you choose fsfs instead of the BerkeleyDB backend?
I had hoped that it would consume less disk space - but I really should try with bdb again. In our operational repositories, I have now migrated everything to fsfs because it is so much more friendly to backups. You can backup the on-disk state, and trust that is consistent. With bdb, you need to use hot-backup.py or some such, and this gives you an entire copy which then goes into all incremental backups. With fsfs, the incremental backups really pickup new commits only. (for the Python svn, it doesn't matter much, since that is excluded from backup, anyway)
Thanks for doing this Martin. I've heard that SF may be offering svn as early as May or June and I would love to see us convert when that's available.
So do I. However, I now believe that it is unlikely that SF will provide automatic conversion (or the automatic conversion will be useless/fail); instead, we likely need to provide our hand-tuned conversion. I'll keep collecting issues/complaints about this specific conversion, and try to integrate them if I can. Regards, Martin
participants (3)
-
"Martin v. Löwis"
-
Barry Warsaw
-
Greg Ward