Fossil SCM
Replaced a few remaining "block chain" references with "Merkle tree" in the Fossil v Git article.
Commit
e673065280bbd81ec08e1364ee494505e59653a5c0ff853ead2f33388c2b526a
Parent
f6ab24fd26a1ba1…
1 file changed
+4
-3
+4
-3
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -264,11 +264,12 @@ | ||
| 264 | 264 | Fossil, on the other hand, parses essential information about check-ins |
| 265 | 265 | (parents, children, committers, comments, files changed, etc.) into a |
| 266 | 266 | relational database that can easily be queried using concise SQL |
| 267 | 267 | statements to find both ancestors and descendants of a check-in. This is |
| 268 | 268 | the hybrid data model mentioned above: Fossil manages your check-in and |
| 269 | -other data in a NoSQL block chain structured data store, but that's backed | |
| 269 | +other data in a NoSQL [https://en.wikipedia.org/wiki/Merkle_tree | | |
| 270 | +Merkle tree] structured data store, but that's backed | |
| 270 | 271 | by a set of relational lookup tables for quick indexing into that |
| 271 | 272 | artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The |
| 272 | 273 | Fossil DVCS]" for more details.) |
| 273 | 274 | |
| 274 | 275 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| @@ -276,11 +277,11 @@ | ||
| 276 | 277 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 277 | 278 | state] problem has caused untold grief for |
| 278 | 279 | [https://www.google.com/search?q=git+detached+head+state | a huge number |
| 279 | 280 | of Git users]. With |
| 280 | 281 | Fossil, detached heads are simply impossible because we can always find |
| 281 | -our way back into the block chain using one or more of the relational | |
| 282 | +our way back into the Merkle tree using one or more of the relational | |
| 282 | 283 | indices it automatically manages for you. |
| 283 | 284 | |
| 284 | 285 | This design difference shows up in several other places within each |
| 285 | 286 | tool. It is why Fossil's [/help?cmd=timeline|timeline] is generally more |
| 286 | 287 | detailed yet more clear than those available in Git front-ends. |
| @@ -906,11 +907,11 @@ | ||
| 906 | 907 | Almost three years after Fossil solved this problem, the |
| 907 | 908 | [https://sha-mbles.github.io/ | SHAmbles attack] was published, further |
| 908 | 909 | weakening the case for continuing to use SHA-1. |
| 909 | 910 | |
| 910 | 911 | The practical impact of attacks like SHAttered and SHAmbles on the |
| 911 | -Git and Fossil blockchains isn't clear, but you want to have your repositories | |
| 912 | +Git and Fossil Merkle trees isn't clear, but you want to have your repositories | |
| 912 | 913 | moved over to a stronger hash algorithm before someone figures out how |
| 913 | 914 | to make use of the weaknesses in the old one. Fossil has had this covered |
| 914 | 915 | for years now, so that the solution is now almost universally deployed. |
| 915 | 916 | |
| 916 | 917 | <hr/> |
| 917 | 918 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -264,11 +264,12 @@ | |
| 264 | Fossil, on the other hand, parses essential information about check-ins |
| 265 | (parents, children, committers, comments, files changed, etc.) into a |
| 266 | relational database that can easily be queried using concise SQL |
| 267 | statements to find both ancestors and descendants of a check-in. This is |
| 268 | the hybrid data model mentioned above: Fossil manages your check-in and |
| 269 | other data in a NoSQL block chain structured data store, but that's backed |
| 270 | by a set of relational lookup tables for quick indexing into that |
| 271 | artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The |
| 272 | Fossil DVCS]" for more details.) |
| 273 | |
| 274 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| @@ -276,11 +277,11 @@ | |
| 276 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 277 | state] problem has caused untold grief for |
| 278 | [https://www.google.com/search?q=git+detached+head+state | a huge number |
| 279 | of Git users]. With |
| 280 | Fossil, detached heads are simply impossible because we can always find |
| 281 | our way back into the block chain using one or more of the relational |
| 282 | indices it automatically manages for you. |
| 283 | |
| 284 | This design difference shows up in several other places within each |
| 285 | tool. It is why Fossil's [/help?cmd=timeline|timeline] is generally more |
| 286 | detailed yet more clear than those available in Git front-ends. |
| @@ -906,11 +907,11 @@ | |
| 906 | Almost three years after Fossil solved this problem, the |
| 907 | [https://sha-mbles.github.io/ | SHAmbles attack] was published, further |
| 908 | weakening the case for continuing to use SHA-1. |
| 909 | |
| 910 | The practical impact of attacks like SHAttered and SHAmbles on the |
| 911 | Git and Fossil blockchains isn't clear, but you want to have your repositories |
| 912 | moved over to a stronger hash algorithm before someone figures out how |
| 913 | to make use of the weaknesses in the old one. Fossil has had this covered |
| 914 | for years now, so that the solution is now almost universally deployed. |
| 915 | |
| 916 | <hr/> |
| 917 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -264,11 +264,12 @@ | |
| 264 | Fossil, on the other hand, parses essential information about check-ins |
| 265 | (parents, children, committers, comments, files changed, etc.) into a |
| 266 | relational database that can easily be queried using concise SQL |
| 267 | statements to find both ancestors and descendants of a check-in. This is |
| 268 | the hybrid data model mentioned above: Fossil manages your check-in and |
| 269 | other data in a NoSQL [https://en.wikipedia.org/wiki/Merkle_tree | |
| 270 | Merkle tree] structured data store, but that's backed |
| 271 | by a set of relational lookup tables for quick indexing into that |
| 272 | artifact store. (See "[./theory1.wiki|Thoughts On The Design Of The |
| 273 | Fossil DVCS]" for more details.) |
| 274 | |
| 275 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| @@ -276,11 +277,11 @@ | |
| 277 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 278 | state] problem has caused untold grief for |
| 279 | [https://www.google.com/search?q=git+detached+head+state | a huge number |
| 280 | of Git users]. With |
| 281 | Fossil, detached heads are simply impossible because we can always find |
| 282 | our way back into the Merkle tree using one or more of the relational |
| 283 | indices it automatically manages for you. |
| 284 | |
| 285 | This design difference shows up in several other places within each |
| 286 | tool. It is why Fossil's [/help?cmd=timeline|timeline] is generally more |
| 287 | detailed yet more clear than those available in Git front-ends. |
| @@ -906,11 +907,11 @@ | |
| 907 | Almost three years after Fossil solved this problem, the |
| 908 | [https://sha-mbles.github.io/ | SHAmbles attack] was published, further |
| 909 | weakening the case for continuing to use SHA-1. |
| 910 | |
| 911 | The practical impact of attacks like SHAttered and SHAmbles on the |
| 912 | Git and Fossil Merkle trees isn't clear, but you want to have your repositories |
| 913 | moved over to a stronger hash algorithm before someone figures out how |
| 914 | to make use of the weaknesses in the old one. Fossil has had this covered |
| 915 | for years now, so that the solution is now almost universally deployed. |
| 916 | |
| 917 | <hr/> |
| 918 |