----- Original Message -----
From: "Ben Collins-Sussman" <sussman@collab.net>
> So make as many copies as you want. Is has nothing to do with
> performance.
I -think- it will depend on the amount of data changed
on each revision, the size of the individual files
and the size of the changesets.
If the mentioned 15,000 files are purely text, html, .c
(i.e. non-binary) files this is not a problem at all,
since -real- changes on these files tend to be very small.
I put about 60,000 .c and even many .png files into SVN
and it still runs ok (up to ~ rev. 100 yet)
but maybe I'll run a test on it overnight and push
it up to some rev. 10000 to verify this :-)
( To give a worst-case example: if you'd put 15.000
.png files into svn and RGB-color-correct all them 3 times
a day and commit them, your DB would expand and slow
down like hell -- binary files that change often should
always be handled with care when using an SCM :-)
( note: the initial question was on 7 commits a day = 2555 a year )
After reading through
http://subversion.tigris.org/files/documents/15/17/svn-design.html#Schema
I -think- (devs, please tell me if I got it wrong)
that access to >recent revisions< of the repository will
remain quite fast, independent from the amount of revisions
in the DB.
but access to -very-old- file revisions (e.g. rev. 1) get slightly
slower with each new revision that is committed, since all
data is stored as 'diffs' to the previous file, and all the,
say 2555 diffs have to be applied in reverse order.
Applying 2555 diffs on, say, 1MB files could get pretty slow -
and that slowness gets multiplied by 15.000 files in the worst case.
But note, that other revision control systems work mostly similar,
and suffer from equal or even larger limitations.
:-)
=====
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 5 18:25:43 2004