Fossil SCM
Fix typos in Markdown and Wiki pages.
Commit
e755561d7358fb7bf1d140ca78c51f47aad72602213213995b00d7f3eaacff03
Parent
2f78b2cb413d4fc…
24 files changed
+1
-1
+3
-3
+1
-1
+1
-1
+3
-3
+1
-1
+2
-2
+3
-3
+2
-2
+1
-1
+1
-1
+2
-2
+2
-2
+1
-1
+1
-1
+1
-1
+4
-4
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
~
src/wiki.wiki
~
www/blockchain.md
~
www/build.wiki
~
www/caps/admin-v-setup.md
~
www/changes.wiki
~
www/css-tricks.md
~
www/customskin.md
~
www/defcsp.md
~
www/env-opts.md
~
www/fileedit-page.md
~
www/gitusers.md
~
www/globs.md
~
www/history.md
~
www/hooks.md
~
www/image-format-vs-repo-size.md
~
www/makefile.wiki
~
www/quickstart.wiki
~
www/rebaseharm.md
~
www/server/any/althttpd.md
~
www/server/debian/service.md
~
www/server/openbsd/fastcgi.md
~
www/server/whyuseaserver.wiki
~
www/shunning.wiki
~
www/ssl.wiki
+1
-1
| --- src/wiki.wiki | ||
| +++ src/wiki.wiki | ||
| @@ -32,11 +32,11 @@ | ||
| 32 | 32 | character surrounded on both sides by two or more spaces or by a tab. |
| 33 | 33 | Or it can be a number and a "." (ex: "5.") surrounded on both sides |
| 34 | 34 | by two spaces or a tab. |
| 35 | 35 | Only a single level of enumeration list is supported by wiki. |
| 36 | 36 | For nested lists or for enumerations that count using letters or |
| 37 | - roman numerials, use HTML. | |
| 37 | + roman numerals, use HTML. | |
| 38 | 38 | |
| 39 | 39 | 4. <b>Indented Paragraphs.</b> |
| 40 | 40 | Any paragraph that begins with two or more spaces or a tab and which |
| 41 | 41 | is not a bullet or enumeration list item is rendered indented. |
| 42 | 42 | Only a single level of indentation is supported by wiki. |
| 43 | 43 |
| --- src/wiki.wiki | |
| +++ src/wiki.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | character surrounded on both sides by two or more spaces or by a tab. |
| 33 | Or it can be a number and a "." (ex: "5.") surrounded on both sides |
| 34 | by two spaces or a tab. |
| 35 | Only a single level of enumeration list is supported by wiki. |
| 36 | For nested lists or for enumerations that count using letters or |
| 37 | roman numerials, use HTML. |
| 38 | |
| 39 | 4. <b>Indented Paragraphs.</b> |
| 40 | Any paragraph that begins with two or more spaces or a tab and which |
| 41 | is not a bullet or enumeration list item is rendered indented. |
| 42 | Only a single level of indentation is supported by wiki. |
| 43 |
| --- src/wiki.wiki | |
| +++ src/wiki.wiki | |
| @@ -32,11 +32,11 @@ | |
| 32 | character surrounded on both sides by two or more spaces or by a tab. |
| 33 | Or it can be a number and a "." (ex: "5.") surrounded on both sides |
| 34 | by two spaces or a tab. |
| 35 | Only a single level of enumeration list is supported by wiki. |
| 36 | For nested lists or for enumerations that count using letters or |
| 37 | roman numerals, use HTML. |
| 38 | |
| 39 | 4. <b>Indented Paragraphs.</b> |
| 40 | Any paragraph that begins with two or more spaces or a tab and which |
| 41 | is not a bullet or enumeration list item is rendered indented. |
| 42 | Only a single level of indentation is supported by wiki. |
| 43 |
+3
-3
| --- www/blockchain.md | ||
| +++ www/blockchain.md | ||
| @@ -80,11 +80,11 @@ | ||
| 80 | 80 | hash chain that applies an ordering and lookup scheme to the blocks. |
| 81 | 81 | [_Blockchain: Simple Explanation_][bse] explains this “hash chain” |
| 82 | 82 | vs. “block chain” distinction in more detail. |
| 83 | 83 | |
| 84 | 84 | These signatures prevent modification of the face value of each |
| 85 | - transation (Type 1 fraud) by ensuring that only the one signing a | |
| 85 | + transaction (Type 1 fraud) by ensuring that only the one signing a | |
| 86 | 86 | new block has the private signing key that could change an issued |
| 87 | 87 | block after the fact. |
| 88 | 88 | |
| 89 | 89 | The fact that these signatures are also *chained* prevents Type |
| 90 | 90 | 3 frauds by making the *prior* owner of a block sign it over to |
| @@ -119,11 +119,11 @@ | ||
| 119 | 119 | to [later](#work). |
| 120 | 120 | |
| 121 | 121 | Although you have complete control over the contents of your local |
| 122 | 122 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| 123 | 123 | contents short of executing a [preimage attack][prei] on the hash |
| 124 | - algorthm. ([SHA3-256][SHA-3] by default in the current version of | |
| 124 | + algorithm. ([SHA3-256][SHA-3] by default in the current version of | |
| 125 | 125 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 126 | 126 | modification from being pushed into another repository: the remote |
| 127 | 127 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 128 | 128 | ignores the push. Thus, short of breaking into the remote server |
| 129 | 129 | and modifying the repository in place, you couldn’t even make use of |
| @@ -146,11 +146,11 @@ | ||
| 146 | 146 | |
| 147 | 147 | If Fossil signatures prevent Type 1 and Type 2 frauds, you |
| 148 | 148 | may wonder why they are not enabled by default. It is because |
| 149 | 149 | they are defense-in-depth measures, not the minimum sufficient |
| 150 | 150 | measures needed to prevent repository fraud, unlike the equivalent |
| 151 | - protections in a cryptocurrency blockcahin. Fossil provides its | |
| 151 | + protections in a cryptocurrency blockchain. Fossil provides its | |
| 152 | 152 | primary protections through other means, so it doesn’t need to |
| 153 | 153 | mandate signatures. |
| 154 | 154 | |
| 155 | 155 | Also, Fossil is not itself a [PKI], and there is no way for regular |
| 156 | 156 | users of Fossil to link it to a PKI, since doing so would likely |
| 157 | 157 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -80,11 +80,11 @@ | |
| 80 | hash chain that applies an ordering and lookup scheme to the blocks. |
| 81 | [_Blockchain: Simple Explanation_][bse] explains this “hash chain” |
| 82 | vs. “block chain” distinction in more detail. |
| 83 | |
| 84 | These signatures prevent modification of the face value of each |
| 85 | transation (Type 1 fraud) by ensuring that only the one signing a |
| 86 | new block has the private signing key that could change an issued |
| 87 | block after the fact. |
| 88 | |
| 89 | The fact that these signatures are also *chained* prevents Type |
| 90 | 3 frauds by making the *prior* owner of a block sign it over to |
| @@ -119,11 +119,11 @@ | |
| 119 | to [later](#work). |
| 120 | |
| 121 | Although you have complete control over the contents of your local |
| 122 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| 123 | contents short of executing a [preimage attack][prei] on the hash |
| 124 | algorthm. ([SHA3-256][SHA-3] by default in the current version of |
| 125 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 126 | modification from being pushed into another repository: the remote |
| 127 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 128 | ignores the push. Thus, short of breaking into the remote server |
| 129 | and modifying the repository in place, you couldn’t even make use of |
| @@ -146,11 +146,11 @@ | |
| 146 | |
| 147 | If Fossil signatures prevent Type 1 and Type 2 frauds, you |
| 148 | may wonder why they are not enabled by default. It is because |
| 149 | they are defense-in-depth measures, not the minimum sufficient |
| 150 | measures needed to prevent repository fraud, unlike the equivalent |
| 151 | protections in a cryptocurrency blockcahin. Fossil provides its |
| 152 | primary protections through other means, so it doesn’t need to |
| 153 | mandate signatures. |
| 154 | |
| 155 | Also, Fossil is not itself a [PKI], and there is no way for regular |
| 156 | users of Fossil to link it to a PKI, since doing so would likely |
| 157 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -80,11 +80,11 @@ | |
| 80 | hash chain that applies an ordering and lookup scheme to the blocks. |
| 81 | [_Blockchain: Simple Explanation_][bse] explains this “hash chain” |
| 82 | vs. “block chain” distinction in more detail. |
| 83 | |
| 84 | These signatures prevent modification of the face value of each |
| 85 | transaction (Type 1 fraud) by ensuring that only the one signing a |
| 86 | new block has the private signing key that could change an issued |
| 87 | block after the fact. |
| 88 | |
| 89 | The fact that these signatures are also *chained* prevents Type |
| 90 | 3 frauds by making the *prior* owner of a block sign it over to |
| @@ -119,11 +119,11 @@ | |
| 119 | to [later](#work). |
| 120 | |
| 121 | Although you have complete control over the contents of your local |
| 122 | Fossil repository clone, you cannot perform Type 1 forgery on its |
| 123 | contents short of executing a [preimage attack][prei] on the hash |
| 124 | algorithm. ([SHA3-256][SHA-3] by default in the current version of |
| 125 | Fossil.) Even if you could, Fossil’s sync protocol will prevent the |
| 126 | modification from being pushed into another repository: the remote |
| 127 | Fossil instance says, “I’ve already got that one, thanks,” and |
| 128 | ignores the push. Thus, short of breaking into the remote server |
| 129 | and modifying the repository in place, you couldn’t even make use of |
| @@ -146,11 +146,11 @@ | |
| 146 | |
| 147 | If Fossil signatures prevent Type 1 and Type 2 frauds, you |
| 148 | may wonder why they are not enabled by default. It is because |
| 149 | they are defense-in-depth measures, not the minimum sufficient |
| 150 | measures needed to prevent repository fraud, unlike the equivalent |
| 151 | protections in a cryptocurrency blockchain. Fossil provides its |
| 152 | primary protections through other means, so it doesn’t need to |
| 153 | mandate signatures. |
| 154 | |
| 155 | Also, Fossil is not itself a [PKI], and there is no way for regular |
| 156 | users of Fossil to link it to a PKI, since doing so would likely |
| 157 |
+1
-1
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -316,11 +316,11 @@ | ||
| 316 | 316 | |
| 317 | 317 | <h2>6.0 Building on/for Android</h2> |
| 318 | 318 | |
| 319 | 319 | <h3>6.1 Cross-compiling from Linux</h3> |
| 320 | 320 | |
| 321 | -The following instructions for building Fossil for Andoid, | |
| 321 | +The following instructions for building Fossil for Android, | |
| 322 | 322 | without requiring a rooted OS, are adapted from |
| 323 | 323 | [https://fossil-scm.org/forum/forumpost/e0e9de4a7e | forumpost/e0e9de4a7e]. |
| 324 | 324 | |
| 325 | 325 | On the development machine, from the fossil source tree: |
| 326 | 326 | |
| 327 | 327 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -316,11 +316,11 @@ | |
| 316 | |
| 317 | <h2>6.0 Building on/for Android</h2> |
| 318 | |
| 319 | <h3>6.1 Cross-compiling from Linux</h3> |
| 320 | |
| 321 | The following instructions for building Fossil for Andoid, |
| 322 | without requiring a rooted OS, are adapted from |
| 323 | [https://fossil-scm.org/forum/forumpost/e0e9de4a7e | forumpost/e0e9de4a7e]. |
| 324 | |
| 325 | On the development machine, from the fossil source tree: |
| 326 | |
| 327 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -316,11 +316,11 @@ | |
| 316 | |
| 317 | <h2>6.0 Building on/for Android</h2> |
| 318 | |
| 319 | <h3>6.1 Cross-compiling from Linux</h3> |
| 320 | |
| 321 | The following instructions for building Fossil for Android, |
| 322 | without requiring a rooted OS, are adapted from |
| 323 | [https://fossil-scm.org/forum/forumpost/e0e9de4a7e | forumpost/e0e9de4a7e]. |
| 324 | |
| 325 | On the development machine, from the fossil source tree: |
| 326 | |
| 327 |
+1
-1
| --- www/caps/admin-v-setup.md | ||
| +++ www/caps/admin-v-setup.md | ||
| @@ -348,11 +348,11 @@ | ||
| 348 | 348 | SQL queries against the Fossil repository via Fossil UI. This not |
| 349 | 349 | only allows arbitrary ability to modify the repository hash tree |
| 350 | 350 | and its backing data tables, it can probably also be used to damage |
| 351 | 351 | the host such as via `PRAGMA temp_store = FILE`. |
| 352 | 352 | |
| 353 | -* **Tickets**: This section allows input of aribtrary TH1 code that | |
| 353 | +* **Tickets**: This section allows input of arbitrary TH1 code that | |
| 354 | 354 | runs on the server, affecting the way the Fossil ticketing system |
| 355 | 355 | works. The justification in the **TH1** section below therefore |
| 356 | 356 | applies. |
| 357 | 357 | |
| 358 | 358 | * **TH1**: The [TH1 language][th1] is quite restricted relative to the |
| 359 | 359 |
| --- www/caps/admin-v-setup.md | |
| +++ www/caps/admin-v-setup.md | |
| @@ -348,11 +348,11 @@ | |
| 348 | SQL queries against the Fossil repository via Fossil UI. This not |
| 349 | only allows arbitrary ability to modify the repository hash tree |
| 350 | and its backing data tables, it can probably also be used to damage |
| 351 | the host such as via `PRAGMA temp_store = FILE`. |
| 352 | |
| 353 | * **Tickets**: This section allows input of aribtrary TH1 code that |
| 354 | runs on the server, affecting the way the Fossil ticketing system |
| 355 | works. The justification in the **TH1** section below therefore |
| 356 | applies. |
| 357 | |
| 358 | * **TH1**: The [TH1 language][th1] is quite restricted relative to the |
| 359 |
| --- www/caps/admin-v-setup.md | |
| +++ www/caps/admin-v-setup.md | |
| @@ -348,11 +348,11 @@ | |
| 348 | SQL queries against the Fossil repository via Fossil UI. This not |
| 349 | only allows arbitrary ability to modify the repository hash tree |
| 350 | and its backing data tables, it can probably also be used to damage |
| 351 | the host such as via `PRAGMA temp_store = FILE`. |
| 352 | |
| 353 | * **Tickets**: This section allows input of arbitrary TH1 code that |
| 354 | runs on the server, affecting the way the Fossil ticketing system |
| 355 | works. The justification in the **TH1** section below therefore |
| 356 | applies. |
| 357 | |
| 358 | * **TH1**: The [TH1 language][th1] is quite restricted relative to the |
| 359 |
+3
-3
| --- www/changes.wiki | ||
| +++ www/changes.wiki | ||
| @@ -635,11 +635,11 @@ | ||
| 635 | 635 | <a name='v2_0'></a> |
| 636 | 636 | <h2>Changes for Version 2.0 (2017-03-03)</h2> |
| 637 | 637 | |
| 638 | 638 | * Use the |
| 639 | 639 | [https://github.com/cr-marcstevens/sha1collisiondetection|hardened SHA1] |
| 640 | - implemenation by Marc Stevens and Dan Shumow. | |
| 640 | + implementation by Marc Stevens and Dan Shumow. | |
| 641 | 641 | * Add the ability to read and understand |
| 642 | 642 | [./fileformat.wiki#names|artifact names] that are based on SHA3-256 |
| 643 | 643 | rather than SHA1, but do not actually generate any such names. |
| 644 | 644 | * Added the [/help?cmd=sha3sum|sha3sum] command. |
| 645 | 645 | * Update the built-in SQLite to version 3.17.0. |
| @@ -659,11 +659,11 @@ | ||
| 659 | 659 | with many new filter options so that specific kinds of changes can be |
| 660 | 660 | found without having to pipe through grep or sed. |
| 661 | 661 | * Enhanced the [/help/sqlite3|fossil sql] command so that it opens the |
| 662 | 662 | [./tech_overview.wiki#localdb|checkout database] and the |
| 663 | 663 | [./tech_overview.wiki#configdb|configuration database] in addition to the |
| 664 | - respository database. | |
| 664 | + repository database. | |
| 665 | 665 | * TH1 enhancements: |
| 666 | 666 | <ul><li>Add <nowiki>[unversioned content]</nowiki> command.</li> |
| 667 | 667 | <li>Add <nowiki>[unversioned list]</nowiki> command.</li> |
| 668 | 668 | <li>Add project_description variable.</li> |
| 669 | 669 | </ul> |
| @@ -752,11 +752,11 @@ | ||
| 752 | 752 | [/help?cmd=/tarball|/tarball] and [/help?cmd=/zip|/zip] web pages. |
| 753 | 753 | * Add support for [./encryptedrepos.wiki|encrypted Fossil repositories]. |
| 754 | 754 | * If the FOSSIL_PWREADER environment variable is set, then use the program it |
| 755 | 755 | names in place of getpass() to read passwords and passphrases |
| 756 | 756 | * Option --baseurl now works on Windows. |
| 757 | - * Numerious documentation improvements. | |
| 757 | + * Numerous documentation improvements. | |
| 758 | 758 | * Update the built-in SQLite to version 3.13.0. |
| 759 | 759 | |
| 760 | 760 | <a name='v1_34'></a> |
| 761 | 761 | <h2>Changes for Version 1.34 (2015-11-02)</h2> |
| 762 | 762 | |
| 763 | 763 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -635,11 +635,11 @@ | |
| 635 | <a name='v2_0'></a> |
| 636 | <h2>Changes for Version 2.0 (2017-03-03)</h2> |
| 637 | |
| 638 | * Use the |
| 639 | [https://github.com/cr-marcstevens/sha1collisiondetection|hardened SHA1] |
| 640 | implemenation by Marc Stevens and Dan Shumow. |
| 641 | * Add the ability to read and understand |
| 642 | [./fileformat.wiki#names|artifact names] that are based on SHA3-256 |
| 643 | rather than SHA1, but do not actually generate any such names. |
| 644 | * Added the [/help?cmd=sha3sum|sha3sum] command. |
| 645 | * Update the built-in SQLite to version 3.17.0. |
| @@ -659,11 +659,11 @@ | |
| 659 | with many new filter options so that specific kinds of changes can be |
| 660 | found without having to pipe through grep or sed. |
| 661 | * Enhanced the [/help/sqlite3|fossil sql] command so that it opens the |
| 662 | [./tech_overview.wiki#localdb|checkout database] and the |
| 663 | [./tech_overview.wiki#configdb|configuration database] in addition to the |
| 664 | respository database. |
| 665 | * TH1 enhancements: |
| 666 | <ul><li>Add <nowiki>[unversioned content]</nowiki> command.</li> |
| 667 | <li>Add <nowiki>[unversioned list]</nowiki> command.</li> |
| 668 | <li>Add project_description variable.</li> |
| 669 | </ul> |
| @@ -752,11 +752,11 @@ | |
| 752 | [/help?cmd=/tarball|/tarball] and [/help?cmd=/zip|/zip] web pages. |
| 753 | * Add support for [./encryptedrepos.wiki|encrypted Fossil repositories]. |
| 754 | * If the FOSSIL_PWREADER environment variable is set, then use the program it |
| 755 | names in place of getpass() to read passwords and passphrases |
| 756 | * Option --baseurl now works on Windows. |
| 757 | * Numerious documentation improvements. |
| 758 | * Update the built-in SQLite to version 3.13.0. |
| 759 | |
| 760 | <a name='v1_34'></a> |
| 761 | <h2>Changes for Version 1.34 (2015-11-02)</h2> |
| 762 | |
| 763 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -635,11 +635,11 @@ | |
| 635 | <a name='v2_0'></a> |
| 636 | <h2>Changes for Version 2.0 (2017-03-03)</h2> |
| 637 | |
| 638 | * Use the |
| 639 | [https://github.com/cr-marcstevens/sha1collisiondetection|hardened SHA1] |
| 640 | implementation by Marc Stevens and Dan Shumow. |
| 641 | * Add the ability to read and understand |
| 642 | [./fileformat.wiki#names|artifact names] that are based on SHA3-256 |
| 643 | rather than SHA1, but do not actually generate any such names. |
| 644 | * Added the [/help?cmd=sha3sum|sha3sum] command. |
| 645 | * Update the built-in SQLite to version 3.17.0. |
| @@ -659,11 +659,11 @@ | |
| 659 | with many new filter options so that specific kinds of changes can be |
| 660 | found without having to pipe through grep or sed. |
| 661 | * Enhanced the [/help/sqlite3|fossil sql] command so that it opens the |
| 662 | [./tech_overview.wiki#localdb|checkout database] and the |
| 663 | [./tech_overview.wiki#configdb|configuration database] in addition to the |
| 664 | repository database. |
| 665 | * TH1 enhancements: |
| 666 | <ul><li>Add <nowiki>[unversioned content]</nowiki> command.</li> |
| 667 | <li>Add <nowiki>[unversioned list]</nowiki> command.</li> |
| 668 | <li>Add project_description variable.</li> |
| 669 | </ul> |
| @@ -752,11 +752,11 @@ | |
| 752 | [/help?cmd=/tarball|/tarball] and [/help?cmd=/zip|/zip] web pages. |
| 753 | * Add support for [./encryptedrepos.wiki|encrypted Fossil repositories]. |
| 754 | * If the FOSSIL_PWREADER environment variable is set, then use the program it |
| 755 | names in place of getpass() to read passwords and passphrases |
| 756 | * Option --baseurl now works on Windows. |
| 757 | * Numerous documentation improvements. |
| 758 | * Update the built-in SQLite to version 3.13.0. |
| 759 | |
| 760 | <a name='v1_34'></a> |
| 761 | <h2>Changes for Version 1.34 (2015-11-02)</h2> |
| 762 | |
| 763 |
+1
-1
| --- www/css-tricks.md | ||
| +++ www/css-tricks.md | ||
| @@ -13,11 +13,11 @@ | ||
| 13 | 13 | of customizing certain CSS-based behaviors in a Fossil UI. That said... |
| 14 | 14 | |
| 15 | 15 | ## Is it Really `!important`? |
| 16 | 16 | |
| 17 | 17 | By and large, CSS's `!important` qualifier is not needed when |
| 18 | -customzing Fossil's CSS. On occasion, however, particular styles may | |
| 18 | +customizing Fossil's CSS. On occasion, however, particular styles may | |
| 19 | 19 | be set directly on DOM elements when Fossil generates its HTML, and |
| 20 | 20 | such cases require the use of `!important` to override them. |
| 21 | 21 | |
| 22 | 22 | |
| 23 | 23 | <!-- ============================================================ --> |
| 24 | 24 |
| --- www/css-tricks.md | |
| +++ www/css-tricks.md | |
| @@ -13,11 +13,11 @@ | |
| 13 | of customizing certain CSS-based behaviors in a Fossil UI. That said... |
| 14 | |
| 15 | ## Is it Really `!important`? |
| 16 | |
| 17 | By and large, CSS's `!important` qualifier is not needed when |
| 18 | customzing Fossil's CSS. On occasion, however, particular styles may |
| 19 | be set directly on DOM elements when Fossil generates its HTML, and |
| 20 | such cases require the use of `!important` to override them. |
| 21 | |
| 22 | |
| 23 | <!-- ============================================================ --> |
| 24 |
| --- www/css-tricks.md | |
| +++ www/css-tricks.md | |
| @@ -13,11 +13,11 @@ | |
| 13 | of customizing certain CSS-based behaviors in a Fossil UI. That said... |
| 14 | |
| 15 | ## Is it Really `!important`? |
| 16 | |
| 17 | By and large, CSS's `!important` qualifier is not needed when |
| 18 | customizing Fossil's CSS. On occasion, however, particular styles may |
| 19 | be set directly on DOM elements when Fossil generates its HTML, and |
| 20 | such cases require the use of `!important` to override them. |
| 21 | |
| 22 | |
| 23 | <!-- ============================================================ --> |
| 24 |
+2
-2
| --- www/customskin.md | ||
| +++ www/customskin.md | ||
| @@ -169,11 +169,11 @@ | ||
| 169 | 169 | |
| 170 | 170 | <blockquote><dl> |
| 171 | 171 | <dt><b>css.txt</b></dt><dd> |
| 172 | 172 | |
| 173 | 173 | <p>The css.txt file is the text of the CSS for Fossil. |
| 174 | -Fossil might add additional CSS elements after the | |
| 174 | +Fossil might add additional CSS elements after | |
| 175 | 175 | the css.txt file, if it sees that the css.txt omits some |
| 176 | 176 | CSS components that Fossil needs. But for the most part, |
| 177 | 177 | the content of the css.txt is the CSS for the page.</dd> |
| 178 | 178 | |
| 179 | 179 | <dt><b>details.txt</b><dt><dd> |
| @@ -263,11 +263,11 @@ | ||
| 263 | 263 | press "Reload" on your browser to see the effects. |
| 264 | 264 | |
| 265 | 265 | ## <a name="headfoot"></a>Header and Footer Processing |
| 266 | 266 | |
| 267 | 267 | The `header.txt` and `footer.txt` control files of a skin are the HTML text |
| 268 | -of the Contnet Header and Content Footer, except that before being inserted | |
| 268 | +of the Content Header and Content Footer, except that before being inserted | |
| 269 | 269 | into the output stream, the text is run through a |
| 270 | 270 | [TH1 interpreter](./th1.md) that might adjust the text as follows: |
| 271 | 271 | |
| 272 | 272 | * All text within <th1>...</th1> is omitted from the |
| 273 | 273 | output and is instead run as a TH1 script. That TH1 |
| 274 | 274 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -169,11 +169,11 @@ | |
| 169 | |
| 170 | <blockquote><dl> |
| 171 | <dt><b>css.txt</b></dt><dd> |
| 172 | |
| 173 | <p>The css.txt file is the text of the CSS for Fossil. |
| 174 | Fossil might add additional CSS elements after the |
| 175 | the css.txt file, if it sees that the css.txt omits some |
| 176 | CSS components that Fossil needs. But for the most part, |
| 177 | the content of the css.txt is the CSS for the page.</dd> |
| 178 | |
| 179 | <dt><b>details.txt</b><dt><dd> |
| @@ -263,11 +263,11 @@ | |
| 263 | press "Reload" on your browser to see the effects. |
| 264 | |
| 265 | ## <a name="headfoot"></a>Header and Footer Processing |
| 266 | |
| 267 | The `header.txt` and `footer.txt` control files of a skin are the HTML text |
| 268 | of the Contnet Header and Content Footer, except that before being inserted |
| 269 | into the output stream, the text is run through a |
| 270 | [TH1 interpreter](./th1.md) that might adjust the text as follows: |
| 271 | |
| 272 | * All text within <th1>...</th1> is omitted from the |
| 273 | output and is instead run as a TH1 script. That TH1 |
| 274 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -169,11 +169,11 @@ | |
| 169 | |
| 170 | <blockquote><dl> |
| 171 | <dt><b>css.txt</b></dt><dd> |
| 172 | |
| 173 | <p>The css.txt file is the text of the CSS for Fossil. |
| 174 | Fossil might add additional CSS elements after |
| 175 | the css.txt file, if it sees that the css.txt omits some |
| 176 | CSS components that Fossil needs. But for the most part, |
| 177 | the content of the css.txt is the CSS for the page.</dd> |
| 178 | |
| 179 | <dt><b>details.txt</b><dt><dd> |
| @@ -263,11 +263,11 @@ | |
| 263 | press "Reload" on your browser to see the effects. |
| 264 | |
| 265 | ## <a name="headfoot"></a>Header and Footer Processing |
| 266 | |
| 267 | The `header.txt` and `footer.txt` control files of a skin are the HTML text |
| 268 | of the Content Header and Content Footer, except that before being inserted |
| 269 | into the output stream, the text is run through a |
| 270 | [TH1 interpreter](./th1.md) that might adjust the text as follows: |
| 271 | |
| 272 | * All text within <th1>...</th1> is omitted from the |
| 273 | output and is instead run as a TH1 script. That TH1 |
| 274 |
+3
-3
| --- www/defcsp.md | ||
| +++ www/defcsp.md | ||
| @@ -102,11 +102,11 @@ | ||
| 102 | 102 | |
| 103 | 103 | As the "`unsafe-`" prefix on the name implies, the `'unsafe-inline'` |
| 104 | 104 | feature is suboptimal for security. However, there are |
| 105 | 105 | a few places in the Fossil-generated HTML that benefit from this |
| 106 | 106 | flexibility and the work-arounds are verbose and difficult to maintain. |
| 107 | -Futhermore, the harm that can be done with style injections is far | |
| 107 | +Furthermore, the harm that can be done with style injections is far | |
| 108 | 108 | less than the harm possible with injected javascript. And so the |
| 109 | 109 | `'unsafe-inline'` compromise is accepted for now, though it might |
| 110 | 110 | go away in some future release of Fossil. |
| 111 | 111 | |
| 112 | 112 | ### <a name="script"></a> script-src 'self' 'nonce-%s' |
| @@ -173,11 +173,11 @@ | ||
| 173 | 173 | content: |
| 174 | 174 | |
| 175 | 175 | <script src="/doc/trunk/bad.js"></script> |
| 176 | 176 | |
| 177 | 177 | That script can then do anything allowed in JavaScript to *any other* |
| 178 | -Chisel repository your browser can access.The possibilities for mischief | |
| 178 | +Chisel repository your browser can access. The possibilities for mischief | |
| 179 | 179 | are *vast*. For just one example, if you have login cookies on four |
| 180 | 180 | different Chisel repositories, your attacker could harvest the login |
| 181 | 181 | cookies for all of them through this path if we allowed Fossil to serve |
| 182 | 182 | JavaScript files under the same CSP policy as we do for CSS files. |
| 183 | 183 | |
| @@ -240,11 +240,11 @@ | ||
| 240 | 240 | to serve such content via `/ext` URLs. |
| 241 | 241 | |
| 242 | 242 | 5. Put Fossil behind a [front-end proxy server][svr] as a virtual |
| 243 | 243 | subdirectory within the site, so that our default CSP’s “self” rules |
| 244 | 244 | match static file routes on that same site. For instance, your repo |
| 245 | - might be at `https://example.com/code`, allowing documentes in that | |
| 245 | + might be at `https://example.com/code`, allowing documents in that | |
| 246 | 246 | repo to refer to: |
| 247 | 247 | |
| 248 | 248 | * images as `/image/foo.png` |
| 249 | 249 | * JavaScript files as `/js/bar.js` |
| 250 | 250 | * CSS style sheets as `/style/qux.css` |
| 251 | 251 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -102,11 +102,11 @@ | |
| 102 | |
| 103 | As the "`unsafe-`" prefix on the name implies, the `'unsafe-inline'` |
| 104 | feature is suboptimal for security. However, there are |
| 105 | a few places in the Fossil-generated HTML that benefit from this |
| 106 | flexibility and the work-arounds are verbose and difficult to maintain. |
| 107 | Futhermore, the harm that can be done with style injections is far |
| 108 | less than the harm possible with injected javascript. And so the |
| 109 | `'unsafe-inline'` compromise is accepted for now, though it might |
| 110 | go away in some future release of Fossil. |
| 111 | |
| 112 | ### <a name="script"></a> script-src 'self' 'nonce-%s' |
| @@ -173,11 +173,11 @@ | |
| 173 | content: |
| 174 | |
| 175 | <script src="/doc/trunk/bad.js"></script> |
| 176 | |
| 177 | That script can then do anything allowed in JavaScript to *any other* |
| 178 | Chisel repository your browser can access.The possibilities for mischief |
| 179 | are *vast*. For just one example, if you have login cookies on four |
| 180 | different Chisel repositories, your attacker could harvest the login |
| 181 | cookies for all of them through this path if we allowed Fossil to serve |
| 182 | JavaScript files under the same CSP policy as we do for CSS files. |
| 183 | |
| @@ -240,11 +240,11 @@ | |
| 240 | to serve such content via `/ext` URLs. |
| 241 | |
| 242 | 5. Put Fossil behind a [front-end proxy server][svr] as a virtual |
| 243 | subdirectory within the site, so that our default CSP’s “self” rules |
| 244 | match static file routes on that same site. For instance, your repo |
| 245 | might be at `https://example.com/code`, allowing documentes in that |
| 246 | repo to refer to: |
| 247 | |
| 248 | * images as `/image/foo.png` |
| 249 | * JavaScript files as `/js/bar.js` |
| 250 | * CSS style sheets as `/style/qux.css` |
| 251 |
| --- www/defcsp.md | |
| +++ www/defcsp.md | |
| @@ -102,11 +102,11 @@ | |
| 102 | |
| 103 | As the "`unsafe-`" prefix on the name implies, the `'unsafe-inline'` |
| 104 | feature is suboptimal for security. However, there are |
| 105 | a few places in the Fossil-generated HTML that benefit from this |
| 106 | flexibility and the work-arounds are verbose and difficult to maintain. |
| 107 | Furthermore, the harm that can be done with style injections is far |
| 108 | less than the harm possible with injected javascript. And so the |
| 109 | `'unsafe-inline'` compromise is accepted for now, though it might |
| 110 | go away in some future release of Fossil. |
| 111 | |
| 112 | ### <a name="script"></a> script-src 'self' 'nonce-%s' |
| @@ -173,11 +173,11 @@ | |
| 173 | content: |
| 174 | |
| 175 | <script src="/doc/trunk/bad.js"></script> |
| 176 | |
| 177 | That script can then do anything allowed in JavaScript to *any other* |
| 178 | Chisel repository your browser can access. The possibilities for mischief |
| 179 | are *vast*. For just one example, if you have login cookies on four |
| 180 | different Chisel repositories, your attacker could harvest the login |
| 181 | cookies for all of them through this path if we allowed Fossil to serve |
| 182 | JavaScript files under the same CSP policy as we do for CSS files. |
| 183 | |
| @@ -240,11 +240,11 @@ | |
| 240 | to serve such content via `/ext` URLs. |
| 241 | |
| 242 | 5. Put Fossil behind a [front-end proxy server][svr] as a virtual |
| 243 | subdirectory within the site, so that our default CSP’s “self” rules |
| 244 | match static file routes on that same site. For instance, your repo |
| 245 | might be at `https://example.com/code`, allowing documents in that |
| 246 | repo to refer to: |
| 247 | |
| 248 | * images as `/image/foo.png` |
| 249 | * JavaScript files as `/js/bar.js` |
| 250 | * CSS style sheets as `/style/qux.css` |
| 251 |
+2
-2
| --- www/env-opts.md | ||
| +++ www/env-opts.md | ||
| @@ -113,11 +113,11 @@ | ||
| 113 | 113 | |
| 114 | 114 | Environment Variables |
| 115 | 115 | --------------------- |
| 116 | 116 | |
| 117 | 117 | The location of the user's account-wide [configuration database][configdb] |
| 118 | -depends on the operating system and on the existance of various | |
| 118 | +depends on the operating system and on the existence of various | |
| 119 | 119 | environment variables and/or files. See the discussion of the |
| 120 | 120 | [configuration database location algorithm][configloc] for details. |
| 121 | 121 | |
| 122 | 122 | `EDITOR`: Name the editor to use for check-in and stash comments. |
| 123 | 123 | Overridden by the local or global `editor` setting or the `VISUAL` |
| @@ -393,11 +393,11 @@ | ||
| 393 | 393 | [configuration database file][configdb]. |
| 394 | 394 | The configuration database file includes the global settings |
| 395 | 395 | and the list of repositories and checkouts used by `fossil all`. |
| 396 | 396 | |
| 397 | 397 | The location of the configuration database file depends on the |
| 398 | -operating system and on the existance of various environment | |
| 398 | +operating system and on the existence of various environment | |
| 399 | 399 | variables and/or files. In brief, the configuration database is |
| 400 | 400 | usually: |
| 401 | 401 | |
| 402 | 402 | * Traditional unix → "`$HOME/.fossil`" |
| 403 | 403 | * Windows → "`%LOCALAPPDATA%/_fossil`" |
| 404 | 404 |
| --- www/env-opts.md | |
| +++ www/env-opts.md | |
| @@ -113,11 +113,11 @@ | |
| 113 | |
| 114 | Environment Variables |
| 115 | --------------------- |
| 116 | |
| 117 | The location of the user's account-wide [configuration database][configdb] |
| 118 | depends on the operating system and on the existance of various |
| 119 | environment variables and/or files. See the discussion of the |
| 120 | [configuration database location algorithm][configloc] for details. |
| 121 | |
| 122 | `EDITOR`: Name the editor to use for check-in and stash comments. |
| 123 | Overridden by the local or global `editor` setting or the `VISUAL` |
| @@ -393,11 +393,11 @@ | |
| 393 | [configuration database file][configdb]. |
| 394 | The configuration database file includes the global settings |
| 395 | and the list of repositories and checkouts used by `fossil all`. |
| 396 | |
| 397 | The location of the configuration database file depends on the |
| 398 | operating system and on the existance of various environment |
| 399 | variables and/or files. In brief, the configuration database is |
| 400 | usually: |
| 401 | |
| 402 | * Traditional unix → "`$HOME/.fossil`" |
| 403 | * Windows → "`%LOCALAPPDATA%/_fossil`" |
| 404 |
| --- www/env-opts.md | |
| +++ www/env-opts.md | |
| @@ -113,11 +113,11 @@ | |
| 113 | |
| 114 | Environment Variables |
| 115 | --------------------- |
| 116 | |
| 117 | The location of the user's account-wide [configuration database][configdb] |
| 118 | depends on the operating system and on the existence of various |
| 119 | environment variables and/or files. See the discussion of the |
| 120 | [configuration database location algorithm][configloc] for details. |
| 121 | |
| 122 | `EDITOR`: Name the editor to use for check-in and stash comments. |
| 123 | Overridden by the local or global `editor` setting or the `VISUAL` |
| @@ -393,11 +393,11 @@ | |
| 393 | [configuration database file][configdb]. |
| 394 | The configuration database file includes the global settings |
| 395 | and the list of repositories and checkouts used by `fossil all`. |
| 396 | |
| 397 | The location of the configuration database file depends on the |
| 398 | operating system and on the existence of various environment |
| 399 | variables and/or files. In brief, the configuration database is |
| 400 | usually: |
| 401 | |
| 402 | * Traditional unix → "`$HOME/.fossil`" |
| 403 | * Windows → "`%LOCALAPPDATA%/_fossil`" |
| 404 |
+1
-1
| --- www/fileedit-page.md | ||
| +++ www/fileedit-page.md | ||
| @@ -137,11 +137,11 @@ | ||
| 137 | 137 | Exactly how long `localStorage` will survive, and how much it or |
| 138 | 138 | `sessionStorage` can hold, is environment-dependent. `sessionStorage` |
| 139 | 139 | will survive until the current browser tab is closed, but it survives |
| 140 | 140 | across reloads of the same tab. |
| 141 | 141 | |
| 142 | -If `/filepage` determines that no peristent storage is available a | |
| 142 | +If `/filepage` determines that no persistent storage is available a | |
| 143 | 143 | warning is displayed on the editor page. |
| 144 | 144 | |
| 145 | 145 | [html5storage]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API |
| 146 | 146 | |
| 147 | 147 | ## <a id="power"></a> The Power is Yours, but... |
| 148 | 148 |
| --- www/fileedit-page.md | |
| +++ www/fileedit-page.md | |
| @@ -137,11 +137,11 @@ | |
| 137 | Exactly how long `localStorage` will survive, and how much it or |
| 138 | `sessionStorage` can hold, is environment-dependent. `sessionStorage` |
| 139 | will survive until the current browser tab is closed, but it survives |
| 140 | across reloads of the same tab. |
| 141 | |
| 142 | If `/filepage` determines that no peristent storage is available a |
| 143 | warning is displayed on the editor page. |
| 144 | |
| 145 | [html5storage]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API |
| 146 | |
| 147 | ## <a id="power"></a> The Power is Yours, but... |
| 148 |
| --- www/fileedit-page.md | |
| +++ www/fileedit-page.md | |
| @@ -137,11 +137,11 @@ | |
| 137 | Exactly how long `localStorage` will survive, and how much it or |
| 138 | `sessionStorage` can hold, is environment-dependent. `sessionStorage` |
| 139 | will survive until the current browser tab is closed, but it survives |
| 140 | across reloads of the same tab. |
| 141 | |
| 142 | If `/filepage` determines that no persistent storage is available a |
| 143 | warning is displayed on the editor page. |
| 144 | |
| 145 | [html5storage]: https://developer.mozilla.org/en-US/docs/Web/API/Web_Storage_API |
| 146 | |
| 147 | ## <a id="power"></a> The Power is Yours, but... |
| 148 |
+1
-1
| --- www/gitusers.md | ||
| +++ www/gitusers.md | ||
| @@ -847,11 +847,11 @@ | ||
| 847 | 847 | |
| 848 | 848 | 2. A date string in Git without a time will be interpreted as |
| 849 | 849 | “[at the local wall clock time on the given date][gapxd],” so the |
| 850 | 850 | command means something different from one second to the next. This |
| 851 | 851 | can be a problem if there are multiple commits on that date, because |
| 852 | - the command will give diffferent results depending on the time of | |
| 852 | + the command will give different results depending on the time of | |
| 853 | 853 | day you run it. |
| 854 | 854 | |
| 855 | 855 | 3. It gives misleading output if there is no close match for the date |
| 856 | 856 | in the local [reflog]. It starts out empty after a fresh clone, and |
| 857 | 857 | while it does build up as you use that clone, Git [automatically |
| 858 | 858 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -847,11 +847,11 @@ | |
| 847 | |
| 848 | 2. A date string in Git without a time will be interpreted as |
| 849 | “[at the local wall clock time on the given date][gapxd],” so the |
| 850 | command means something different from one second to the next. This |
| 851 | can be a problem if there are multiple commits on that date, because |
| 852 | the command will give diffferent results depending on the time of |
| 853 | day you run it. |
| 854 | |
| 855 | 3. It gives misleading output if there is no close match for the date |
| 856 | in the local [reflog]. It starts out empty after a fresh clone, and |
| 857 | while it does build up as you use that clone, Git [automatically |
| 858 |
| --- www/gitusers.md | |
| +++ www/gitusers.md | |
| @@ -847,11 +847,11 @@ | |
| 847 | |
| 848 | 2. A date string in Git without a time will be interpreted as |
| 849 | “[at the local wall clock time on the given date][gapxd],” so the |
| 850 | command means something different from one second to the next. This |
| 851 | can be a problem if there are multiple commits on that date, because |
| 852 | the command will give different results depending on the time of |
| 853 | day you run it. |
| 854 | |
| 855 | 3. It gives misleading output if there is no close match for the date |
| 856 | in the local [reflog]. It starts out empty after a fresh clone, and |
| 857 | while it does build up as you use that clone, Git [automatically |
| 858 |
+2
-2
| --- www/globs.md | ||
| +++ www/globs.md | ||
| @@ -60,11 +60,11 @@ | ||
| 60 | 60 | Fossil file names are stored as complete path names. The distinction |
| 61 | 61 | between file name and directory name is “below” Fossil in this sense. |
| 62 | 62 | |
| 63 | 63 | [pg]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13 |
| 64 | 64 | |
| 65 | -The bracket expresssions above require some additional explanation: | |
| 65 | +The bracket expressions above require some additional explanation: | |
| 66 | 66 | |
| 67 | 67 | * A range of characters may be specified with `-`, so `[a-f]` matches |
| 68 | 68 | exactly the same characters as `[abcdef]`. Ranges reflect Unicode |
| 69 | 69 | code points without any locale-specific collation sequence. |
| 70 | 70 | Therefore, this particular sequence never matches the Unicode |
| @@ -484,11 +484,11 @@ | ||
| 484 | 484 | ## Experimenting |
| 485 | 485 | |
| 486 | 486 | To preview the effects of command line glob pattern expansion for |
| 487 | 487 | various glob patterns (unquoted, quoted, comma-terminated), for any |
| 488 | 488 | combination of command shell, OS, C run time, and Fossil version, |
| 489 | -preceed the command you want to test with [`test-echo`][] like so: | |
| 489 | +precede the command you want to test with [`test-echo`][] like so: | |
| 490 | 490 | |
| 491 | 491 | $ fossil test-echo setting crlf-glob "*" |
| 492 | 492 | C:\> echo * | fossil test-echo setting crlf-glob --args - |
| 493 | 493 | |
| 494 | 494 | The [`test-glob`][] command is also handy to test if a string |
| 495 | 495 |
| --- www/globs.md | |
| +++ www/globs.md | |
| @@ -60,11 +60,11 @@ | |
| 60 | Fossil file names are stored as complete path names. The distinction |
| 61 | between file name and directory name is “below” Fossil in this sense. |
| 62 | |
| 63 | [pg]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13 |
| 64 | |
| 65 | The bracket expresssions above require some additional explanation: |
| 66 | |
| 67 | * A range of characters may be specified with `-`, so `[a-f]` matches |
| 68 | exactly the same characters as `[abcdef]`. Ranges reflect Unicode |
| 69 | code points without any locale-specific collation sequence. |
| 70 | Therefore, this particular sequence never matches the Unicode |
| @@ -484,11 +484,11 @@ | |
| 484 | ## Experimenting |
| 485 | |
| 486 | To preview the effects of command line glob pattern expansion for |
| 487 | various glob patterns (unquoted, quoted, comma-terminated), for any |
| 488 | combination of command shell, OS, C run time, and Fossil version, |
| 489 | preceed the command you want to test with [`test-echo`][] like so: |
| 490 | |
| 491 | $ fossil test-echo setting crlf-glob "*" |
| 492 | C:\> echo * | fossil test-echo setting crlf-glob --args - |
| 493 | |
| 494 | The [`test-glob`][] command is also handy to test if a string |
| 495 |
| --- www/globs.md | |
| +++ www/globs.md | |
| @@ -60,11 +60,11 @@ | |
| 60 | Fossil file names are stored as complete path names. The distinction |
| 61 | between file name and directory name is “below” Fossil in this sense. |
| 62 | |
| 63 | [pg]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_13 |
| 64 | |
| 65 | The bracket expressions above require some additional explanation: |
| 66 | |
| 67 | * A range of characters may be specified with `-`, so `[a-f]` matches |
| 68 | exactly the same characters as `[abcdef]`. Ranges reflect Unicode |
| 69 | code points without any locale-specific collation sequence. |
| 70 | Therefore, this particular sequence never matches the Unicode |
| @@ -484,11 +484,11 @@ | |
| 484 | ## Experimenting |
| 485 | |
| 486 | To preview the effects of command line glob pattern expansion for |
| 487 | various glob patterns (unquoted, quoted, comma-terminated), for any |
| 488 | combination of command shell, OS, C run time, and Fossil version, |
| 489 | precede the command you want to test with [`test-echo`][] like so: |
| 490 | |
| 491 | $ fossil test-echo setting crlf-glob "*" |
| 492 | C:\> echo * | fossil test-echo setting crlf-glob --args - |
| 493 | |
| 494 | The [`test-glob`][] command is also handy to test if a string |
| 495 |
+2
-2
| --- www/history.md | ||
| +++ www/history.md | ||
| @@ -61,11 +61,11 @@ | ||
| 61 | 61 | |
| 62 | 62 | [335]: https://www.monotone.ca/ |
| 63 | 63 | |
| 64 | 64 | Beginning around 2005, the need for a better version control system |
| 65 | 65 | for SQLite began to become evident. The SQLite architect looked |
| 66 | -around for a suitable replacement. Monotone, Git, and Mercurical were | |
| 66 | +around for a suitable replacement. Monotone, Git, and Mercurial were | |
| 67 | 67 | all considered. But at that time, none of these supported sync |
| 68 | 68 | over ordinary HTTP, none could be run from an inexpensive shell |
| 69 | 69 | account on a leased server (this was before the widespread availability |
| 70 | 70 | of affordable virtual machines), and none of them supported anything |
| 71 | 71 | resembling the wiki and ticket features of CVSTrac that had been |
| @@ -85,11 +85,11 @@ | ||
| 85 | 85 | The first project hosted by Fossil was Fossil itself. After a |
| 86 | 86 | few months of development work, the code was considered stable enough |
| 87 | 87 | to begin hosting the [SQLite documentation repository][350] which was |
| 88 | 88 | split off from the main SQLite CVS repository on [2007-11-12][355]. |
| 89 | 89 | After two years of development work on Fossil, the |
| 90 | -SQLite source code itself was transfered to Fossil on | |
| 90 | +SQLite source code itself was transferred to Fossil on | |
| 91 | 91 | [2009-08-11][360]. |
| 92 | 92 | |
| 93 | 93 | [350]: https://www.sqlite.org/docsrc/doc/trunk/README.md |
| 94 | 94 | [355]: https://www.sqlite.org/docsrc/timeline?c=200711120345&n1=10 |
| 95 | 95 | [360]: https://sqlite.org/src/timeline?c=b0848925babde524&n1=12&y=ci |
| 96 | 96 |
| --- www/history.md | |
| +++ www/history.md | |
| @@ -61,11 +61,11 @@ | |
| 61 | |
| 62 | [335]: https://www.monotone.ca/ |
| 63 | |
| 64 | Beginning around 2005, the need for a better version control system |
| 65 | for SQLite began to become evident. The SQLite architect looked |
| 66 | around for a suitable replacement. Monotone, Git, and Mercurical were |
| 67 | all considered. But at that time, none of these supported sync |
| 68 | over ordinary HTTP, none could be run from an inexpensive shell |
| 69 | account on a leased server (this was before the widespread availability |
| 70 | of affordable virtual machines), and none of them supported anything |
| 71 | resembling the wiki and ticket features of CVSTrac that had been |
| @@ -85,11 +85,11 @@ | |
| 85 | The first project hosted by Fossil was Fossil itself. After a |
| 86 | few months of development work, the code was considered stable enough |
| 87 | to begin hosting the [SQLite documentation repository][350] which was |
| 88 | split off from the main SQLite CVS repository on [2007-11-12][355]. |
| 89 | After two years of development work on Fossil, the |
| 90 | SQLite source code itself was transfered to Fossil on |
| 91 | [2009-08-11][360]. |
| 92 | |
| 93 | [350]: https://www.sqlite.org/docsrc/doc/trunk/README.md |
| 94 | [355]: https://www.sqlite.org/docsrc/timeline?c=200711120345&n1=10 |
| 95 | [360]: https://sqlite.org/src/timeline?c=b0848925babde524&n1=12&y=ci |
| 96 |
| --- www/history.md | |
| +++ www/history.md | |
| @@ -61,11 +61,11 @@ | |
| 61 | |
| 62 | [335]: https://www.monotone.ca/ |
| 63 | |
| 64 | Beginning around 2005, the need for a better version control system |
| 65 | for SQLite began to become evident. The SQLite architect looked |
| 66 | around for a suitable replacement. Monotone, Git, and Mercurial were |
| 67 | all considered. But at that time, none of these supported sync |
| 68 | over ordinary HTTP, none could be run from an inexpensive shell |
| 69 | account on a leased server (this was before the widespread availability |
| 70 | of affordable virtual machines), and none of them supported anything |
| 71 | resembling the wiki and ticket features of CVSTrac that had been |
| @@ -85,11 +85,11 @@ | |
| 85 | The first project hosted by Fossil was Fossil itself. After a |
| 86 | few months of development work, the code was considered stable enough |
| 87 | to begin hosting the [SQLite documentation repository][350] which was |
| 88 | split off from the main SQLite CVS repository on [2007-11-12][355]. |
| 89 | After two years of development work on Fossil, the |
| 90 | SQLite source code itself was transferred to Fossil on |
| 91 | [2009-08-11][360]. |
| 92 | |
| 93 | [350]: https://www.sqlite.org/docsrc/doc/trunk/README.md |
| 94 | [355]: https://www.sqlite.org/docsrc/timeline?c=200711120345&n1=10 |
| 95 | [360]: https://sqlite.org/src/timeline?c=b0848925babde524&n1=12&y=ci |
| 96 |
+1
-1
| --- www/hooks.md | ||
| +++ www/hooks.md | ||
| @@ -91,11 +91,11 @@ | ||
| 91 | 91 | and the transaction commits before it tries to access the repository |
| 92 | 92 | database. |
| 93 | 93 | |
| 94 | 94 | * A push might not deliver all of the artifacts for a checkin. If |
| 95 | 95 | Fossil knows that a /xfer HTTP request is incomplete, it will defer |
| 96 | - running the after-receive push for 60 seconds, or unti a complete | |
| 96 | + running the after-receive push for 60 seconds, or until a complete | |
| 97 | 97 | /xfer request is received. This helps to prevent after-receive hooks |
| 98 | 98 | from running when incomplete checkins exist in the repository, but |
| 99 | 99 | it does not provide hard guarantees, as there is no way to do that |
| 100 | 100 | in a distributed system. |
| 101 | 101 | |
| 102 | 102 |
| --- www/hooks.md | |
| +++ www/hooks.md | |
| @@ -91,11 +91,11 @@ | |
| 91 | and the transaction commits before it tries to access the repository |
| 92 | database. |
| 93 | |
| 94 | * A push might not deliver all of the artifacts for a checkin. If |
| 95 | Fossil knows that a /xfer HTTP request is incomplete, it will defer |
| 96 | running the after-receive push for 60 seconds, or unti a complete |
| 97 | /xfer request is received. This helps to prevent after-receive hooks |
| 98 | from running when incomplete checkins exist in the repository, but |
| 99 | it does not provide hard guarantees, as there is no way to do that |
| 100 | in a distributed system. |
| 101 | |
| 102 |
| --- www/hooks.md | |
| +++ www/hooks.md | |
| @@ -91,11 +91,11 @@ | |
| 91 | and the transaction commits before it tries to access the repository |
| 92 | database. |
| 93 | |
| 94 | * A push might not deliver all of the artifacts for a checkin. If |
| 95 | Fossil knows that a /xfer HTTP request is incomplete, it will defer |
| 96 | running the after-receive push for 60 seconds, or until a complete |
| 97 | /xfer request is received. This helps to prevent after-receive hooks |
| 98 | from running when incomplete checkins exist in the repository, but |
| 99 | it does not provide hard guarantees, as there is no way to do that |
| 100 | in a distributed system. |
| 101 | |
| 102 |
+1
-1
| --- www/image-format-vs-repo-size.md | ||
| +++ www/image-format-vs-repo-size.md | ||
| @@ -140,11 +140,11 @@ | ||
| 140 | 140 | virtually no penalty to using BMP or TIFF over PNG. The file sizes |
| 141 | 141 | likely differ only because of differences in zlib settings between |
| 142 | 142 | the cases. |
| 143 | 143 | |
| 144 | 144 | * Because JPEG’s lossy nature allows it to start smaller and have |
| 145 | - smaller size increases than than PNG, the crossover point with | |
| 145 | + smaller size increases than PNG, the crossover point with | |
| 146 | 146 | BMP/TIFF isn’t until 7-9 checkins in typical runs of this [Monte |
| 147 | 147 | Carlo experiment][mce]. Given a choice among these four file |
| 148 | 148 | formats and a willingness to use lossy image compression, a rational |
| 149 | 149 | tradeoff is to choose JPEG for repositories where each image will |
| 150 | 150 | change fewer than that number of times. |
| 151 | 151 |
| --- www/image-format-vs-repo-size.md | |
| +++ www/image-format-vs-repo-size.md | |
| @@ -140,11 +140,11 @@ | |
| 140 | virtually no penalty to using BMP or TIFF over PNG. The file sizes |
| 141 | likely differ only because of differences in zlib settings between |
| 142 | the cases. |
| 143 | |
| 144 | * Because JPEG’s lossy nature allows it to start smaller and have |
| 145 | smaller size increases than than PNG, the crossover point with |
| 146 | BMP/TIFF isn’t until 7-9 checkins in typical runs of this [Monte |
| 147 | Carlo experiment][mce]. Given a choice among these four file |
| 148 | formats and a willingness to use lossy image compression, a rational |
| 149 | tradeoff is to choose JPEG for repositories where each image will |
| 150 | change fewer than that number of times. |
| 151 |
| --- www/image-format-vs-repo-size.md | |
| +++ www/image-format-vs-repo-size.md | |
| @@ -140,11 +140,11 @@ | |
| 140 | virtually no penalty to using BMP or TIFF over PNG. The file sizes |
| 141 | likely differ only because of differences in zlib settings between |
| 142 | the cases. |
| 143 | |
| 144 | * Because JPEG’s lossy nature allows it to start smaller and have |
| 145 | smaller size increases than PNG, the crossover point with |
| 146 | BMP/TIFF isn’t until 7-9 checkins in typical runs of this [Monte |
| 147 | Carlo experiment][mce]. Given a choice among these four file |
| 148 | formats and a willingness to use lossy image compression, a rational |
| 149 | tradeoff is to choose JPEG for repositories where each image will |
| 150 | change fewer than that number of times. |
| 151 |
+1
-1
| --- www/makefile.wiki | ||
| +++ www/makefile.wiki | ||
| @@ -158,11 +158,11 @@ | ||
| 158 | 158 | VERSION files |
| 159 | 159 | in the root of the source tree are the three arguments and |
| 160 | 160 | the generated VERSION.h file appears on standard output. |
| 161 | 161 | |
| 162 | 162 | The builtin_data.h header file is generated by a C program: src/mkbuiltin.c. |
| 163 | -The builtin_data.h file contains C-langauge byte-array definitions for | |
| 163 | +The builtin_data.h file contains C-language byte-array definitions for | |
| 164 | 164 | the content of resource files used by Fossil. To generate the |
| 165 | 165 | builtin_data.h file, first compile the mkbuiltin.c program, then run: |
| 166 | 166 | |
| 167 | 167 | <blockquote><pre> |
| 168 | 168 | mkbuiltin.exe diff.tcl <i>OtherFiles...</i> >builtin_data.h |
| 169 | 169 |
| --- www/makefile.wiki | |
| +++ www/makefile.wiki | |
| @@ -158,11 +158,11 @@ | |
| 158 | VERSION files |
| 159 | in the root of the source tree are the three arguments and |
| 160 | the generated VERSION.h file appears on standard output. |
| 161 | |
| 162 | The builtin_data.h header file is generated by a C program: src/mkbuiltin.c. |
| 163 | The builtin_data.h file contains C-langauge byte-array definitions for |
| 164 | the content of resource files used by Fossil. To generate the |
| 165 | builtin_data.h file, first compile the mkbuiltin.c program, then run: |
| 166 | |
| 167 | <blockquote><pre> |
| 168 | mkbuiltin.exe diff.tcl <i>OtherFiles...</i> >builtin_data.h |
| 169 |
| --- www/makefile.wiki | |
| +++ www/makefile.wiki | |
| @@ -158,11 +158,11 @@ | |
| 158 | VERSION files |
| 159 | in the root of the source tree are the three arguments and |
| 160 | the generated VERSION.h file appears on standard output. |
| 161 | |
| 162 | The builtin_data.h header file is generated by a C program: src/mkbuiltin.c. |
| 163 | The builtin_data.h file contains C-language byte-array definitions for |
| 164 | the content of resource files used by Fossil. To generate the |
| 165 | builtin_data.h file, first compile the mkbuiltin.c program, then run: |
| 166 | |
| 167 | <blockquote><pre> |
| 168 | mkbuiltin.exe diff.tcl <i>OtherFiles...</i> >builtin_data.h |
| 169 |
+4
-4
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -176,11 +176,11 @@ | ||
| 176 | 176 | <b>[/help/timeline | fossil timeline]</b><br> |
| 177 | 177 | <b>[/help/ls | fossil ls]</b><br> |
| 178 | 178 | <b>[/help/branch | fossil branch]</b><br> |
| 179 | 179 | </blockquote> |
| 180 | 180 | |
| 181 | -<p>If you created a new respository using "fossil init" some commands will not | |
| 181 | +<p>If you created a new repository using "fossil init" some commands will not | |
| 182 | 182 | produce much output.</p> |
| 183 | 183 | |
| 184 | 184 | <p>Note that Fossil allows you to make multiple check-outs in |
| 185 | 185 | separate directories from the same repository. This enables you, |
| 186 | 186 | for example, to do builds from multiple branches or versions at |
| @@ -198,11 +198,11 @@ | ||
| 198 | 198 | does a "soft" switch, merging any local changes into the target |
| 199 | 199 | version, whereas [/help/checkout | checkout] does not |
| 200 | 200 | automatically sync and does a "hard" switch, overwriting local |
| 201 | 201 | changes if told to do so.</p> |
| 202 | 202 | |
| 203 | -<h2 id="changes">Making and Commiting Changes</h2> | |
| 203 | +<h2 id="changes">Making and Committing Changes</h2> | |
| 204 | 204 | |
| 205 | 205 | <p>To add new files to your project or remove existing ones, use these |
| 206 | 206 | commands:</p> |
| 207 | 207 | |
| 208 | 208 | <blockquote> |
| @@ -532,14 +532,14 @@ | ||
| 532 | 532 | <b>fossil setting proxy off</b> |
| 533 | 533 | </blockquote> |
| 534 | 534 | |
| 535 | 535 | <p>Or unset the environment variable. The fossil setting for the |
| 536 | 536 | HTTP proxy takes precedence over the environment variable and the |
| 537 | -command-line option overrides both. If you have an persistent | |
| 537 | +command-line option overrides both. If you have a persistent | |
| 538 | 538 | proxy setting that you want to override for a one-time sync, that |
| 539 | 539 | is easily done on the command-line. For example, to sync with |
| 540 | -a co-workers repository on your LAN, you might type:</p> | |
| 540 | +a co-worker's repository on your LAN, you might type:</p> | |
| 541 | 541 | |
| 542 | 542 | <blockquote> |
| 543 | 543 | <b>fossil sync http://192.168.1.36:8080/ --proxy off</b> |
| 544 | 544 | </blockquote> |
| 545 | 545 | |
| 546 | 546 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -176,11 +176,11 @@ | |
| 176 | <b>[/help/timeline | fossil timeline]</b><br> |
| 177 | <b>[/help/ls | fossil ls]</b><br> |
| 178 | <b>[/help/branch | fossil branch]</b><br> |
| 179 | </blockquote> |
| 180 | |
| 181 | <p>If you created a new respository using "fossil init" some commands will not |
| 182 | produce much output.</p> |
| 183 | |
| 184 | <p>Note that Fossil allows you to make multiple check-outs in |
| 185 | separate directories from the same repository. This enables you, |
| 186 | for example, to do builds from multiple branches or versions at |
| @@ -198,11 +198,11 @@ | |
| 198 | does a "soft" switch, merging any local changes into the target |
| 199 | version, whereas [/help/checkout | checkout] does not |
| 200 | automatically sync and does a "hard" switch, overwriting local |
| 201 | changes if told to do so.</p> |
| 202 | |
| 203 | <h2 id="changes">Making and Commiting Changes</h2> |
| 204 | |
| 205 | <p>To add new files to your project or remove existing ones, use these |
| 206 | commands:</p> |
| 207 | |
| 208 | <blockquote> |
| @@ -532,14 +532,14 @@ | |
| 532 | <b>fossil setting proxy off</b> |
| 533 | </blockquote> |
| 534 | |
| 535 | <p>Or unset the environment variable. The fossil setting for the |
| 536 | HTTP proxy takes precedence over the environment variable and the |
| 537 | command-line option overrides both. If you have an persistent |
| 538 | proxy setting that you want to override for a one-time sync, that |
| 539 | is easily done on the command-line. For example, to sync with |
| 540 | a co-workers repository on your LAN, you might type:</p> |
| 541 | |
| 542 | <blockquote> |
| 543 | <b>fossil sync http://192.168.1.36:8080/ --proxy off</b> |
| 544 | </blockquote> |
| 545 | |
| 546 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -176,11 +176,11 @@ | |
| 176 | <b>[/help/timeline | fossil timeline]</b><br> |
| 177 | <b>[/help/ls | fossil ls]</b><br> |
| 178 | <b>[/help/branch | fossil branch]</b><br> |
| 179 | </blockquote> |
| 180 | |
| 181 | <p>If you created a new repository using "fossil init" some commands will not |
| 182 | produce much output.</p> |
| 183 | |
| 184 | <p>Note that Fossil allows you to make multiple check-outs in |
| 185 | separate directories from the same repository. This enables you, |
| 186 | for example, to do builds from multiple branches or versions at |
| @@ -198,11 +198,11 @@ | |
| 198 | does a "soft" switch, merging any local changes into the target |
| 199 | version, whereas [/help/checkout | checkout] does not |
| 200 | automatically sync and does a "hard" switch, overwriting local |
| 201 | changes if told to do so.</p> |
| 202 | |
| 203 | <h2 id="changes">Making and Committing Changes</h2> |
| 204 | |
| 205 | <p>To add new files to your project or remove existing ones, use these |
| 206 | commands:</p> |
| 207 | |
| 208 | <blockquote> |
| @@ -532,14 +532,14 @@ | |
| 532 | <b>fossil setting proxy off</b> |
| 533 | </blockquote> |
| 534 | |
| 535 | <p>Or unset the environment variable. The fossil setting for the |
| 536 | HTTP proxy takes precedence over the environment variable and the |
| 537 | command-line option overrides both. If you have a persistent |
| 538 | proxy setting that you want to override for a one-time sync, that |
| 539 | is easily done on the command-line. For example, to sync with |
| 540 | a co-worker's repository on your LAN, you might type:</p> |
| 541 | |
| 542 | <blockquote> |
| 543 | <b>fossil sync http://192.168.1.36:8080/ --proxy off</b> |
| 544 | </blockquote> |
| 545 | |
| 546 |
+1
-1
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -331,11 +331,11 @@ | ||
| 331 | 331 | presentation for routine display purposes. |
| 332 | 332 | |
| 333 | 333 | Git needs rebase because it lacks these annotation facilities. Rather |
| 334 | 334 | than consider rebase a desirable feature missing in Fossil, ask instead |
| 335 | 335 | why Git lacks support for making editorial changes to check-ins without |
| 336 | -modifyihng history? Wouldn't it be better to fix the version control | |
| 336 | +modifying history? Wouldn't it be better to fix the version control | |
| 337 | 337 | tool rather than requiring users to fabricate a fictitious project |
| 338 | 338 | history? |
| 339 | 339 | |
| 340 | 340 | ## <a name="collapsing"></a>6.0 Collapsing check-ins throws away valuable information |
| 341 | 341 | |
| 342 | 342 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -331,11 +331,11 @@ | |
| 331 | presentation for routine display purposes. |
| 332 | |
| 333 | Git needs rebase because it lacks these annotation facilities. Rather |
| 334 | than consider rebase a desirable feature missing in Fossil, ask instead |
| 335 | why Git lacks support for making editorial changes to check-ins without |
| 336 | modifyihng history? Wouldn't it be better to fix the version control |
| 337 | tool rather than requiring users to fabricate a fictitious project |
| 338 | history? |
| 339 | |
| 340 | ## <a name="collapsing"></a>6.0 Collapsing check-ins throws away valuable information |
| 341 | |
| 342 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -331,11 +331,11 @@ | |
| 331 | presentation for routine display purposes. |
| 332 | |
| 333 | Git needs rebase because it lacks these annotation facilities. Rather |
| 334 | than consider rebase a desirable feature missing in Fossil, ask instead |
| 335 | why Git lacks support for making editorial changes to check-ins without |
| 336 | modifying history? Wouldn't it be better to fix the version control |
| 337 | tool rather than requiring users to fabricate a fictitious project |
| 338 | history? |
| 339 | |
| 340 | ## <a name="collapsing"></a>6.0 Collapsing check-ins throws away valuable information |
| 341 | |
| 342 |
+1
-1
| --- www/server/any/althttpd.md | ||
| +++ www/server/any/althttpd.md | ||
| @@ -9,11 +9,11 @@ | ||
| 9 | 9 | server, follow these steps. |
| 10 | 10 | <ol> |
| 11 | 11 | <li<p>Get the althttpd webserver running on the host. This is easily |
| 12 | 12 | done by following the [althttpd documentation][althttpd]. |
| 13 | 13 | |
| 14 | -<li><p>Create a CGI script for your Fossil respository. The script will | |
| 14 | +<li><p>Create a CGI script for your Fossil repository. The script will | |
| 15 | 15 | be typically be two lines of code that look something like this: |
| 16 | 16 | |
| 17 | 17 | ~~~ |
| 18 | 18 | #!/usr/bin/fossil |
| 19 | 19 | repository: /home/yourlogin/fossils/project.fossil |
| 20 | 20 |
| --- www/server/any/althttpd.md | |
| +++ www/server/any/althttpd.md | |
| @@ -9,11 +9,11 @@ | |
| 9 | server, follow these steps. |
| 10 | <ol> |
| 11 | <li<p>Get the althttpd webserver running on the host. This is easily |
| 12 | done by following the [althttpd documentation][althttpd]. |
| 13 | |
| 14 | <li><p>Create a CGI script for your Fossil respository. The script will |
| 15 | be typically be two lines of code that look something like this: |
| 16 | |
| 17 | ~~~ |
| 18 | #!/usr/bin/fossil |
| 19 | repository: /home/yourlogin/fossils/project.fossil |
| 20 |
| --- www/server/any/althttpd.md | |
| +++ www/server/any/althttpd.md | |
| @@ -9,11 +9,11 @@ | |
| 9 | server, follow these steps. |
| 10 | <ol> |
| 11 | <li<p>Get the althttpd webserver running on the host. This is easily |
| 12 | done by following the [althttpd documentation][althttpd]. |
| 13 | |
| 14 | <li><p>Create a CGI script for your Fossil repository. The script will |
| 15 | be typically be two lines of code that look something like this: |
| 16 | |
| 17 | ~~~ |
| 18 | #!/usr/bin/fossil |
| 19 | repository: /home/yourlogin/fossils/project.fossil |
| 20 |
+1
-1
| --- www/server/debian/service.md | ||
| +++ www/server/debian/service.md | ||
| @@ -103,11 +103,11 @@ | ||
| 103 | 103 | |
| 104 | 104 | /etc/systemd/system |
| 105 | 105 | /lib/systemd/system |
| 106 | 106 | |
| 107 | 107 | 2. Add `User` and `Group` directives to the `[Service]` section so |
| 108 | - Fossil runs as a normal user, preferrably one with access only to | |
| 108 | + Fossil runs as a normal user, preferably one with access only to | |
| 109 | 109 | the Fossil repo files, rather than running as `root`. |
| 110 | 110 | |
| 111 | 111 | |
| 112 | 112 | ## Socket Activation |
| 113 | 113 | |
| 114 | 114 |
| --- www/server/debian/service.md | |
| +++ www/server/debian/service.md | |
| @@ -103,11 +103,11 @@ | |
| 103 | |
| 104 | /etc/systemd/system |
| 105 | /lib/systemd/system |
| 106 | |
| 107 | 2. Add `User` and `Group` directives to the `[Service]` section so |
| 108 | Fossil runs as a normal user, preferrably one with access only to |
| 109 | the Fossil repo files, rather than running as `root`. |
| 110 | |
| 111 | |
| 112 | ## Socket Activation |
| 113 | |
| 114 |
| --- www/server/debian/service.md | |
| +++ www/server/debian/service.md | |
| @@ -103,11 +103,11 @@ | |
| 103 | |
| 104 | /etc/systemd/system |
| 105 | /lib/systemd/system |
| 106 | |
| 107 | 2. Add `User` and `Group` directives to the `[Service]` section so |
| 108 | Fossil runs as a normal user, preferably one with access only to |
| 109 | the Fossil repo files, rather than running as `root`. |
| 110 | |
| 111 | |
| 112 | ## Socket Activation |
| 113 | |
| 114 |
+1
-1
| --- www/server/openbsd/fastcgi.md | ||
| +++ www/server/openbsd/fastcgi.md | ||
| @@ -68,11 +68,11 @@ | ||
| 68 | 68 | Fossil needs both `/dev/random` and `/dev/null`, which aren't accessible |
| 69 | 69 | from within the chroot, so need to be constructed; `/var`, however, is |
| 70 | 70 | mounted with the `nodev` option. Rather than removing this default |
| 71 | 71 | setting, create a small memory filesystem and then mount it on to |
| 72 | 72 | `/var/www/dev` with [`mount_mfs(8)`][mfs] so that the `random` and |
| 73 | -`null` device files can be created. In order to avoid neccessitating a | |
| 73 | +`null` device files can be created. In order to avoid necessitating a | |
| 74 | 74 | startup script to recreate the device files at boot, create a template |
| 75 | 75 | of the needed ``/dev`` tree to automatically populate the memory |
| 76 | 76 | filesystem. |
| 77 | 77 | |
| 78 | 78 | ```console |
| 79 | 79 |
| --- www/server/openbsd/fastcgi.md | |
| +++ www/server/openbsd/fastcgi.md | |
| @@ -68,11 +68,11 @@ | |
| 68 | Fossil needs both `/dev/random` and `/dev/null`, which aren't accessible |
| 69 | from within the chroot, so need to be constructed; `/var`, however, is |
| 70 | mounted with the `nodev` option. Rather than removing this default |
| 71 | setting, create a small memory filesystem and then mount it on to |
| 72 | `/var/www/dev` with [`mount_mfs(8)`][mfs] so that the `random` and |
| 73 | `null` device files can be created. In order to avoid neccessitating a |
| 74 | startup script to recreate the device files at boot, create a template |
| 75 | of the needed ``/dev`` tree to automatically populate the memory |
| 76 | filesystem. |
| 77 | |
| 78 | ```console |
| 79 |
| --- www/server/openbsd/fastcgi.md | |
| +++ www/server/openbsd/fastcgi.md | |
| @@ -68,11 +68,11 @@ | |
| 68 | Fossil needs both `/dev/random` and `/dev/null`, which aren't accessible |
| 69 | from within the chroot, so need to be constructed; `/var`, however, is |
| 70 | mounted with the `nodev` option. Rather than removing this default |
| 71 | setting, create a small memory filesystem and then mount it on to |
| 72 | `/var/www/dev` with [`mount_mfs(8)`][mfs] so that the `random` and |
| 73 | `null` device files can be created. In order to avoid necessitating a |
| 74 | startup script to recreate the device files at boot, create a template |
| 75 | of the needed ``/dev`` tree to automatically populate the memory |
| 76 | filesystem. |
| 77 | |
| 78 | ```console |
| 79 |
+1
-1
| --- www/server/whyuseaserver.wiki | ||
| +++ www/server/whyuseaserver.wiki | ||
| @@ -26,11 +26,11 @@ | ||
| 26 | 26 | 2. <b>A server gives developers a common point of rendezvous for |
| 27 | 27 | syncing their work.</b><p> |
| 28 | 28 | It is possible for developers to synchronize peer-to-peer but |
| 29 | 29 | that requires the developers coordinate the sync, which in turn |
| 30 | 30 | requires that the developers both want to sync at the same moment. |
| 31 | - A server aleviates this time dependency by allowing each developer | |
| 31 | + A server alleviates this time dependency by allowing each developer | |
| 32 | 32 | to sync whenever it is convenient (for example, automatically syncing |
| 33 | 33 | after each commit and before each update). Developers all stay |
| 34 | 34 | in sync with each other, without having to interrupt each other |
| 35 | 35 | constantly to set up a peer-to-peer sync. |
| 36 | 36 | |
| 37 | 37 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -26,11 +26,11 @@ | |
| 26 | 2. <b>A server gives developers a common point of rendezvous for |
| 27 | syncing their work.</b><p> |
| 28 | It is possible for developers to synchronize peer-to-peer but |
| 29 | that requires the developers coordinate the sync, which in turn |
| 30 | requires that the developers both want to sync at the same moment. |
| 31 | A server aleviates this time dependency by allowing each developer |
| 32 | to sync whenever it is convenient (for example, automatically syncing |
| 33 | after each commit and before each update). Developers all stay |
| 34 | in sync with each other, without having to interrupt each other |
| 35 | constantly to set up a peer-to-peer sync. |
| 36 | |
| 37 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -26,11 +26,11 @@ | |
| 26 | 2. <b>A server gives developers a common point of rendezvous for |
| 27 | syncing their work.</b><p> |
| 28 | It is possible for developers to synchronize peer-to-peer but |
| 29 | that requires the developers coordinate the sync, which in turn |
| 30 | requires that the developers both want to sync at the same moment. |
| 31 | A server alleviates this time dependency by allowing each developer |
| 32 | to sync whenever it is convenient (for example, automatically syncing |
| 33 | after each commit and before each update). Developers all stay |
| 34 | in sync with each other, without having to interrupt each other |
| 35 | constantly to set up a peer-to-peer sync. |
| 36 | |
| 37 |
+1
-1
| --- www/shunning.wiki | ||
| +++ www/shunning.wiki | ||
| @@ -92,11 +92,11 @@ | ||
| 92 | 92 | |
| 93 | 93 | <h2>Exception: Non-versioned Content</h2> |
| 94 | 94 | |
| 95 | 95 | It is normal and expected to delete data which is not versioned, such as |
| 96 | 96 | usernames and passwords in the user table. The [/help/scrub|fossil scrub] |
| 97 | -command will remove all sensitive non-versioned data from a respository. | |
| 97 | +command will remove all sensitive non-versioned data from a repository. | |
| 98 | 98 | |
| 99 | 99 | The scrub command will remove user 'bertina', along with their password, |
| 100 | 100 | any supplied IP address, any concealed email address etc. However, in the |
| 101 | 101 | DAG, commits by 'bertina' will continue to be visible unchanged even though |
| 102 | 102 | there is no longer any such user in Fossil. |
| 103 | 103 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -92,11 +92,11 @@ | |
| 92 | |
| 93 | <h2>Exception: Non-versioned Content</h2> |
| 94 | |
| 95 | It is normal and expected to delete data which is not versioned, such as |
| 96 | usernames and passwords in the user table. The [/help/scrub|fossil scrub] |
| 97 | command will remove all sensitive non-versioned data from a respository. |
| 98 | |
| 99 | The scrub command will remove user 'bertina', along with their password, |
| 100 | any supplied IP address, any concealed email address etc. However, in the |
| 101 | DAG, commits by 'bertina' will continue to be visible unchanged even though |
| 102 | there is no longer any such user in Fossil. |
| 103 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -92,11 +92,11 @@ | |
| 92 | |
| 93 | <h2>Exception: Non-versioned Content</h2> |
| 94 | |
| 95 | It is normal and expected to delete data which is not versioned, such as |
| 96 | usernames and passwords in the user table. The [/help/scrub|fossil scrub] |
| 97 | command will remove all sensitive non-versioned data from a repository. |
| 98 | |
| 99 | The scrub command will remove user 'bertina', along with their password, |
| 100 | any supplied IP address, any concealed email address etc. However, in the |
| 101 | DAG, commits by 'bertina' will continue to be visible unchanged even though |
| 102 | there is no longer any such user in Fossil. |
| 103 |
+1
-1
| --- www/ssl.wiki | ||
| +++ www/ssl.wiki | ||
| @@ -157,11 +157,11 @@ | ||
| 157 | 157 | <pre> |
| 158 | 158 | fossil set --global ssl-ca-location /path/to/local-ca.pem |
| 159 | 159 | </pre> |
| 160 | 160 | |
| 161 | 161 | The use of <tt>--global</tt> with this option is common, since you may |
| 162 | -have multiple reposotories served under certificates signed by that same | |
| 162 | +have multiple repositories served under certificates signed by that same | |
| 163 | 163 | CA. However, if you have a mix of publicly-signed and locally-signed |
| 164 | 164 | certificates, you might want to drop the <tt>--global</tt> flag and set |
| 165 | 165 | this option on a per-repository basis instead. |
| 166 | 166 | |
| 167 | 167 | A common way to run into the broader first problem is that you're on |
| 168 | 168 |
| --- www/ssl.wiki | |
| +++ www/ssl.wiki | |
| @@ -157,11 +157,11 @@ | |
| 157 | <pre> |
| 158 | fossil set --global ssl-ca-location /path/to/local-ca.pem |
| 159 | </pre> |
| 160 | |
| 161 | The use of <tt>--global</tt> with this option is common, since you may |
| 162 | have multiple reposotories served under certificates signed by that same |
| 163 | CA. However, if you have a mix of publicly-signed and locally-signed |
| 164 | certificates, you might want to drop the <tt>--global</tt> flag and set |
| 165 | this option on a per-repository basis instead. |
| 166 | |
| 167 | A common way to run into the broader first problem is that you're on |
| 168 |
| --- www/ssl.wiki | |
| +++ www/ssl.wiki | |
| @@ -157,11 +157,11 @@ | |
| 157 | <pre> |
| 158 | fossil set --global ssl-ca-location /path/to/local-ca.pem |
| 159 | </pre> |
| 160 | |
| 161 | The use of <tt>--global</tt> with this option is common, since you may |
| 162 | have multiple repositories served under certificates signed by that same |
| 163 | CA. However, if you have a mix of publicly-signed and locally-signed |
| 164 | certificates, you might want to drop the <tt>--global</tt> flag and set |
| 165 | this option on a per-repository basis instead. |
| 166 | |
| 167 | A common way to run into the broader first problem is that you're on |
| 168 |