may i ask some additional questions?
- do you use it via file:// or http(s)://?
- do you use it with access control?
- what would svn ls -R https://.../ � wc give?
i.e. is it more in the 3000 region, or more
in the 20000 region?
- how big is a typical working copy
ls -1R | wc
(when do you start to think it is too slow)
btw, the svn ls -R https://.../svnrep seems
to be strange. i did a ^c after 5 minutes waiting ...
it seems to collect all the data in an interestingly
slow way and then send it all at once.
-s
--- Gustavo Niemeyer niemeyer@conectiva.com wrote:
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
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:06:28 2006