Fossil SCM
Still moer grammar fixes in fossil-v-git
Commit
e28c25e497a462b46fd029faa5406a26003068829bdd1a3fe858a5c9d8d72f89
Parent
9f135f2f4c753f9…
1 file changed
+13
-11
+13
-11
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -289,14 +289,14 @@ | ||
| 289 | 289 | |
| 290 | 290 | The ease of querying Fossil data using SQL means that status or |
| 291 | 291 | history information about the project under management is easier |
| 292 | 292 | to obtain. Being easier means that it is more likely to happen. |
| 293 | 293 | Fossil reports tend to be more detailed and useful. |
| 294 | -Consider the [/timeline?c=6df7a853ec16865b|this Fossil timeline] | |
| 295 | -compared to | |
| 294 | +Compare [/timeline?c=6df7a853ec16865b|this Fossil timeline] | |
| 295 | +to | |
| 296 | 296 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34 | |
| 297 | -its closest equivalent in GitHub]. Judge for yourself: Which of those | |
| 297 | +its closest equivalent in GitHub]. Judge for yourself: which of those | |
| 298 | 298 | reports is more useful to a developer trying to understand what happened? |
| 299 | 299 | |
| 300 | 300 | The bottom line is that even though Fossil and Git are built around |
| 301 | 301 | the same low-level data structure, the use of SQL |
| 302 | 302 | to query this data makes the data more accessible in Fossil, resulting |
| @@ -513,21 +513,21 @@ | ||
| 513 | 513 | contexts, such as in the [https://en.wikipedia.org/wiki/OODA_loop | OODA |
| 514 | 514 | loop] concept. |
| 515 | 515 | Committing your changes to private branches in order to delay a public |
| 516 | 516 | push to the parent repo increases the size of your collaborators' |
| 517 | 517 | control loops, either causing them to slow their work in order to safely |
| 518 | -react to your work, or to overcorrect in response to each change. | |
| 518 | +react to your work, or to over-correct in response to each change. | |
| 519 | 519 | |
| 520 | 520 | Each DVCS can be used in the opposite style, but doing so works against |
| 521 | 521 | their low-friction paths. |
| 522 | 522 | |
| 523 | 523 | |
| 524 | 524 | <h4 id="scale">2.5.2 Scale</h4> |
| 525 | 525 | |
| 526 | 526 | The Linux kernel has a far bigger developer community than that of |
| 527 | 527 | SQLite: there are thousands and thousands of contributors to Linux, most |
| 528 | -of whom do not know each others names. These thousands are responsible | |
| 528 | +of whom do not know each other's names. These thousands are responsible | |
| 529 | 529 | for producing roughly 89× more code than is in SQLite. (10.7 |
| 530 | 530 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC |
| 531 | 531 | according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux |
| 532 | 532 | kernel and its development process were already uncommonly large back in |
| 533 | 533 | 2005 when Git was designed, specifically to support the consequences of |
| @@ -570,13 +570,13 @@ | ||
| 570 | 570 | |
| 571 | 571 | This difference in emphasis arises from the different purposes of |
| 572 | 572 | the two systems. Git focuses on individual branches, because that |
| 573 | 573 | is exactly what you want for a highly-distributed bazaar-style project |
| 574 | 574 | such as Linux. Linus Torvalds does not want to see every check-in |
| 575 | -by every contributor to Linux, as such extreme visibility does not scale | |
| 576 | -well. But Fossil was written for the cathedral-style SQLite project | |
| 577 | -with just a handful of active committers. Seeing all | |
| 575 | +by every contributor to Linux: such extreme visibility does not scale | |
| 576 | +well. Contrast Fossil, which was written for the cathedral-style SQLite project | |
| 577 | +and its handful of active committers. Seeing all | |
| 578 | 578 | changes on all branches all at once helps keep the whole team |
| 579 | 579 | up-to-date with what everybody else is doing, resulting in a more |
| 580 | 580 | tightly focused and cohesive implementation. |
| 581 | 581 | |
| 582 | 582 | |
| @@ -639,12 +639,14 @@ | ||
| 639 | 639 | away in a working directory, then get a call from a customer requiring |
| 640 | 640 | that you switch to a stable branch to answer questions in terms of the |
| 641 | 641 | version that customer is running. You don't want to stop the test in |
| 642 | 642 | order to switch your lone working directory to the stable branch. |
| 643 | 643 | |
| 644 | -Disk space is cheap. Having several working directories, each with its | |
| 645 | -own local state, makes switching versions cheap and fast. Plus, | |
| 644 | +Disk space is cheap. Having several working directories — each with its | |
| 645 | +own local state — makes switching versions cheap and fast. | |
| 646 | + | |
| 647 | +Plus, | |
| 646 | 648 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 647 | 649 | update</tt>. |
| 648 | 650 | |
| 649 | 651 | |
| 650 | 652 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| @@ -663,11 +665,11 @@ | ||
| 663 | 665 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 664 | 666 | including all of the messy errors, dead-ends, experimental branches, and |
| 665 | 667 | so forth. One might argue that this |
| 666 | 668 | makes the history of a Fossil project "messy," but another point of view |
| 667 | 669 | is that this makes the history "accurate." In actual practice, the |
| 668 | -superior reporting tools available in Fossil mean that the added "mess" | |
| 670 | +superior reporting tools available in Fossil mean that this incidental mess | |
| 669 | 671 | is not a factor. |
| 670 | 672 | |
| 671 | 673 | Like Git, Fossil has an [/help?cmd=amend|amend command] for modifying |
| 672 | 674 | prior commits, but unlike in Git, this works not by replacing data in |
| 673 | 675 | the repository, but by adding a correction record to the repository that |
| 674 | 676 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -289,14 +289,14 @@ | |
| 289 | |
| 290 | The ease of querying Fossil data using SQL means that status or |
| 291 | history information about the project under management is easier |
| 292 | to obtain. Being easier means that it is more likely to happen. |
| 293 | Fossil reports tend to be more detailed and useful. |
| 294 | Consider the [/timeline?c=6df7a853ec16865b|this Fossil timeline] |
| 295 | compared to |
| 296 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34 | |
| 297 | its closest equivalent in GitHub]. Judge for yourself: Which of those |
| 298 | reports is more useful to a developer trying to understand what happened? |
| 299 | |
| 300 | The bottom line is that even though Fossil and Git are built around |
| 301 | the same low-level data structure, the use of SQL |
| 302 | to query this data makes the data more accessible in Fossil, resulting |
| @@ -513,21 +513,21 @@ | |
| 513 | contexts, such as in the [https://en.wikipedia.org/wiki/OODA_loop | OODA |
| 514 | loop] concept. |
| 515 | Committing your changes to private branches in order to delay a public |
| 516 | push to the parent repo increases the size of your collaborators' |
| 517 | control loops, either causing them to slow their work in order to safely |
| 518 | react to your work, or to overcorrect in response to each change. |
| 519 | |
| 520 | Each DVCS can be used in the opposite style, but doing so works against |
| 521 | their low-friction paths. |
| 522 | |
| 523 | |
| 524 | <h4 id="scale">2.5.2 Scale</h4> |
| 525 | |
| 526 | The Linux kernel has a far bigger developer community than that of |
| 527 | SQLite: there are thousands and thousands of contributors to Linux, most |
| 528 | of whom do not know each others names. These thousands are responsible |
| 529 | for producing roughly 89× more code than is in SQLite. (10.7 |
| 530 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC |
| 531 | according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux |
| 532 | kernel and its development process were already uncommonly large back in |
| 533 | 2005 when Git was designed, specifically to support the consequences of |
| @@ -570,13 +570,13 @@ | |
| 570 | |
| 571 | This difference in emphasis arises from the different purposes of |
| 572 | the two systems. Git focuses on individual branches, because that |
| 573 | is exactly what you want for a highly-distributed bazaar-style project |
| 574 | such as Linux. Linus Torvalds does not want to see every check-in |
| 575 | by every contributor to Linux, as such extreme visibility does not scale |
| 576 | well. But Fossil was written for the cathedral-style SQLite project |
| 577 | with just a handful of active committers. Seeing all |
| 578 | changes on all branches all at once helps keep the whole team |
| 579 | up-to-date with what everybody else is doing, resulting in a more |
| 580 | tightly focused and cohesive implementation. |
| 581 | |
| 582 | |
| @@ -639,12 +639,14 @@ | |
| 639 | away in a working directory, then get a call from a customer requiring |
| 640 | that you switch to a stable branch to answer questions in terms of the |
| 641 | version that customer is running. You don't want to stop the test in |
| 642 | order to switch your lone working directory to the stable branch. |
| 643 | |
| 644 | Disk space is cheap. Having several working directories, each with its |
| 645 | own local state, makes switching versions cheap and fast. Plus, |
| 646 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 647 | update</tt>. |
| 648 | |
| 649 | |
| 650 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| @@ -663,11 +665,11 @@ | |
| 663 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 664 | including all of the messy errors, dead-ends, experimental branches, and |
| 665 | so forth. One might argue that this |
| 666 | makes the history of a Fossil project "messy," but another point of view |
| 667 | is that this makes the history "accurate." In actual practice, the |
| 668 | superior reporting tools available in Fossil mean that the added "mess" |
| 669 | is not a factor. |
| 670 | |
| 671 | Like Git, Fossil has an [/help?cmd=amend|amend command] for modifying |
| 672 | prior commits, but unlike in Git, this works not by replacing data in |
| 673 | the repository, but by adding a correction record to the repository that |
| 674 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -289,14 +289,14 @@ | |
| 289 | |
| 290 | The ease of querying Fossil data using SQL means that status or |
| 291 | history information about the project under management is easier |
| 292 | to obtain. Being easier means that it is more likely to happen. |
| 293 | Fossil reports tend to be more detailed and useful. |
| 294 | Compare [/timeline?c=6df7a853ec16865b|this Fossil timeline] |
| 295 | to |
| 296 | [https://github.com/drhsqlite/fossil-mirror/commits/master?after=f720c106d297ca1f61bccb30c5c191b88a626d01+34 | |
| 297 | its closest equivalent in GitHub]. Judge for yourself: which of those |
| 298 | reports is more useful to a developer trying to understand what happened? |
| 299 | |
| 300 | The bottom line is that even though Fossil and Git are built around |
| 301 | the same low-level data structure, the use of SQL |
| 302 | to query this data makes the data more accessible in Fossil, resulting |
| @@ -513,21 +513,21 @@ | |
| 513 | contexts, such as in the [https://en.wikipedia.org/wiki/OODA_loop | OODA |
| 514 | loop] concept. |
| 515 | Committing your changes to private branches in order to delay a public |
| 516 | push to the parent repo increases the size of your collaborators' |
| 517 | control loops, either causing them to slow their work in order to safely |
| 518 | react to your work, or to over-correct in response to each change. |
| 519 | |
| 520 | Each DVCS can be used in the opposite style, but doing so works against |
| 521 | their low-friction paths. |
| 522 | |
| 523 | |
| 524 | <h4 id="scale">2.5.2 Scale</h4> |
| 525 | |
| 526 | The Linux kernel has a far bigger developer community than that of |
| 527 | SQLite: there are thousands and thousands of contributors to Linux, most |
| 528 | of whom do not know each other's names. These thousands are responsible |
| 529 | for producing roughly 89× more code than is in SQLite. (10.7 |
| 530 | [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC |
| 531 | according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux |
| 532 | kernel and its development process were already uncommonly large back in |
| 533 | 2005 when Git was designed, specifically to support the consequences of |
| @@ -570,13 +570,13 @@ | |
| 570 | |
| 571 | This difference in emphasis arises from the different purposes of |
| 572 | the two systems. Git focuses on individual branches, because that |
| 573 | is exactly what you want for a highly-distributed bazaar-style project |
| 574 | such as Linux. Linus Torvalds does not want to see every check-in |
| 575 | by every contributor to Linux: such extreme visibility does not scale |
| 576 | well. Contrast Fossil, which was written for the cathedral-style SQLite project |
| 577 | and its handful of active committers. Seeing all |
| 578 | changes on all branches all at once helps keep the whole team |
| 579 | up-to-date with what everybody else is doing, resulting in a more |
| 580 | tightly focused and cohesive implementation. |
| 581 | |
| 582 | |
| @@ -639,12 +639,14 @@ | |
| 639 | away in a working directory, then get a call from a customer requiring |
| 640 | that you switch to a stable branch to answer questions in terms of the |
| 641 | version that customer is running. You don't want to stop the test in |
| 642 | order to switch your lone working directory to the stable branch. |
| 643 | |
| 644 | Disk space is cheap. Having several working directories — each with its |
| 645 | own local state — makes switching versions cheap and fast. |
| 646 | |
| 647 | Plus, |
| 648 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 649 | update</tt>. |
| 650 | |
| 651 | |
| 652 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| @@ -663,11 +665,11 @@ | |
| 665 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 666 | including all of the messy errors, dead-ends, experimental branches, and |
| 667 | so forth. One might argue that this |
| 668 | makes the history of a Fossil project "messy," but another point of view |
| 669 | is that this makes the history "accurate." In actual practice, the |
| 670 | superior reporting tools available in Fossil mean that this incidental mess |
| 671 | is not a factor. |
| 672 | |
| 673 | Like Git, Fossil has an [/help?cmd=amend|amend command] for modifying |
| 674 | prior commits, but unlike in Git, this works not by replacing data in |
| 675 | the repository, but by adding a correction record to the repository that |
| 676 |