Fossil SCM
Prior section 2.5 in fossil-v-git is now section 2.4.4, since it's part of the "2.4 Linux vs SQLite" story. Little change in content; primarily just an organization fix.
Commit
e9628d7063e080299144d13e9567ea40d5afdc82b68f2485bbe97def5c32c96b
Parent
5c24bee9fd5abaf…
1 file changed
+5
-5
+5
-5
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -185,11 +185,11 @@ | ||
| 185 | 185 | Fossil to support the development of [https://sqlite.org/|SQLite]. |
| 186 | 186 | Both projects must rank high on any objective list of "most |
| 187 | 187 | important FOSS projects," yet these two projects are almost entirely unlike |
| 188 | 188 | one another. So, too, are these two DVCSes. |
| 189 | 189 | |
| 190 | -In the following sections, we will explain how three key differences | |
| 190 | +In the following sections, we will explain how four key differences | |
| 191 | 191 | between Linux and SQLite dictated the design of each DVCS's low-friction |
| 192 | 192 | usage path. |
| 193 | 193 | |
| 194 | 194 | When deciding between these two DVCSes, you should ask yourself, "Is my |
| 195 | 195 | project more like Linux or more like SQLite?" |
| @@ -378,11 +378,11 @@ | ||
| 378 | 378 | The end result is that Fossil more closely adheres to |
| 379 | 379 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 380 | 380 | principle of least astonishment] than Git does. |
| 381 | 381 | |
| 382 | 382 | |
| 383 | -<h3 id="branches">2.5 Individual Branches vs. The Entire Change History</h3> | |
| 383 | +<h4 id="branches">2.4.4 Individual Branches vs. The Entire Change History</h4> | |
| 384 | 384 | |
| 385 | 385 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 386 | 386 | of changes, but Git tends to focus more on individual branches of |
| 387 | 387 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 388 | 388 | |
| @@ -407,11 +407,11 @@ | ||
| 407 | 407 | changes on all branches all at once helps keep the whole team |
| 408 | 408 | up-to-date with what everybody else is doing, resulting in a more |
| 409 | 409 | tightly focused and cohesive implementation. |
| 410 | 410 | |
| 411 | 411 | |
| 412 | -<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> | |
| 412 | +<h3 id="checkouts">2.5 One vs. Many Check-outs per Repository</h3> | |
| 413 | 413 | |
| 414 | 414 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 415 | 415 | of a single check-out. The check-out and the repository are located |
| 416 | 416 | together in the filesystem. |
| 417 | 417 | |
| @@ -439,11 +439,11 @@ | ||
| 439 | 439 | you can switch branches with a "cd" command rather than replace the |
| 440 | 440 | current working file set with a different file set by updating in place, |
| 441 | 441 | as Git prefers. |
| 442 | 442 | |
| 443 | 443 | |
| 444 | -<h3 id="history">2.7 What you should have done vs. What you actually did</h3> | |
| 444 | +<h3 id="history">2.6 What you should have done vs. What you actually did</h3> | |
| 445 | 445 | |
| 446 | 446 | Git puts a lot of emphasis on maintaining |
| 447 | 447 | a "clean" check-in history. Extraneous and experimental branches by |
| 448 | 448 | individual developers often never make it into the main repository. And |
| 449 | 449 | branches are often rebased before being pushed, to make |
| @@ -470,11 +470,11 @@ | ||
| 470 | 470 | |
| 471 | 471 | One commentator characterized Git as recording history according to |
| 472 | 472 | the victors, whereas Fossil records history as it actually happened. |
| 473 | 473 | |
| 474 | 474 | |
| 475 | -<h3 id="hash">2.8 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> | |
| 475 | +<h3 id="hash">2.7 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> | |
| 476 | 476 | |
| 477 | 477 | Fossil started out using 160-bit SHA-1 hashes to identify check-ins, |
| 478 | 478 | just as in Git. That changed in early 2017 when news of the |
| 479 | 479 | [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1 |
| 480 | 480 | collisions were now practical to create. Two weeks later, the creator of |
| 481 | 481 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -185,11 +185,11 @@ | |
| 185 | Fossil to support the development of [https://sqlite.org/|SQLite]. |
| 186 | Both projects must rank high on any objective list of "most |
| 187 | important FOSS projects," yet these two projects are almost entirely unlike |
| 188 | one another. So, too, are these two DVCSes. |
| 189 | |
| 190 | In the following sections, we will explain how three key differences |
| 191 | between Linux and SQLite dictated the design of each DVCS's low-friction |
| 192 | usage path. |
| 193 | |
| 194 | When deciding between these two DVCSes, you should ask yourself, "Is my |
| 195 | project more like Linux or more like SQLite?" |
| @@ -378,11 +378,11 @@ | |
| 378 | The end result is that Fossil more closely adheres to |
| 379 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 380 | principle of least astonishment] than Git does. |
| 381 | |
| 382 | |
| 383 | <h3 id="branches">2.5 Individual Branches vs. The Entire Change History</h3> |
| 384 | |
| 385 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 386 | of changes, but Git tends to focus more on individual branches of |
| 387 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 388 | |
| @@ -407,11 +407,11 @@ | |
| 407 | changes on all branches all at once helps keep the whole team |
| 408 | up-to-date with what everybody else is doing, resulting in a more |
| 409 | tightly focused and cohesive implementation. |
| 410 | |
| 411 | |
| 412 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 413 | |
| 414 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 415 | of a single check-out. The check-out and the repository are located |
| 416 | together in the filesystem. |
| 417 | |
| @@ -439,11 +439,11 @@ | |
| 439 | you can switch branches with a "cd" command rather than replace the |
| 440 | current working file set with a different file set by updating in place, |
| 441 | as Git prefers. |
| 442 | |
| 443 | |
| 444 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 445 | |
| 446 | Git puts a lot of emphasis on maintaining |
| 447 | a "clean" check-in history. Extraneous and experimental branches by |
| 448 | individual developers often never make it into the main repository. And |
| 449 | branches are often rebased before being pushed, to make |
| @@ -470,11 +470,11 @@ | |
| 470 | |
| 471 | One commentator characterized Git as recording history according to |
| 472 | the victors, whereas Fossil records history as it actually happened. |
| 473 | |
| 474 | |
| 475 | <h3 id="hash">2.8 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> |
| 476 | |
| 477 | Fossil started out using 160-bit SHA-1 hashes to identify check-ins, |
| 478 | just as in Git. That changed in early 2017 when news of the |
| 479 | [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1 |
| 480 | collisions were now practical to create. Two weeks later, the creator of |
| 481 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -185,11 +185,11 @@ | |
| 185 | Fossil to support the development of [https://sqlite.org/|SQLite]. |
| 186 | Both projects must rank high on any objective list of "most |
| 187 | important FOSS projects," yet these two projects are almost entirely unlike |
| 188 | one another. So, too, are these two DVCSes. |
| 189 | |
| 190 | In the following sections, we will explain how four key differences |
| 191 | between Linux and SQLite dictated the design of each DVCS's low-friction |
| 192 | usage path. |
| 193 | |
| 194 | When deciding between these two DVCSes, you should ask yourself, "Is my |
| 195 | project more like Linux or more like SQLite?" |
| @@ -378,11 +378,11 @@ | |
| 378 | The end result is that Fossil more closely adheres to |
| 379 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 380 | principle of least astonishment] than Git does. |
| 381 | |
| 382 | |
| 383 | <h4 id="branches">2.4.4 Individual Branches vs. The Entire Change History</h4> |
| 384 | |
| 385 | Both Fossil and Git store history as a directed acyclic graph (DAG) |
| 386 | of changes, but Git tends to focus more on individual branches of |
| 387 | the DAG, whereas Fossil puts more emphasis on the entire DAG. |
| 388 | |
| @@ -407,11 +407,11 @@ | |
| 407 | changes on all branches all at once helps keep the whole team |
| 408 | up-to-date with what everybody else is doing, resulting in a more |
| 409 | tightly focused and cohesive implementation. |
| 410 | |
| 411 | |
| 412 | <h3 id="checkouts">2.5 One vs. Many Check-outs per Repository</h3> |
| 413 | |
| 414 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 415 | of a single check-out. The check-out and the repository are located |
| 416 | together in the filesystem. |
| 417 | |
| @@ -439,11 +439,11 @@ | |
| 439 | you can switch branches with a "cd" command rather than replace the |
| 440 | current working file set with a different file set by updating in place, |
| 441 | as Git prefers. |
| 442 | |
| 443 | |
| 444 | <h3 id="history">2.6 What you should have done vs. What you actually did</h3> |
| 445 | |
| 446 | Git puts a lot of emphasis on maintaining |
| 447 | a "clean" check-in history. Extraneous and experimental branches by |
| 448 | individual developers often never make it into the main repository. And |
| 449 | branches are often rebased before being pushed, to make |
| @@ -470,11 +470,11 @@ | |
| 470 | |
| 471 | One commentator characterized Git as recording history according to |
| 472 | the victors, whereas Fossil records history as it actually happened. |
| 473 | |
| 474 | |
| 475 | <h3 id="hash">2.7 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3> |
| 476 | |
| 477 | Fossil started out using 160-bit SHA-1 hashes to identify check-ins, |
| 478 | just as in Git. That changed in early 2017 when news of the |
| 479 | [https://shattered.io/|SHAttered attack] broke, demonstrating that SHA-1 |
| 480 | collisions were now practical to create. Two weeks later, the creator of |
| 481 |