Lim Swee Tat <st_lim@stlim.net> writes:
> I made the suggestion in the hopes of seeing a rather inexpensive
> checksum that will perhaps perform error correction, if such needs
> arise.
> Is it possible to make this checksum transparently so that we can then
> have both data integrity and error correction? But I guess under the
> current implementation of the Berkeley DB, this rather difficult since it
> will involve slipping a layer under the BerkeleyDB, rite??
> I understand the need to keep it simple, but if the tradeoff for
> getting error correction system that is already taking time doing
> checksums is minor, I'm willing to trade speed for the error correction
> capability.
I don't think Subversion should be involved in:
1) checking that bits were transmitted across the network without
corruption, or
2) checking that bits were stored on disk without corruption.
These are problems which users can address (if they like) by using
RAID, using hard drives with extensive parity checking, using better
network media, IPsec MAC facilities (which will detect accidental
corruption just as well as deliberate corruption), etc. Completely
generic solutions benefit Subversion as much as anything we could
hard-code into Subversion itself. They're outside of Subversion's
responsibility.
Subversion *should* use checksums or error-correcting information
where we might make mistakes ourselves --- as in the computation and
application of text deltas. Which is, in fact, where we're using them
now.
Received on Sat Oct 21 14:36:27 2006