Fossil SCM
Improvements to www/selfcheck.wiki: fixed a few typos, added a link to the delta-compression algo doc, and capitalized "fossil" where used as a product name, rather than a command.
Commit
0b9bfc4f7d5ab08a942e7c600d42cb045dcd5f46640b0ec58c46e593e0502dbe
Parent
1ebe5bbec0b6241…
1 file changed
+15
-15
+15
-15
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -13,11 +13,11 @@ | ||
| 13 | 13 | part to the defensive measures described here, no data has been |
| 14 | 14 | lost. The integrity checks are doing their job well.</p> |
| 15 | 15 | |
| 16 | 16 | <h2>Atomic Check-ins With Rollback</h2> |
| 17 | 17 | |
| 18 | -The fossil repository is stored in an | |
| 18 | +The Fossil repository is stored in an | |
| 19 | 19 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 20 | 20 | ([./tech_overview.wiki | Addition information] about the repository |
| 21 | 21 | file format.) |
| 22 | 22 | SQLite is very mature and stable and has been in wide-spread use for many |
| 23 | 23 | years, so we are confident it will not cause repository |
| @@ -25,46 +25,46 @@ | ||
| 25 | 25 | databases do not corrupt even if a program or system crash or power |
| 26 | 26 | failure occurs in the middle of the update. If some kind of crash |
| 27 | 27 | does occur in the middle of a change, then all the changes are rolled |
| 28 | 28 | back the next time that the database is accessed. |
| 29 | 29 | |
| 30 | -A check-in operation in fossil makes many changes to the repository | |
| 30 | +A check-in operation in Fossil makes many changes to the repository | |
| 31 | 31 | database. But all these changes happen within a single transaction. |
| 32 | 32 | If something goes wrong in the middle of the commit, even if that something |
| 33 | 33 | is a power failure or OS crash, then the transaction |
| 34 | 34 | is rolled back and the database is unchanged. |
| 35 | 35 | |
| 36 | 36 | <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> |
| 37 | 37 | |
| 38 | -The content files that comprise the global state of a fossil repository | |
| 38 | +The content files that comprise the global state of a Fossil repository | |
| 39 | 39 | are stored in the repository as a tree. The leaves of the tree are |
| 40 | 40 | stored as zlib-compressed BLOBs. Interior nodes are deltas from their |
| 41 | 41 | descendants. A lot of encoding is going on. There is |
| 42 | 42 | zlib-compression which is relatively well-tested but still might |
| 43 | 43 | cause corruption if used improperly. And there is the relatively |
| 44 | -new delta-encoding mechanism designed expressly for fossil. We want | |
| 44 | +new [./delta_encoder_algorithm.wiki | delta-encoding mechanism] designed expressly for Fossil. We want | |
| 45 | 45 | to make sure that bugs in these encoding mechanisms do not lead to |
| 46 | 46 | loss of data. |
| 47 | 47 | |
| 48 | 48 | To increase our confidence that everything in the repository is |
| 49 | -recoverable, fossil makes sure it can extract an exact replica | |
| 49 | +recoverable, Fossil makes sure it can extract an exact replica | |
| 50 | 50 | of every content file that it changes just prior to transaction |
| 51 | 51 | commit. So during the course of check-in (or other repository |
| 52 | 52 | operation) many different files |
| 53 | 53 | in the repository might be modified. Some files are simply |
| 54 | 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | -While all this is going on, fossil makes a record of every file | |
| 55 | +While all this is going on, Fossil makes a record of every file | |
| 56 | 56 | and the SHA1 or SHA3-256 hash of the original content of that |
| 57 | -file. Then just before transaction commit, fossil re-extracts | |
| 57 | +file. Then just before transaction commit, Fossil re-extracts | |
| 58 | 58 | the original content of all files that were written, recomputes |
| 59 | 59 | the hash, and verifies that the recomputed hash still matches. |
| 60 | 60 | If anything does not match up, an error |
| 61 | 61 | message is printed and the transaction rolls back. |
| 62 | 62 | |
| 63 | -So, in other words, fossil always checks to make sure it can | |
| 63 | +So, in other words, Fossil always checks to make sure it can | |
| 64 | 64 | re-extract a file before it commits a change to that file. |
| 65 | -Hence bugs in fossil are unlikely to corrupt the repository in | |
| 65 | +Hence bugs in Fossil are unlikely to corrupt the repository in | |
| 66 | 66 | a way that prevents us from extracting historical versions of |
| 67 | 67 | files. |
| 68 | 68 | |
| 69 | 69 | <h2>Checksum Over All Files In A Check-in</h2> |
| 70 | 70 | |
| @@ -80,11 +80,11 @@ | ||
| 80 | 80 | algorithm implementation. |
| 81 | 81 | |
| 82 | 82 | |
| 83 | 83 | <h2>Checksums On Structural Artifacts And Deltas</h2> |
| 84 | 84 | |
| 85 | -Every [./fileformat.wiki | structural artifact] in a fossil repository | |
| 85 | +Every [./fileformat.wiki | structural artifact] in a Fossil repository | |
| 86 | 86 | contains a "Z-card" bearing an MD5 checksum over the rest of the |
| 87 | 87 | artifact. Any mismatch causes the structural artifact to be ignored. |
| 88 | 88 | |
| 89 | 89 | The [./delta_format.wiki | file delta format] includes a 32-bit |
| 90 | 90 | checksum of the target file. Whenever a file is reconstructed from |
| @@ -93,17 +93,17 @@ | ||
| 93 | 93 | |
| 94 | 94 | <h2>Reliability Versus Performance</h2> |
| 95 | 95 | |
| 96 | 96 | Some version control systems make a big deal out of being "high performance" |
| 97 | 97 | or the "fastest version control system". Fossil makes no such claims and has |
| 98 | -no such ambition. Indeed, profiling indicates that fossil bears a | |
| 98 | +no such ambition. Indeed, profiling indicates that Fossil bears a | |
| 99 | 99 | substantial performance cost for |
| 100 | 100 | doing all of the checksumming and verification outlined above. |
| 101 | 101 | Fossil takes the philosophy of the |
| 102 | 102 | <a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>: |
| 103 | 103 | reliability is more important than raw speed. The developers of |
| 104 | -fossil see no merit in getting the wrong answer quickly. | |
| 104 | +Fossil see no merit in getting the wrong answer quickly. | |
| 105 | 105 | |
| 106 | -Fossil may not be the fastest versioning system, but it is "fast enough". | |
| 107 | -Fossil runs quickly enough to stay out of the developers way. | |
| 108 | -Most operations complete in milliseconds, faster that you can press | |
| 106 | +Fossil may not be the fastest versioning system, but it is <i>fast enough</i>. | |
| 107 | +Fossil runs quickly enough to stay out of the developer's way. | |
| 108 | +Most operations complete in milliseconds, faster than you can press | |
| 109 | 109 | the "Enter" key. |
| 110 | 110 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | part to the defensive measures described here, no data has been |
| 14 | lost. The integrity checks are doing their job well.</p> |
| 15 | |
| 16 | <h2>Atomic Check-ins With Rollback</h2> |
| 17 | |
| 18 | The fossil repository is stored in an |
| 19 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 20 | ([./tech_overview.wiki | Addition information] about the repository |
| 21 | file format.) |
| 22 | SQLite is very mature and stable and has been in wide-spread use for many |
| 23 | years, so we are confident it will not cause repository |
| @@ -25,46 +25,46 @@ | |
| 25 | databases do not corrupt even if a program or system crash or power |
| 26 | failure occurs in the middle of the update. If some kind of crash |
| 27 | does occur in the middle of a change, then all the changes are rolled |
| 28 | back the next time that the database is accessed. |
| 29 | |
| 30 | A check-in operation in fossil makes many changes to the repository |
| 31 | database. But all these changes happen within a single transaction. |
| 32 | If something goes wrong in the middle of the commit, even if that something |
| 33 | is a power failure or OS crash, then the transaction |
| 34 | is rolled back and the database is unchanged. |
| 35 | |
| 36 | <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> |
| 37 | |
| 38 | The content files that comprise the global state of a fossil repository |
| 39 | are stored in the repository as a tree. The leaves of the tree are |
| 40 | stored as zlib-compressed BLOBs. Interior nodes are deltas from their |
| 41 | descendants. A lot of encoding is going on. There is |
| 42 | zlib-compression which is relatively well-tested but still might |
| 43 | cause corruption if used improperly. And there is the relatively |
| 44 | new delta-encoding mechanism designed expressly for fossil. We want |
| 45 | to make sure that bugs in these encoding mechanisms do not lead to |
| 46 | loss of data. |
| 47 | |
| 48 | To increase our confidence that everything in the repository is |
| 49 | recoverable, fossil makes sure it can extract an exact replica |
| 50 | of every content file that it changes just prior to transaction |
| 51 | commit. So during the course of check-in (or other repository |
| 52 | operation) many different files |
| 53 | in the repository might be modified. Some files are simply |
| 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | While all this is going on, fossil makes a record of every file |
| 56 | and the SHA1 or SHA3-256 hash of the original content of that |
| 57 | file. Then just before transaction commit, fossil re-extracts |
| 58 | the original content of all files that were written, recomputes |
| 59 | the hash, and verifies that the recomputed hash still matches. |
| 60 | If anything does not match up, an error |
| 61 | message is printed and the transaction rolls back. |
| 62 | |
| 63 | So, in other words, fossil always checks to make sure it can |
| 64 | re-extract a file before it commits a change to that file. |
| 65 | Hence bugs in fossil are unlikely to corrupt the repository in |
| 66 | a way that prevents us from extracting historical versions of |
| 67 | files. |
| 68 | |
| 69 | <h2>Checksum Over All Files In A Check-in</h2> |
| 70 | |
| @@ -80,11 +80,11 @@ | |
| 80 | algorithm implementation. |
| 81 | |
| 82 | |
| 83 | <h2>Checksums On Structural Artifacts And Deltas</h2> |
| 84 | |
| 85 | Every [./fileformat.wiki | structural artifact] in a fossil repository |
| 86 | contains a "Z-card" bearing an MD5 checksum over the rest of the |
| 87 | artifact. Any mismatch causes the structural artifact to be ignored. |
| 88 | |
| 89 | The [./delta_format.wiki | file delta format] includes a 32-bit |
| 90 | checksum of the target file. Whenever a file is reconstructed from |
| @@ -93,17 +93,17 @@ | |
| 93 | |
| 94 | <h2>Reliability Versus Performance</h2> |
| 95 | |
| 96 | Some version control systems make a big deal out of being "high performance" |
| 97 | or the "fastest version control system". Fossil makes no such claims and has |
| 98 | no such ambition. Indeed, profiling indicates that fossil bears a |
| 99 | substantial performance cost for |
| 100 | doing all of the checksumming and verification outlined above. |
| 101 | Fossil takes the philosophy of the |
| 102 | <a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>: |
| 103 | reliability is more important than raw speed. The developers of |
| 104 | fossil see no merit in getting the wrong answer quickly. |
| 105 | |
| 106 | Fossil may not be the fastest versioning system, but it is "fast enough". |
| 107 | Fossil runs quickly enough to stay out of the developers way. |
| 108 | Most operations complete in milliseconds, faster that you can press |
| 109 | the "Enter" key. |
| 110 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | part to the defensive measures described here, no data has been |
| 14 | lost. The integrity checks are doing their job well.</p> |
| 15 | |
| 16 | <h2>Atomic Check-ins With Rollback</h2> |
| 17 | |
| 18 | The Fossil repository is stored in an |
| 19 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 20 | ([./tech_overview.wiki | Addition information] about the repository |
| 21 | file format.) |
| 22 | SQLite is very mature and stable and has been in wide-spread use for many |
| 23 | years, so we are confident it will not cause repository |
| @@ -25,46 +25,46 @@ | |
| 25 | databases do not corrupt even if a program or system crash or power |
| 26 | failure occurs in the middle of the update. If some kind of crash |
| 27 | does occur in the middle of a change, then all the changes are rolled |
| 28 | back the next time that the database is accessed. |
| 29 | |
| 30 | A check-in operation in Fossil makes many changes to the repository |
| 31 | database. But all these changes happen within a single transaction. |
| 32 | If something goes wrong in the middle of the commit, even if that something |
| 33 | is a power failure or OS crash, then the transaction |
| 34 | is rolled back and the database is unchanged. |
| 35 | |
| 36 | <h2>Verification Of Delta Encodings Prior To Transaction Commit</h2> |
| 37 | |
| 38 | The content files that comprise the global state of a Fossil repository |
| 39 | are stored in the repository as a tree. The leaves of the tree are |
| 40 | stored as zlib-compressed BLOBs. Interior nodes are deltas from their |
| 41 | descendants. A lot of encoding is going on. There is |
| 42 | zlib-compression which is relatively well-tested but still might |
| 43 | cause corruption if used improperly. And there is the relatively |
| 44 | new [./delta_encoder_algorithm.wiki | delta-encoding mechanism] designed expressly for Fossil. We want |
| 45 | to make sure that bugs in these encoding mechanisms do not lead to |
| 46 | loss of data. |
| 47 | |
| 48 | To increase our confidence that everything in the repository is |
| 49 | recoverable, Fossil makes sure it can extract an exact replica |
| 50 | of every content file that it changes just prior to transaction |
| 51 | commit. So during the course of check-in (or other repository |
| 52 | operation) many different files |
| 53 | in the repository might be modified. Some files are simply |
| 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | While all this is going on, Fossil makes a record of every file |
| 56 | and the SHA1 or SHA3-256 hash of the original content of that |
| 57 | file. Then just before transaction commit, Fossil re-extracts |
| 58 | the original content of all files that were written, recomputes |
| 59 | the hash, and verifies that the recomputed hash still matches. |
| 60 | If anything does not match up, an error |
| 61 | message is printed and the transaction rolls back. |
| 62 | |
| 63 | So, in other words, Fossil always checks to make sure it can |
| 64 | re-extract a file before it commits a change to that file. |
| 65 | Hence bugs in Fossil are unlikely to corrupt the repository in |
| 66 | a way that prevents us from extracting historical versions of |
| 67 | files. |
| 68 | |
| 69 | <h2>Checksum Over All Files In A Check-in</h2> |
| 70 | |
| @@ -80,11 +80,11 @@ | |
| 80 | algorithm implementation. |
| 81 | |
| 82 | |
| 83 | <h2>Checksums On Structural Artifacts And Deltas</h2> |
| 84 | |
| 85 | Every [./fileformat.wiki | structural artifact] in a Fossil repository |
| 86 | contains a "Z-card" bearing an MD5 checksum over the rest of the |
| 87 | artifact. Any mismatch causes the structural artifact to be ignored. |
| 88 | |
| 89 | The [./delta_format.wiki | file delta format] includes a 32-bit |
| 90 | checksum of the target file. Whenever a file is reconstructed from |
| @@ -93,17 +93,17 @@ | |
| 93 | |
| 94 | <h2>Reliability Versus Performance</h2> |
| 95 | |
| 96 | Some version control systems make a big deal out of being "high performance" |
| 97 | or the "fastest version control system". Fossil makes no such claims and has |
| 98 | no such ambition. Indeed, profiling indicates that Fossil bears a |
| 99 | substantial performance cost for |
| 100 | doing all of the checksumming and verification outlined above. |
| 101 | Fossil takes the philosophy of the |
| 102 | <a href="http://en.wikipedia.org/wiki/The_Tortoise_and_the_Hare">tortoise</a>: |
| 103 | reliability is more important than raw speed. The developers of |
| 104 | Fossil see no merit in getting the wrong answer quickly. |
| 105 | |
| 106 | Fossil may not be the fastest versioning system, but it is <i>fast enough</i>. |
| 107 | Fossil runs quickly enough to stay out of the developer's way. |
| 108 | Most operations complete in milliseconds, faster than you can press |
| 109 | the "Enter" key. |
| 110 |