Date: Mon, 9 Feb 2004 15:56:03 -0600 From: Craig Boston <craig@tobuj.gank.org> To: Stijn Hoop <stijn@win.tue.nl> Cc: freebsd-hackers@freebsd.org Subject: Re: Subversion/CVS experiment summary Message-ID: <200402091556.03228.craig@tobuj.gank.org> In-Reply-To: <20040209210625.GY2803@pcwin002.win.tue.nl> References: <200402091130.05656.craig@tobuj.gank.org> <200402091326.45172.craig@tobuj.gank.org> <20040209210625.GY2803@pcwin002.win.tue.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 09 February 2004 03:06 pm, Stijn Hoop wrote: > Well, that explains a lot -- for some reason I tested using > $LastChangedRevision: 7921 $. I'll try with an up-to-date one then. I was looking through the change history for cvs2svn.py and it seems that the 0.37 version is almost exactly the same as the 0.35 version. For some reason it looks like they just re-tagged the old version rather than bring in the changes from HEAD... > > One thing that may have made a difference is that so far I've been > > importing things in chunks rather than trying to do the whole repo at > > once. > > Yes, I was afraid though that commits might have spanned subtrees. But then > again, even if they did they would just get committed as separate revisions > to the tree, and I suppose one could live with that. There probably are some commits that do. Only reason I did it like that was to try to trap failure cases more quickly without having to wait for it to get through stage 1 on the whole repo. My plan has always been to go back and try to convert the whole thing when I was sure it would import cleanly and had the resources to do it (the fastest CPU machine I have probably doesn't have enough disk space right now to handle it). > > Does the Python version do the same thing? I didn't think to look at > > memory usage very closely while it was running :-/ > > As far as I understood it builds a disk cache instead of using malloc(). > This might explain the slowness :) Ok, that's consistent with what I saw here. It looked like it created several large temporary bdb databases, but I don't remember any excessive swapping going on. > Yes, that's the idea. You 'just' need a tool that can determine changesets > from a CVS repository to automate this. See > > http://wiki.gnuarch.org/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree > > but substitute Subversion for arch :) Makes sense. I believe you mentioned earlier that post-commit hooks could be used for this? But that of course requires assistance from the repomaster. It might also be possible to rig up a script to monitor the cvs-all mailing list and get its changesets from there... > It is, but it does work. Maybe I'll test and see if I can 'port' those > scripts to Subversion :) Yes, it does work as long as your users are relatively trusted and you keep good backups :). Still, it would probably be the most painless transition path to use that over ssh. In regards to the speed test: ARGH! svn dump died on me with this message: * Dumped revision 18576. * Dumped revision 18577. * Dumped revision 18578. * Dumped revision 18579. * Dumped revision 18580. svn: Invalid change ordering: non-add change on deleted path If it's really invalid I wonder how it ended up in the repo in the first place. Not good. I'll have to do some digging to find out what causes that. Craig
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200402091556.03228.craig>