On Sun, 2004-03-28 at 12:46, Martin Furter wrote:
> > They can already do that by limiting themselves to format version 2.
>
> Yes, i also thought about that.
> But what if the dump file format changes again?
> For example if another node type like symbolic link is added?
We could add such a header when the format changes again, if it still
seems to be needed. It seems to be a little speculative to add it now,
though I'm not totally opposed to it.
As an aside, I now have performance numbers. Using the Subversion
repository as of r9219 (thanks to Ben for providing me with a dumpfile):
Standard dump size: 648479605
Compressed standard dump size: 144751988
Repository size: 170291200
Diffy dump size: 33113142
Compressed diffy dump size: 13196422
(Ben says the repository on svn.collab.net is only 140MB, so there's
obviously some variation there. I thought I was using BDB 4.2, but I
had to delete unused logfiles to get the repository size down from
1.65GB to the 162MB listed above, so maybe I'm using BDB 4.0 on account
of the APR configury bug.)
Anyway, the upshot is that diffy dumps are 20 times smaller than regular
dumps, or 10 times smaller when compressed. Also, the repository seems
to be 4-5 times bigger than a diffy dump of the repository, which seems
like a lot of overhead.
I haven't collected time data, but subjectively, diffy dumps and loads
seem to be roughly as fast as regular dumps and loads.
On the testing front, we don't appear to have any dump-load test cases
(we have some very basic "dump" test cases which don't validate the
output), so I'm not sure if I'll write any test cases before checking in
my code. It appears to dump and load the Subversion repository just
fine, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 29 00:07:40 2004