> > I heard tell this morning of a change to cvs2svn to make it use
> > bdb-txn-nosync, allegedly speeding up conversion by a factor of four
> > or so. So you might be able to get comparable conversion performance
> > between the two back ends now.
>
> You can either pass --bdb-txn-nosync directly to cvs2svn, or make
> cvs2svn create a dumpfile and pass --bdb-txn-nosync when creating the
> repo yourself.
>
> When doing our conversion, 'svnadmin load' took ~10 hours by default.
> Creating the repo with --bdb-txn-nosync sped things up to ~2 hours. In
> both cases 'svnadmin load' was I/O bound.
>
> Putting the whole repository in tmpfs sped it up even more, from ~2
> hours to ~20 minutes (and then it was CPU bound, not I/O bound). Note
> that you don't even need enough RAM to fit it all in memory for this to
> be a win; in our case, most of the tmpfs mount got pushed out to swap
> (~600mb repo on a 256mb machine). Obviously you have to remember to copy
> the repo somewhere permanent afterwards if you do this :)
Interesting because you get the full benefit of having a fast machine. But
doing it this way leaves the db-txn-nosync off even for normal use. It looks
like the latest cvs2svn program modifies the DB_CONFIG file to turn is back
on, so presumably there's no svnadmin command to reenable it.
Is there a recommendation on whether it should or shouldn't be on for normal
usage?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 13 00:34:41 2004