From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 13:56:10 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7065C16A4CE for ; Mon, 9 Feb 2004 13:56:10 -0800 (PST) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E23743D1D for ; Mon, 9 Feb 2004 13:56:10 -0800 (PST) (envelope-from craig@tobuj.gank.org) Received: from localhost (ion.gank.org [69.55.238.164]) by ion.gank.org (mail) with ESMTP id 7C7F22B301; Mon, 9 Feb 2004 15:56:07 -0600 (CST) Received: from ion.gank.org ([69.55.238.164]) by localhost (ion.gank.org [69.55.238.164]) (amavisd-new, port 10024) with LMTP id 73567-01; Mon, 9 Feb 2004 15:56:06 -0600 (CST) Received: from owen1492.uf.corelab.com (pix.corelab.com [12.45.169.2]) by ion.gank.org (mail) with ESMTP id 5A5F62B2EA; Mon, 9 Feb 2004 15:56:06 -0600 (CST) From: Craig Boston To: Stijn Hoop Date: Mon, 9 Feb 2004 15:56:03 -0600 User-Agent: KMail/1.6 References: <200402091130.05656.craig@tobuj.gank.org> <200402091326.45172.craig@tobuj.gank.org> <20040209210625.GY2803@pcwin002.win.tue.nl> In-Reply-To: <20040209210625.GY2803@pcwin002.win.tue.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200402091556.03228.craig@tobuj.gank.org> X-Virus-Scanned: by amavisd-new at gank.org cc: freebsd-hackers@freebsd.org Subject: Re: Subversion/CVS experiment summary X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 21:56:10 -0000 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