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

Issue 1074: Need a svnadmin command to verify that the repository is not corrupted

From: John Szakmeister <john_at_szakmeister.net>
Date: 2003-07-18 01:38:13 CEST

Just wanted someone who is more familiar with the internals of the fs and
repos libraries to give me a little guidance. Karl suggested that we should
read every rep and make sure it matches the checksum:

        ------ Additional Comments From Karl Fogel 2003-01-11 14:33 PST -------
 
        Marking this as a bite-sized Post-1.0 feature. (Note that issue #649
        is done now, so this is basically a matter of reading every rep and
        making sure it matches its checksum.)

But I have a few questions. First, I've sat down and gone through the FS
structure documentation several times (which, btw, is very interesting to a
guy who hasn't seen how databases are really used :-) and saw that you need
a key to access the rep. Which made reading every rep from a table an
unlikely thing to do. :-)

At any rate, it seems like the best solution, as far as I can tell, would be
to do something similar to a dump of the repository, only without the actual
dump, and check a file's checksum with the recorded checksum. Does that seem
like a reasonable solution, or should I be looking at this from another
angle? I've gone through and created a 'verify' command that does this now,
and it's at least checking the file checksums just fine.

My real reason for posting this message is about regression testing. Does
anyone have a good idea I can how to create an SVN repository in which the
file data or the checksum gets tweaked for testing purposes?

Thanks!

-John

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 18 01:38:12 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.