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

Re: large repositories with svn?

From: <kfogel_at_collab.net>
Date: 2003-06-17 20:57:40 CEST

"Subversion" <mailing.lists@gmx.net> writes:
> i am planning to convert a very large CVS/RCS repository to svn, but i
> wonder if svn can handle such a large repository as fast as CVS?
>
> there will be approximately 25.000 (twenty five thousand) files in it;
>
> what will happen when i perform a checkout or an update, will this slow the
> process down?
>
> what will happen when the repository grows, will all actions slow down?
>
> how fast will grow the disk usage, when i create trunks / tags?
>
> has anybody ever used SVN with such a large repository?
>
> i would be very happy for any answers.

The conversion process may take a while, but the Subversion repository
itself should work fine once converted.

(Or do you mean, will updating from the CVS repository cause the
conversion process to be slower? It shouldn't. Don't let anyone
commit, though, unless you're prepared to watch the commits and make
sure they get ported to the Subversion repository later.)

The Subversion checkouts and other operations will use an amount of
time proportional to the change, that is, to the number of files
involved. A checkout is a big change -- it converts the empty set to
a directory full of files, so it will take as long as is needed to get
all those files from the repository :-).

Disk usage won't grow with tags and other copies in the repository;
they only use a tiny amount of space, no matter how large the subtree
being tagged.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 17 21:45:12 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.