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

Re: The small commit problem

From: <cmpilato_at_collab.net>
Date: 2003-07-29 20:46:18 CEST

Philip Martin <philip@codematters.co.uk> writes:

> Thus a Subversion repository doesn't handle "small" commits
> particularly well, there is a sort of threshold on the minimum size
> for each commit. This could explain why we are getting reports that
> CVS repositories convert to much larger Subversion repositories.
>
> Does that sound plausible? If it does I wonder what we could do to
> change it: make the nodes less expensive, or use some sort of "diffy"
> directory storage, or...

We explicitly disabled diffy directory storage because of the time
costs of undeltifying those things. That said, this cost might not be
so great these days (with skip-deltas and delta combiners).

> psize=`du -ks repostress | awk '{print $1}'`

It would appear that your script is measuring just the sheer size of
the database, log files and all (unless stress.pl does log removal).
This means you're measuring not just the growth of the repository, but
the growth of all the intermediate loggish steps taken to change that
repository. So yes, you can expect that to grow almost linearly based
on the size of the of the change. I mean, as each new edit or move
comes in, we are replacing the directory entries list. That's a
write-ahead log action of (probably) the entire new entries list *for
each edit*.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 29 20:47:27 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.