Re: svn stability problems

 brandon flatly says bdb4.0 is unusable for large repositories.
 
 i have a hard time believing that berkely db 4.0 is broken for
 large repositories, which would be 5000-10000 entries in our case,
 and 200mb in size of the dump file, and it can't handle a 100
 revision, 1000 file dump.
 
 but IF brandon and justin are right, than throwing out db4.0 should
 be made one of the highest priorities.

We are currently using db 4.0.14 here, without any problems.

 what would be a good strategy to reach scalablility/stability? could
 it be a testcase with thousands of entries and moving/copying around
 in it? could it be encouraging somebody large to move to svn?

This is our everyday usage of subversion. Our repository has currently
7.7GB (no log files) and we are reaching revision 23000 (could somebody
please update svn-repositories.html?).

 and i'm wondering how the conectiva folks are handling this, or how

We haven't done any special setup for stability.

 many entries (files/dirs) they have in their repository ... as the

Ouch.. I'd have a hard time counting them, as there are lots of
copies in the strucuture and many files are removed and replaced
every day (see the documentation).

To give you a vague idea, if you look at the documentation, you'll
see that the snapshot directory hold one subdirectory for each package
actively in the distribution, and inside each of those directories
there's something between 2 and 30 files, besides the copies happening
each time a package is released to the snapshot distribution.

[niemeyer@ibook ~]% svn ls $REPOS/snapshot | wc -l
   1483

Of course, we should also count removed files, happening each time a
package has its version updated, and obsolete packages, which were
removed from this directory.

 numbers given in http://subversion.tigris.org/svn-repositories.html
 are quite impressive and do not at all match our experiences.

We have already surpassed them, as shown above.

I'm surprised to see you reporting a bad experience, as we have a very
good experience with subversion/db stability. We had many problems with
our previous server (disk failure, out of memory, out of disk, power
problems, etc), and a simple db_recover always solved our problems.

-- 
Gustavo Niemeyer
[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org