Karl,
we are administrating the databases of our customers (one thousand companies all over the world) and I can tell you lots of horror stories from that: The user schema checks oftern reported no problems, while a simple SELECT returned totally screwed data because of internal linkage failures (indices where physically correct but pointed to the wrong records due to corrupt meta data table entries -- the check program thought this would be correct since it used the same meta data tables to find out what the index is for...). Also we had been usinig Microsoft VSS for years and often had the problem that VSS's check tool told us 'no errors found', but I could not get the correct version history (but I was able to checkout), and vice versa. So *before* running in such problems with FSFS (for Berkeley the SVN book says its proofed to work well while FSFS is totally new) I want to be safe and check meta information, also.
Mit freundlichem Gruss / With kind regards
Markus KARG, Staatl. gepr. Inf.
Entwicklung / R & D
QUIPSY QUALITY GmbH
________________________________
Von: kfogel@newton.ch.collab.net im Auftrag von kfogel@collab.net
Gesendet: Fr 07.10.2005 18:25
An: Markus Karg
Cc: Daniel Berlin; Leon Zandman; users@subversion.tigris.org
Betreff: Re: AW: AW: Re: AW: AW: AW: How to check integrity of database?
"Markus Karg" <markus.karg@quipsy.de> writes:
> thank you for clarification on what the SVN team actually thinks
> about this, because in the previous discussion this was
> unclear. It's good to see that the team has understood that there
> are users very concerned even on corrupted properties and we don't
> think that it is only hypothetical.
>
> Thanks for SVN, it's a great tool.
> All what we want is to make it even better.
As do we all. I'm also in favor of clean air, clean water, beautiful
spring days, and democratic government, personally.
However, defining "better" is the key problem here. In order to
determine whether or not revision properties should have checksums,
and all the extra code complexity that goes along with that, we'd like
to know of any instances of revision properties getting corrupted in a
way that was not immediately detected. (For example, a hard disk head
strike wouldn't count, because that would have corrupted the entire
repository, revision properties along with everything else. Thus, it
would almost have to be a software error, most likely in Subversion.)
Does anyone have any such horror stories?
Thank you,
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
Received on Mon Oct 10 07:49:48 2005