[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: incremental conversion from other SCM to svn by vcp

From: Chia-liang Kao <clkao_at_clkao.org>
Date: 2003-06-14 22:23:02 CEST

On Fri, Jun 13, 2003 at 01:08:14PM -0500, kfogel@collab.net wrote:
> Some questions:
> - Have you tested the driver on any really big repositories, like
> the FreeBSD CVS repository (2.3 gigs)? Also, that one's good
> because it has a lot of edge cases -- twice-deleted files,
> branches where some files are branched much later than others
> ("split" branches), etc.

yes i also tried the freebsd tree. but vcp was too slow so i decided
to make it perform better first on some smaller real cases.

> - Is it holding a lot of state in memory, such as all the branch
> paths and things like that?

currently yes. so in my trial of converting the freebsd tree, it took
up like ~300 MB of memory.

> Well, the total conversion time is still important -- many sites will
> be converting once and then using just Subversion. For them, the main
> issue is "How long will my developers be shut out of the repository
> during this conversion?"

but the thing is that one could convert cvs to svn while not having
the cvs server down. after the first expensive conversion, a second
one would take maybe just a few minutes to catch up with the changes
that are made within the conversion time. :) anyway it does not stop
me from improving the performance.

> (I'm not sure how using date instead of revision will help your CVS
> retrieval time? I would think the Subversion commits are a huge
> bottleneck... outputting to a dumpfile and then loading it might save
> a lot of time.)

with the date checkout heuristic, I just got it to < 4 hours today. note
that this is a conversion from remote cvs tree, so every cvs checkout or
update for a single file takes 2 or 3 seconds. 51% of the time is waiting
cvs results, while 48% of the time is for svn invokation.

now i'll be working on tagging and maybe investigate using dumpfile (are
there utility functions availble for dealing dumpfiles?)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 14 22:23:33 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.