Differences From:
File www/selfcheck.html part of check-in [469002ccdf] - Added navbar to all pages, linking back to the index. Fixed typo in the index page. by aku on 2007-09-12 04:19:59. Also file www/selfcheck.html part of check-in [bbcb6326c9] - Pulled in the navbar and timeline changes. by aku on 2007-09-17 00:58:51. [view]
To:
File www/selfcheck.html part of check-in [6680679c2e] - Documentation updates. by drh on 2007-11-24 14:06:38. Also file www/selfcheck.html part of check-in [d0305b305a] - Merged mainline into my branch to get the newest application. by aku on 2007-12-05 08:07:46. [view]
@@ -16,8 +16,14 @@ lose your files. This note describes the defensive measures that fossil uses to help prevent file loss due to bugs. </p> +<p><i>Follow-up as of 2007-11-24:</i> +Fossil has been hosting itself and several other projects for +months now. Many bugs have been encountered. But, thanks in large +part to the defensive measures described here, no data has been +lost. The integrity checks are doing their job well.</p> + <h2>Atomic Check-ins With Rollback</h2> <p> The fossil repository is an @@ -43,9 +49,9 @@ <p> The content files that comprise the global state of a fossil respository are stored in the repository as a tree. The leaves of the tree are stored as zlib-compressed BLOBs. Interior nodes are deltas from their -decendents. There is a lot of encoding going on here. There is +decendents. A lot of encoding is going on. There is zlib-compression which is relatively well-tested but still might cause corruption if used improperly. And there is the relatively new delta-encoding mechanism designed expressly for fossil. We want to make sure that bugs in these encoding mechanisms do not lead to @@ -55,9 +61,10 @@ <p> To increase our confidence that everything in the repository is recoverable, fossil makes sure it can extract an exact replicate of every content file that it changes just prior to transaction -commit. So during the course of check-in, many different files +commit. So during the course of check-in (or other repository +operation) many different files in the repository might be modified. Some files are simply compressed. Other files are delta encoded and then compressed. While all this is going on, fossil makes a record of every file that is encoded and the SHA1 hash of the original content of that @@ -69,9 +76,9 @@ </p> <p> So, in other words, fossil always checks to make sure it can -re-extract a file before it commits a check-in of that file. +re-extract a file before it commits a change to that file. Hence bugs in fossil are unlikely to corrupt the repository in a way that prevents us from extracting historical versions of files. </p> @@ -78,10 +85,10 @@ <h2>Checksum Over All Files In A Baseline</h2> <p> -Manifest files that define a baseline have two fields (the -R-line and Z-line) that record MD5 hashs of the manifest itself +Manifest artifacts that define a baseline have two fields (the +R-card and Z-card) that record MD5 hashs of the manifest itself and of all other files in the manifest. Prior to any check-in commit, these checksums are verified to ensure that the baseline checked in agrees exactly with what is on disk. Similarly, the repository checksum is verified after a checkout to make