Fossil SCM
Further tweaks to grammar.
Commit
fa7f71560f2780cc8fc92aa1a9905824203c25d396ed556f5ce24b37492487f5
Parent
c629e71c25c20f4…
1 file changed
+9
-9
+9
-9
| --- www/hundredandone.md | ||
| +++ www/hundredandone.md | ||
| @@ -487,11 +487,11 @@ | ||
| 487 | 487 | be, depending on repository settings). By default, check-in |
| 488 | 488 | comments can contain hyperlinks, including hyperlinks to |
| 489 | 489 | wiki pages, prior check-ins, forum posts, and interwiki hyperlinks. |
| 490 | 490 | |
| 491 | 491 | 1. **Fossil supports hyperlink back references**<p> |
| 492 | - If the check-in comment for a newer commits contains a hyperlink | |
| 492 | + If the check-in comment for a newer commit contains a hyperlink | |
| 493 | 493 | back to an older commit, then when the web interface shows the |
| 494 | 494 | details of the older commit, it also provides a forward |
| 495 | 495 | reference to the newer commit. |
| 496 | 496 | |
| 497 | 497 | 1. **Fossil supports a graphical timeline display of a bisect.**<p> |
| @@ -503,11 +503,11 @@ | ||
| 503 | 503 | check-in appears, with a single mouse click.**<p> |
| 504 | 504 | You have to configure the repository by giving it the name of the |
| 505 | 505 | tag that you use to mark releases, using the |
| 506 | 506 | [path-to-tag setting](/help/path-to-tag). Suppose you use the tag |
| 507 | 507 | name "release". Once you do that, then |
| 508 | - when your are looking at the "info" page for a check-in, a link | |
| 508 | + when you are looking at the "info" page for a check-in, a link | |
| 509 | 509 | named "path-to-release" appears in the overview section, and if |
| 510 | 510 | you click on that link, it brings up a new graph showing the |
| 511 | 511 | shortest path from that check-in to the next descendant check-in |
| 512 | 512 | tagged with "release". |
| 513 | 513 | <p> |
| @@ -515,11 +515,11 @@ | ||
| 515 | 515 | <https://sqlite.org/src/info/b1d7123bc619e3cb>, in the Overview |
| 516 | 516 | section at the top, to the right of the "Timelines:" label, you |
| 517 | 517 | will see the "path-to-release" link. Click that link to take you |
| 518 | 518 | to a page showing an abbreviated path from the original check-in |
| 519 | 519 | to the first "release" check-in that contains the change. To |
| 520 | - See the full path, uncheck the "Brief" checkbox near the top of the page. | |
| 520 | + see the full path, uncheck the "Brief" checkbox near the top of the page. | |
| 521 | 521 | <p> |
| 522 | 522 | This feature is useful for when you bisect to find a bug, or a bug |
| 523 | 523 | fix, and you want to know the first release in which that bug or bug fix |
| 524 | 524 | appeared. |
| 525 | 525 | |
| @@ -581,12 +581,12 @@ | ||
| 581 | 581 | Then we just cherrypick the check-in onto the correct branch. |
| 582 | 582 | <p> |
| 583 | 583 | If you are using the web interface and if you have check-in privilege |
| 584 | 584 | on the repository, then on the /info page for the check-in, under |
| 585 | 585 | the "Overview" section, to the right of "Other Links:", there is |
| 586 | - an "edit" link that will take you to a page that lets move the check-in | |
| 587 | - to a new branch from the web interface. You can also do this | |
| 586 | + an "edit" link that will take you to a page that lets you move the | |
| 587 | + check-in to a new branch from the web interface. You can also do this | |
| 588 | 588 | from the Fossil command-line, but the web interface is easier and less |
| 589 | 589 | error prone. |
| 590 | 590 | |
| 591 | 591 | 1. **Fossil supports unversioned files**.<p> |
| 592 | 592 | [Unversioned Files](/doc/trunk/www/unvers.wiki) are files held |
| @@ -682,11 +682,11 @@ | ||
| 682 | 682 | changes that I want to test on Windows, I SSH over to the Win11 |
| 683 | 683 | machine then run commands like:<pre> |
| 684 | 684 | fossil patch pull r21:sqlite/sqlite -f |
| 685 | 685 | make clean test</pre> |
| 686 | 686 | But typing in "r21:sqlite/sqlite" can be tedious and error-prone, |
| 687 | - maybe not so much in this particular examples but definitely the | |
| 687 | + maybe not so much in this particular example but definitely the | |
| 688 | 688 | case for longer hostnames and subdirectory paths. Fortunately, |
| 689 | 689 | Fossil allows us to define patch alias. On my Win11 machine, |
| 690 | 690 | the alias named "@" is defined as "r21:sqlite/sqlite" and so I |
| 691 | 691 | can get by with typing just:<pre> |
| 692 | 692 | fossil patch pull @ -f</pre> |
| @@ -693,11 +693,11 @@ | ||
| 693 | 693 | (Aside: the -f option tells the command to first "revert" any |
| 694 | 694 | uncommitted changes currently in the checkout prior to pulling |
| 695 | 695 | over the new ones from r21:sqlite/sqlite. Without that option, the |
| 696 | 696 | changes would be merged.) |
| 697 | 697 | |
| 698 | - 1. **Fossil allows you view uncommitted changes on a remote machine | |
| 698 | + 1. **Fossil allows you to view uncommitted changes on a remote machine | |
| 699 | 699 | in a web browser over SSH.**<p> |
| 700 | 700 | Suppose you have some edits on a remote, headless machine and you |
| 701 | 701 | would like to review those changes. Fossil lets you see those |
| 702 | 702 | changes using a command like:<pre> |
| 703 | 703 | fossil ui remote:path/to/checkout</pre> |
| @@ -988,11 +988,11 @@ | ||
| 988 | 988 | |
| 989 | 989 | 1. **Each Fossil repository keeps an audit trail.**<p> |
| 990 | 990 | For each new artifact received into a Fossil repository, by push or |
| 991 | 991 | pull, or by direct commit from the command line, Fossil records a |
| 992 | 992 | timestamp, username, and an IP address (where applicable) for |
| 993 | - that artifact. If harmful or malicious content is added | |
| 993 | + that artifact. If harmful or malicious content is added to | |
| 994 | 994 | a repository, the repository administrator has the capability to |
| 995 | 995 | trace that content back to its source, so that appropriate |
| 996 | 996 | sanctions can be applied to the malefactor. |
| 997 | 997 | |
| 998 | 998 | 1. **Fossil stores content in a power-safe ACID database.**<p> |
| @@ -1028,11 +1028,11 @@ | ||
| 1028 | 1028 | See, for example, <https://sqlite.org/src/rchvdwnld/20260704>. |
| 1029 | 1029 | That link provides access to the last check-in for the day 2026-07-04. |
| 1030 | 1030 | The last element of the patch can be any hash prefix, timestamp prefix, |
| 1031 | 1031 | or tag that references a check-in.<p> |
| 1032 | 1032 | Tarballs and ZIP archives are expensive to compute, not because Fossil |
| 1033 | - has any difficulty to assembly the content, | |
| 1033 | + has trouble assembling the content, | |
| 1034 | 1034 | but rather because the result must be run through zlib compression. |
| 1035 | 1035 | When computing a new archive, almost all of the CPU time is spent |
| 1036 | 1036 | inside of the zlib compression library. |
| 1037 | 1037 | For an SQLite-size tarball, the zlib compression alone can take as |
| 1038 | 1038 | much as 10 seconds of CPU time. If the tarball/ZIP-archive download |
| 1039 | 1039 |
| --- www/hundredandone.md | |
| +++ www/hundredandone.md | |
| @@ -487,11 +487,11 @@ | |
| 487 | be, depending on repository settings). By default, check-in |
| 488 | comments can contain hyperlinks, including hyperlinks to |
| 489 | wiki pages, prior check-ins, forum posts, and interwiki hyperlinks. |
| 490 | |
| 491 | 1. **Fossil supports hyperlink back references**<p> |
| 492 | If the check-in comment for a newer commits contains a hyperlink |
| 493 | back to an older commit, then when the web interface shows the |
| 494 | details of the older commit, it also provides a forward |
| 495 | reference to the newer commit. |
| 496 | |
| 497 | 1. **Fossil supports a graphical timeline display of a bisect.**<p> |
| @@ -503,11 +503,11 @@ | |
| 503 | check-in appears, with a single mouse click.**<p> |
| 504 | You have to configure the repository by giving it the name of the |
| 505 | tag that you use to mark releases, using the |
| 506 | [path-to-tag setting](/help/path-to-tag). Suppose you use the tag |
| 507 | name "release". Once you do that, then |
| 508 | when your are looking at the "info" page for a check-in, a link |
| 509 | named "path-to-release" appears in the overview section, and if |
| 510 | you click on that link, it brings up a new graph showing the |
| 511 | shortest path from that check-in to the next descendant check-in |
| 512 | tagged with "release". |
| 513 | <p> |
| @@ -515,11 +515,11 @@ | |
| 515 | <https://sqlite.org/src/info/b1d7123bc619e3cb>, in the Overview |
| 516 | section at the top, to the right of the "Timelines:" label, you |
| 517 | will see the "path-to-release" link. Click that link to take you |
| 518 | to a page showing an abbreviated path from the original check-in |
| 519 | to the first "release" check-in that contains the change. To |
| 520 | See the full path, uncheck the "Brief" checkbox near the top of the page. |
| 521 | <p> |
| 522 | This feature is useful for when you bisect to find a bug, or a bug |
| 523 | fix, and you want to know the first release in which that bug or bug fix |
| 524 | appeared. |
| 525 | |
| @@ -581,12 +581,12 @@ | |
| 581 | Then we just cherrypick the check-in onto the correct branch. |
| 582 | <p> |
| 583 | If you are using the web interface and if you have check-in privilege |
| 584 | on the repository, then on the /info page for the check-in, under |
| 585 | the "Overview" section, to the right of "Other Links:", there is |
| 586 | an "edit" link that will take you to a page that lets move the check-in |
| 587 | to a new branch from the web interface. You can also do this |
| 588 | from the Fossil command-line, but the web interface is easier and less |
| 589 | error prone. |
| 590 | |
| 591 | 1. **Fossil supports unversioned files**.<p> |
| 592 | [Unversioned Files](/doc/trunk/www/unvers.wiki) are files held |
| @@ -682,11 +682,11 @@ | |
| 682 | changes that I want to test on Windows, I SSH over to the Win11 |
| 683 | machine then run commands like:<pre> |
| 684 | fossil patch pull r21:sqlite/sqlite -f |
| 685 | make clean test</pre> |
| 686 | But typing in "r21:sqlite/sqlite" can be tedious and error-prone, |
| 687 | maybe not so much in this particular examples but definitely the |
| 688 | case for longer hostnames and subdirectory paths. Fortunately, |
| 689 | Fossil allows us to define patch alias. On my Win11 machine, |
| 690 | the alias named "@" is defined as "r21:sqlite/sqlite" and so I |
| 691 | can get by with typing just:<pre> |
| 692 | fossil patch pull @ -f</pre> |
| @@ -693,11 +693,11 @@ | |
| 693 | (Aside: the -f option tells the command to first "revert" any |
| 694 | uncommitted changes currently in the checkout prior to pulling |
| 695 | over the new ones from r21:sqlite/sqlite. Without that option, the |
| 696 | changes would be merged.) |
| 697 | |
| 698 | 1. **Fossil allows you view uncommitted changes on a remote machine |
| 699 | in a web browser over SSH.**<p> |
| 700 | Suppose you have some edits on a remote, headless machine and you |
| 701 | would like to review those changes. Fossil lets you see those |
| 702 | changes using a command like:<pre> |
| 703 | fossil ui remote:path/to/checkout</pre> |
| @@ -988,11 +988,11 @@ | |
| 988 | |
| 989 | 1. **Each Fossil repository keeps an audit trail.**<p> |
| 990 | For each new artifact received into a Fossil repository, by push or |
| 991 | pull, or by direct commit from the command line, Fossil records a |
| 992 | timestamp, username, and an IP address (where applicable) for |
| 993 | that artifact. If harmful or malicious content is added |
| 994 | a repository, the repository administrator has the capability to |
| 995 | trace that content back to its source, so that appropriate |
| 996 | sanctions can be applied to the malefactor. |
| 997 | |
| 998 | 1. **Fossil stores content in a power-safe ACID database.**<p> |
| @@ -1028,11 +1028,11 @@ | |
| 1028 | See, for example, <https://sqlite.org/src/rchvdwnld/20260704>. |
| 1029 | That link provides access to the last check-in for the day 2026-07-04. |
| 1030 | The last element of the patch can be any hash prefix, timestamp prefix, |
| 1031 | or tag that references a check-in.<p> |
| 1032 | Tarballs and ZIP archives are expensive to compute, not because Fossil |
| 1033 | has any difficulty to assembly the content, |
| 1034 | but rather because the result must be run through zlib compression. |
| 1035 | When computing a new archive, almost all of the CPU time is spent |
| 1036 | inside of the zlib compression library. |
| 1037 | For an SQLite-size tarball, the zlib compression alone can take as |
| 1038 | much as 10 seconds of CPU time. If the tarball/ZIP-archive download |
| 1039 |
| --- www/hundredandone.md | |
| +++ www/hundredandone.md | |
| @@ -487,11 +487,11 @@ | |
| 487 | be, depending on repository settings). By default, check-in |
| 488 | comments can contain hyperlinks, including hyperlinks to |
| 489 | wiki pages, prior check-ins, forum posts, and interwiki hyperlinks. |
| 490 | |
| 491 | 1. **Fossil supports hyperlink back references**<p> |
| 492 | If the check-in comment for a newer commit contains a hyperlink |
| 493 | back to an older commit, then when the web interface shows the |
| 494 | details of the older commit, it also provides a forward |
| 495 | reference to the newer commit. |
| 496 | |
| 497 | 1. **Fossil supports a graphical timeline display of a bisect.**<p> |
| @@ -503,11 +503,11 @@ | |
| 503 | check-in appears, with a single mouse click.**<p> |
| 504 | You have to configure the repository by giving it the name of the |
| 505 | tag that you use to mark releases, using the |
| 506 | [path-to-tag setting](/help/path-to-tag). Suppose you use the tag |
| 507 | name "release". Once you do that, then |
| 508 | when you are looking at the "info" page for a check-in, a link |
| 509 | named "path-to-release" appears in the overview section, and if |
| 510 | you click on that link, it brings up a new graph showing the |
| 511 | shortest path from that check-in to the next descendant check-in |
| 512 | tagged with "release". |
| 513 | <p> |
| @@ -515,11 +515,11 @@ | |
| 515 | <https://sqlite.org/src/info/b1d7123bc619e3cb>, in the Overview |
| 516 | section at the top, to the right of the "Timelines:" label, you |
| 517 | will see the "path-to-release" link. Click that link to take you |
| 518 | to a page showing an abbreviated path from the original check-in |
| 519 | to the first "release" check-in that contains the change. To |
| 520 | see the full path, uncheck the "Brief" checkbox near the top of the page. |
| 521 | <p> |
| 522 | This feature is useful for when you bisect to find a bug, or a bug |
| 523 | fix, and you want to know the first release in which that bug or bug fix |
| 524 | appeared. |
| 525 | |
| @@ -581,12 +581,12 @@ | |
| 581 | Then we just cherrypick the check-in onto the correct branch. |
| 582 | <p> |
| 583 | If you are using the web interface and if you have check-in privilege |
| 584 | on the repository, then on the /info page for the check-in, under |
| 585 | the "Overview" section, to the right of "Other Links:", there is |
| 586 | an "edit" link that will take you to a page that lets you move the |
| 587 | check-in to a new branch from the web interface. You can also do this |
| 588 | from the Fossil command-line, but the web interface is easier and less |
| 589 | error prone. |
| 590 | |
| 591 | 1. **Fossil supports unversioned files**.<p> |
| 592 | [Unversioned Files](/doc/trunk/www/unvers.wiki) are files held |
| @@ -682,11 +682,11 @@ | |
| 682 | changes that I want to test on Windows, I SSH over to the Win11 |
| 683 | machine then run commands like:<pre> |
| 684 | fossil patch pull r21:sqlite/sqlite -f |
| 685 | make clean test</pre> |
| 686 | But typing in "r21:sqlite/sqlite" can be tedious and error-prone, |
| 687 | maybe not so much in this particular example but definitely the |
| 688 | case for longer hostnames and subdirectory paths. Fortunately, |
| 689 | Fossil allows us to define patch alias. On my Win11 machine, |
| 690 | the alias named "@" is defined as "r21:sqlite/sqlite" and so I |
| 691 | can get by with typing just:<pre> |
| 692 | fossil patch pull @ -f</pre> |
| @@ -693,11 +693,11 @@ | |
| 693 | (Aside: the -f option tells the command to first "revert" any |
| 694 | uncommitted changes currently in the checkout prior to pulling |
| 695 | over the new ones from r21:sqlite/sqlite. Without that option, the |
| 696 | changes would be merged.) |
| 697 | |
| 698 | 1. **Fossil allows you to view uncommitted changes on a remote machine |
| 699 | in a web browser over SSH.**<p> |
| 700 | Suppose you have some edits on a remote, headless machine and you |
| 701 | would like to review those changes. Fossil lets you see those |
| 702 | changes using a command like:<pre> |
| 703 | fossil ui remote:path/to/checkout</pre> |
| @@ -988,11 +988,11 @@ | |
| 988 | |
| 989 | 1. **Each Fossil repository keeps an audit trail.**<p> |
| 990 | For each new artifact received into a Fossil repository, by push or |
| 991 | pull, or by direct commit from the command line, Fossil records a |
| 992 | timestamp, username, and an IP address (where applicable) for |
| 993 | that artifact. If harmful or malicious content is added to |
| 994 | a repository, the repository administrator has the capability to |
| 995 | trace that content back to its source, so that appropriate |
| 996 | sanctions can be applied to the malefactor. |
| 997 | |
| 998 | 1. **Fossil stores content in a power-safe ACID database.**<p> |
| @@ -1028,11 +1028,11 @@ | |
| 1028 | See, for example, <https://sqlite.org/src/rchvdwnld/20260704>. |
| 1029 | That link provides access to the last check-in for the day 2026-07-04. |
| 1030 | The last element of the patch can be any hash prefix, timestamp prefix, |
| 1031 | or tag that references a check-in.<p> |
| 1032 | Tarballs and ZIP archives are expensive to compute, not because Fossil |
| 1033 | has trouble assembling the content, |
| 1034 | but rather because the result must be run through zlib compression. |
| 1035 | When computing a new archive, almost all of the CPU time is spent |
| 1036 | inside of the zlib compression library. |
| 1037 | For an SQLite-size tarball, the zlib compression alone can take as |
| 1038 | much as 10 seconds of CPU time. If the tarball/ZIP-archive download |
| 1039 |