Fossil SCM
Typo fix pass on www/*
Commit
79c2cb083152d2c6ca8a284b208e296c3a258bcb048804c1b45b65d697f2dbb5
Parent
bf25835f6bc9b6a…
17 files changed
+2
-2
+3
-3
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+1
-1
+8
-8
+1
-1
+3
-3
+2
-2
+1
-1
+4
-4
+3
-3
+3
-3
~
www/admin-v-setup.md
~
www/alerts.md
~
www/backoffice.md
~
www/blockchain.md
~
www/branching.wiki
~
www/build.wiki
~
www/customskin.md
~
www/encryptedrepos.wiki
~
www/env-opts.md
~
www/fossil-v-git.wiki
~
www/hashpolicy.wiki
~
www/image-format-vs-repo-size.md
~
www/mirrorlimitations.md
~
www/password.wiki
~
www/sync.wiki
~
www/tls-nginx.md
~
www/unvers.wiki
+2
-2
| --- www/admin-v-setup.md | ||
| +++ www/admin-v-setup.md | ||
| @@ -130,11 +130,11 @@ | ||
| 130 | 130 | |
| 131 | 131 | It is perfectly fine for a Fossil repository to only have Setup users, |
| 132 | 132 | no Admin users. The smaller the repository, the more likely the |
| 133 | 133 | repository has no Admin-only users. If the Setup user neither needs nor |
| 134 | 134 | wants to grant Admin power to others, there is no requirement in Fossil |
| 135 | -to do so. [Setup capabilty is a pure superset of Admin capability.][sia] | |
| 135 | +to do so. [Setup capability is a pure superset of Admin capability.][sia] | |
| 136 | 136 | |
| 137 | 137 | As the number of users on a Fossil repository grows, the value in |
| 138 | 138 | delegating administrivia also grows, because the Setup user typically |
| 139 | 139 | has other time sinks they consider more important. |
| 140 | 140 | |
| @@ -308,11 +308,11 @@ | ||
| 308 | 308 | the host such as via `PRAGMA temp_store = FILE`. |
| 309 | 309 | |
| 310 | 310 | * **TH1**: The [TH1 language][TH1] is quite restricted relative to the |
| 311 | 311 | Tcl language it descends from, so this author does not believe there |
| 312 | 312 | is a way to damage the Fossil repository or its host via the Admin → |
| 313 | - TH1 feature, which allows exeuction of arbitrary TH1 code within the | |
| 313 | + TH1 feature, which allows execution of arbitrary TH1 code within the | |
| 314 | 314 | repository's execution context. Nevertheless, interpreters are a |
| 315 | 315 | well-known source of security problems, so it seems best to restrict |
| 316 | 316 | this feature to Setup-only users as long as we lack a good reason |
| 317 | 317 | for Admin-only users to have access to it. |
| 318 | 318 | |
| 319 | 319 |
| --- www/admin-v-setup.md | |
| +++ www/admin-v-setup.md | |
| @@ -130,11 +130,11 @@ | |
| 130 | |
| 131 | It is perfectly fine for a Fossil repository to only have Setup users, |
| 132 | no Admin users. The smaller the repository, the more likely the |
| 133 | repository has no Admin-only users. If the Setup user neither needs nor |
| 134 | wants to grant Admin power to others, there is no requirement in Fossil |
| 135 | to do so. [Setup capabilty is a pure superset of Admin capability.][sia] |
| 136 | |
| 137 | As the number of users on a Fossil repository grows, the value in |
| 138 | delegating administrivia also grows, because the Setup user typically |
| 139 | has other time sinks they consider more important. |
| 140 | |
| @@ -308,11 +308,11 @@ | |
| 308 | the host such as via `PRAGMA temp_store = FILE`. |
| 309 | |
| 310 | * **TH1**: The [TH1 language][TH1] is quite restricted relative to the |
| 311 | Tcl language it descends from, so this author does not believe there |
| 312 | is a way to damage the Fossil repository or its host via the Admin → |
| 313 | TH1 feature, which allows exeuction of arbitrary TH1 code within the |
| 314 | repository's execution context. Nevertheless, interpreters are a |
| 315 | well-known source of security problems, so it seems best to restrict |
| 316 | this feature to Setup-only users as long as we lack a good reason |
| 317 | for Admin-only users to have access to it. |
| 318 | |
| 319 |
| --- www/admin-v-setup.md | |
| +++ www/admin-v-setup.md | |
| @@ -130,11 +130,11 @@ | |
| 130 | |
| 131 | It is perfectly fine for a Fossil repository to only have Setup users, |
| 132 | no Admin users. The smaller the repository, the more likely the |
| 133 | repository has no Admin-only users. If the Setup user neither needs nor |
| 134 | wants to grant Admin power to others, there is no requirement in Fossil |
| 135 | to do so. [Setup capability is a pure superset of Admin capability.][sia] |
| 136 | |
| 137 | As the number of users on a Fossil repository grows, the value in |
| 138 | delegating administrivia also grows, because the Setup user typically |
| 139 | has other time sinks they consider more important. |
| 140 | |
| @@ -308,11 +308,11 @@ | |
| 308 | the host such as via `PRAGMA temp_store = FILE`. |
| 309 | |
| 310 | * **TH1**: The [TH1 language][TH1] is quite restricted relative to the |
| 311 | Tcl language it descends from, so this author does not believe there |
| 312 | is a way to damage the Fossil repository or its host via the Admin → |
| 313 | TH1 feature, which allows execution of arbitrary TH1 code within the |
| 314 | repository's execution context. Nevertheless, interpreters are a |
| 315 | well-known source of security problems, so it seems best to restrict |
| 316 | this feature to Setup-only users as long as we lack a good reason |
| 317 | for Admin-only users to have access to it. |
| 318 | |
| 319 |
+3
-3
| --- www/alerts.md | ||
| +++ www/alerts.md | ||
| @@ -64,11 +64,11 @@ | ||
| 64 | 64 | |
| 65 | 65 | (Otherwise, skip [ahead](#advanced) to the sections on advanced email |
| 66 | 66 | service setup.) |
| 67 | 67 | |
| 68 | 68 | This is our "quick setup" option even though setting up an SMTP mail |
| 69 | -server is not trival, because there are many other reasons to have such | |
| 69 | +server is not trivial, because there are many other reasons to have such | |
| 70 | 70 | a server set up already: internal project email service, `cron` |
| 71 | 71 | notifications, server status monitoring notifications... |
| 72 | 72 | |
| 73 | 73 | With that out of the way, the Fossil-specific steps are easy: |
| 74 | 74 | |
| @@ -194,11 +194,11 @@ | ||
| 194 | 194 | |
| 195 | 195 | <a id="unsub" name="unsubscribe"></a> |
| 196 | 196 | ### Unsubscribing |
| 197 | 197 | |
| 198 | 198 | To unsubscribe from alerts, visit the `/alerts` page on the repository, |
| 199 | -click the "Unsubscribe" button, then check the "Unsbuscribe" checkbox to | |
| 199 | +click the "Unsubscribe" button, then check the "Unsubscribe" checkbox to | |
| 200 | 200 | verify your action and press the "Unsubscribe" button a second time. |
| 201 | 201 | |
| 202 | 202 | This interlock is intended to prevent accidental unsubscription. |
| 203 | 203 | |
| 204 | 204 | |
| @@ -568,11 +568,11 @@ | ||
| 568 | 568 | |
| 569 | 569 | <a id="design"></a> |
| 570 | 570 | ## Design of Email Alerts |
| 571 | 571 | |
| 572 | 572 | This section describes the low-level design of the email alert system in |
| 573 | -Fossil. This expands on the high-level administion focused material | |
| 573 | +Fossil. This expands on the high-level administration focused material | |
| 574 | 574 | above with minimal repetition. |
| 575 | 575 | |
| 576 | 576 | This section assumes expert-level systems knowledge. If the material |
| 577 | 577 | above sufficed for your purposes, feel free to skip this section, which |
| 578 | 578 | runs to the end of this document. |
| 579 | 579 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -64,11 +64,11 @@ | |
| 64 | |
| 65 | (Otherwise, skip [ahead](#advanced) to the sections on advanced email |
| 66 | service setup.) |
| 67 | |
| 68 | This is our "quick setup" option even though setting up an SMTP mail |
| 69 | server is not trival, because there are many other reasons to have such |
| 70 | a server set up already: internal project email service, `cron` |
| 71 | notifications, server status monitoring notifications... |
| 72 | |
| 73 | With that out of the way, the Fossil-specific steps are easy: |
| 74 | |
| @@ -194,11 +194,11 @@ | |
| 194 | |
| 195 | <a id="unsub" name="unsubscribe"></a> |
| 196 | ### Unsubscribing |
| 197 | |
| 198 | To unsubscribe from alerts, visit the `/alerts` page on the repository, |
| 199 | click the "Unsubscribe" button, then check the "Unsbuscribe" checkbox to |
| 200 | verify your action and press the "Unsubscribe" button a second time. |
| 201 | |
| 202 | This interlock is intended to prevent accidental unsubscription. |
| 203 | |
| 204 | |
| @@ -568,11 +568,11 @@ | |
| 568 | |
| 569 | <a id="design"></a> |
| 570 | ## Design of Email Alerts |
| 571 | |
| 572 | This section describes the low-level design of the email alert system in |
| 573 | Fossil. This expands on the high-level administion focused material |
| 574 | above with minimal repetition. |
| 575 | |
| 576 | This section assumes expert-level systems knowledge. If the material |
| 577 | above sufficed for your purposes, feel free to skip this section, which |
| 578 | runs to the end of this document. |
| 579 |
| --- www/alerts.md | |
| +++ www/alerts.md | |
| @@ -64,11 +64,11 @@ | |
| 64 | |
| 65 | (Otherwise, skip [ahead](#advanced) to the sections on advanced email |
| 66 | service setup.) |
| 67 | |
| 68 | This is our "quick setup" option even though setting up an SMTP mail |
| 69 | server is not trivial, because there are many other reasons to have such |
| 70 | a server set up already: internal project email service, `cron` |
| 71 | notifications, server status monitoring notifications... |
| 72 | |
| 73 | With that out of the way, the Fossil-specific steps are easy: |
| 74 | |
| @@ -194,11 +194,11 @@ | |
| 194 | |
| 195 | <a id="unsub" name="unsubscribe"></a> |
| 196 | ### Unsubscribing |
| 197 | |
| 198 | To unsubscribe from alerts, visit the `/alerts` page on the repository, |
| 199 | click the "Unsubscribe" button, then check the "Unsubscribe" checkbox to |
| 200 | verify your action and press the "Unsubscribe" button a second time. |
| 201 | |
| 202 | This interlock is intended to prevent accidental unsubscription. |
| 203 | |
| 204 | |
| @@ -568,11 +568,11 @@ | |
| 568 | |
| 569 | <a id="design"></a> |
| 570 | ## Design of Email Alerts |
| 571 | |
| 572 | This section describes the low-level design of the email alert system in |
| 573 | Fossil. This expands on the high-level administration focused material |
| 574 | above with minimal repetition. |
| 575 | |
| 576 | This section assumes expert-level systems knowledge. If the material |
| 577 | above sufficed for your purposes, feel free to skip this section, which |
| 578 | runs to the end of this document. |
| 579 |
+1
-1
| --- www/backoffice.md | ||
| +++ www/backoffice.md | ||
| @@ -74,11 +74,11 @@ | ||
| 74 | 74 | The automatic backoffice runs are sufficient for most installations. |
| 75 | 75 | However, the daily digest of email notifications is handled by the |
| 76 | 76 | backoffice. If a Fossil server can sometimes go more than a day without |
| 77 | 77 | being accessed, then the automatic backoffice will never run, and the |
| 78 | 78 | daily digest might not go out until somebody does visit a webpage. |
| 79 | -If this is a problem, an adminstrator can set up a cron job to | |
| 79 | +If this is a problem, an administrator can set up a cron job to | |
| 80 | 80 | periodically run: |
| 81 | 81 | |
| 82 | 82 | > fossil backoffice _REPOSITORY_ |
| 83 | 83 | |
| 84 | 84 | That command will cause backoffice processing to occur immediately. |
| 85 | 85 |
| --- www/backoffice.md | |
| +++ www/backoffice.md | |
| @@ -74,11 +74,11 @@ | |
| 74 | The automatic backoffice runs are sufficient for most installations. |
| 75 | However, the daily digest of email notifications is handled by the |
| 76 | backoffice. If a Fossil server can sometimes go more than a day without |
| 77 | being accessed, then the automatic backoffice will never run, and the |
| 78 | daily digest might not go out until somebody does visit a webpage. |
| 79 | If this is a problem, an adminstrator can set up a cron job to |
| 80 | periodically run: |
| 81 | |
| 82 | > fossil backoffice _REPOSITORY_ |
| 83 | |
| 84 | That command will cause backoffice processing to occur immediately. |
| 85 |
| --- www/backoffice.md | |
| +++ www/backoffice.md | |
| @@ -74,11 +74,11 @@ | |
| 74 | The automatic backoffice runs are sufficient for most installations. |
| 75 | However, the daily digest of email notifications is handled by the |
| 76 | backoffice. If a Fossil server can sometimes go more than a day without |
| 77 | being accessed, then the automatic backoffice will never run, and the |
| 78 | daily digest might not go out until somebody does visit a webpage. |
| 79 | If this is a problem, an administrator can set up a cron job to |
| 80 | periodically run: |
| 81 | |
| 82 | > fossil backoffice _REPOSITORY_ |
| 83 | |
| 84 | That command will cause backoffice processing to occur immediately. |
| 85 |
+1
-1
| --- www/blockchain.md | ||
| +++ www/blockchain.md | ||
| @@ -11,11 +11,11 @@ | ||
| 11 | 11 | |
| 12 | 12 | |
| 13 | 13 | By that definition, Fossil is clearly an implementation of blockchain. |
| 14 | 14 | The blocks are ["manifests" artifacts](./fileformat.wiki#manifest). |
| 15 | 15 | Each manifest has a SHA1 or SHA3 hash of its parent or parents, |
| 16 | -a timestamp, and other tranactional data. The repository grows by | |
| 16 | +a timestamp, and other transactional data. The repository grows by | |
| 17 | 17 | add new manifests onto the list. |
| 18 | 18 | |
| 19 | 19 | Some people have come to associate blockchain with cryptocurrency, however, |
| 20 | 20 | and since Fossil has nothing to do with cryptocurrency, the claim that |
| 21 | 21 | Fossil is build around blockchain is met with skepticism. The key thing |
| 22 | 22 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -11,11 +11,11 @@ | |
| 11 | |
| 12 | |
| 13 | By that definition, Fossil is clearly an implementation of blockchain. |
| 14 | The blocks are ["manifests" artifacts](./fileformat.wiki#manifest). |
| 15 | Each manifest has a SHA1 or SHA3 hash of its parent or parents, |
| 16 | a timestamp, and other tranactional data. The repository grows by |
| 17 | add new manifests onto the list. |
| 18 | |
| 19 | Some people have come to associate blockchain with cryptocurrency, however, |
| 20 | and since Fossil has nothing to do with cryptocurrency, the claim that |
| 21 | Fossil is build around blockchain is met with skepticism. The key thing |
| 22 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -11,11 +11,11 @@ | |
| 11 | |
| 12 | |
| 13 | By that definition, Fossil is clearly an implementation of blockchain. |
| 14 | The blocks are ["manifests" artifacts](./fileformat.wiki#manifest). |
| 15 | Each manifest has a SHA1 or SHA3 hash of its parent or parents, |
| 16 | a timestamp, and other transactional data. The repository grows by |
| 17 | add new manifests onto the list. |
| 18 | |
| 19 | Some people have come to associate blockchain with cryptocurrency, however, |
| 20 | and since Fossil has nothing to do with cryptocurrency, the claim that |
| 21 | Fossil is build around blockchain is met with skepticism. The key thing |
| 22 |
+1
-1
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -244,11 +244,11 @@ | ||
| 244 | 244 | fork until the two repositories are later sync'd.</p></li> |
| 245 | 245 | |
| 246 | 246 | <li><p id="dist-clone">By Fossil when the cloning hierarchy is more |
| 247 | 247 | than 2 levels deep. |
| 248 | 248 | <br><br> |
| 249 | - [./sync.wiki|Fossil's synchronication protocol] is a two-party | |
| 249 | + [./sync.wiki|Fossil's synchronization protocol] is a two-party | |
| 250 | 250 | negotiation; syncs don't automatically propagate up the clone tree |
| 251 | 251 | beyond that. Because of that, if you have a master repository and |
| 252 | 252 | Alice clones it, then Bobby clones from Alice's repository, a |
| 253 | 253 | check-in by Bobby that autosyncs with Alice's repo will <i>not</i> |
| 254 | 254 | also autosync with the master repo. The master doesn't get a copy of |
| 255 | 255 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -244,11 +244,11 @@ | |
| 244 | fork until the two repositories are later sync'd.</p></li> |
| 245 | |
| 246 | <li><p id="dist-clone">By Fossil when the cloning hierarchy is more |
| 247 | than 2 levels deep. |
| 248 | <br><br> |
| 249 | [./sync.wiki|Fossil's synchronication protocol] is a two-party |
| 250 | negotiation; syncs don't automatically propagate up the clone tree |
| 251 | beyond that. Because of that, if you have a master repository and |
| 252 | Alice clones it, then Bobby clones from Alice's repository, a |
| 253 | check-in by Bobby that autosyncs with Alice's repo will <i>not</i> |
| 254 | also autosync with the master repo. The master doesn't get a copy of |
| 255 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -244,11 +244,11 @@ | |
| 244 | fork until the two repositories are later sync'd.</p></li> |
| 245 | |
| 246 | <li><p id="dist-clone">By Fossil when the cloning hierarchy is more |
| 247 | than 2 levels deep. |
| 248 | <br><br> |
| 249 | [./sync.wiki|Fossil's synchronization protocol] is a two-party |
| 250 | negotiation; syncs don't automatically propagate up the clone tree |
| 251 | beyond that. Because of that, if you have a master repository and |
| 252 | Alice clones it, then Bobby clones from Alice's repository, a |
| 253 | check-in by Bobby that autosyncs with Alice's repo will <i>not</i> |
| 254 | also autosync with the master repo. The master doesn't get a copy of |
| 255 |
+1
-1
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -133,11 +133,11 @@ | ||
| 133 | 133 | want to make minor edits to Makefile.classic to configure the build for your |
| 134 | 134 | system. |
| 135 | 135 | |
| 136 | 136 | <li><p><i>MinGW 3.x (<u>not</u> 4.x) / MinGW-w64</i> → Use the MinGW makefile: |
| 137 | 137 | "<b>make -f win/Makefile.mingw</b>". On a Windows box you will need either |
| 138 | -Cygwin or Msys as build environment. On Cygwin, Linux or Darwin you may want | |
| 138 | +Cygwin or MSYS as build environment. On Cygwin, Linux or Darwin you may want | |
| 139 | 139 | to make minor edits to win/Makefile.mingw to configure the cross-compile |
| 140 | 140 | environment. |
| 141 | 141 | |
| 142 | 142 | To enable the native [./th1.md#tclEval | Tcl integration feature], use a |
| 143 | 143 | command line like the following (all on one line): |
| 144 | 144 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -133,11 +133,11 @@ | |
| 133 | want to make minor edits to Makefile.classic to configure the build for your |
| 134 | system. |
| 135 | |
| 136 | <li><p><i>MinGW 3.x (<u>not</u> 4.x) / MinGW-w64</i> → Use the MinGW makefile: |
| 137 | "<b>make -f win/Makefile.mingw</b>". On a Windows box you will need either |
| 138 | Cygwin or Msys as build environment. On Cygwin, Linux or Darwin you may want |
| 139 | to make minor edits to win/Makefile.mingw to configure the cross-compile |
| 140 | environment. |
| 141 | |
| 142 | To enable the native [./th1.md#tclEval | Tcl integration feature], use a |
| 143 | command line like the following (all on one line): |
| 144 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -133,11 +133,11 @@ | |
| 133 | want to make minor edits to Makefile.classic to configure the build for your |
| 134 | system. |
| 135 | |
| 136 | <li><p><i>MinGW 3.x (<u>not</u> 4.x) / MinGW-w64</i> → Use the MinGW makefile: |
| 137 | "<b>make -f win/Makefile.mingw</b>". On a Windows box you will need either |
| 138 | Cygwin or MSYS as build environment. On Cygwin, Linux or Darwin you may want |
| 139 | to make minor edits to win/Makefile.mingw to configure the cross-compile |
| 140 | environment. |
| 141 | |
| 142 | To enable the native [./th1.md#tclEval | Tcl integration feature], use a |
| 143 | command line like the following (all on one line): |
| 144 |
+1
-1
| --- www/customskin.md | ||
| +++ www/customskin.md | ||
| @@ -198,11 +198,11 @@ | ||
| 198 | 198 | TH1 Variables |
| 199 | 199 | ------------- |
| 200 | 200 | |
| 201 | 201 | Before expanding the TH1 within the header and footer, Fossil first |
| 202 | 202 | initializes a number of TH1 variables to values that depend on |
| 203 | -respository settings and the specific page being generated. | |
| 203 | +repository settings and the specific page being generated. | |
| 204 | 204 | |
| 205 | 205 | * **project_name** - The project_name variable is filled with the |
| 206 | 206 | name of the project as configured under the Admin/Configuration |
| 207 | 207 | menu. |
| 208 | 208 | |
| 209 | 209 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -198,11 +198,11 @@ | |
| 198 | TH1 Variables |
| 199 | ------------- |
| 200 | |
| 201 | Before expanding the TH1 within the header and footer, Fossil first |
| 202 | initializes a number of TH1 variables to values that depend on |
| 203 | respository settings and the specific page being generated. |
| 204 | |
| 205 | * **project_name** - The project_name variable is filled with the |
| 206 | name of the project as configured under the Admin/Configuration |
| 207 | menu. |
| 208 | |
| 209 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -198,11 +198,11 @@ | |
| 198 | TH1 Variables |
| 199 | ------------- |
| 200 | |
| 201 | Before expanding the TH1 within the header and footer, Fossil first |
| 202 | initializes a number of TH1 variables to values that depend on |
| 203 | repository settings and the specific page being generated. |
| 204 | |
| 205 | * **project_name** - The project_name variable is filled with the |
| 206 | name of the project as configured under the Admin/Configuration |
| 207 | menu. |
| 208 | |
| 209 |
+1
-1
| --- www/encryptedrepos.wiki | ||
| +++ www/encryptedrepos.wiki | ||
| @@ -50,11 +50,11 @@ | ||
| 50 | 50 | prevents fossil from trying to remember the previous sync password. |
| 51 | 51 | <blockquote><pre> |
| 52 | 52 | export FOSSIL_SECURITY_LEVEL=2 |
| 53 | 53 | </pre></blockquote> |
| 54 | 54 | A setting of 2 or greater |
| 55 | -causes all password prompts to be preceeded by a random translation matrix similar | |
| 55 | +causes all password prompts to be preceded by a random translation matrix similar | |
| 56 | 56 | to the following: |
| 57 | 57 | <blockquote><pre> |
| 58 | 58 | abcde fghij klmno pqrst uvwyz |
| 59 | 59 | qresw gjymu dpcoa fhkzv inlbt |
| 60 | 60 | </pre></blockquote> |
| 61 | 61 |
| --- www/encryptedrepos.wiki | |
| +++ www/encryptedrepos.wiki | |
| @@ -50,11 +50,11 @@ | |
| 50 | prevents fossil from trying to remember the previous sync password. |
| 51 | <blockquote><pre> |
| 52 | export FOSSIL_SECURITY_LEVEL=2 |
| 53 | </pre></blockquote> |
| 54 | A setting of 2 or greater |
| 55 | causes all password prompts to be preceeded by a random translation matrix similar |
| 56 | to the following: |
| 57 | <blockquote><pre> |
| 58 | abcde fghij klmno pqrst uvwyz |
| 59 | qresw gjymu dpcoa fhkzv inlbt |
| 60 | </pre></blockquote> |
| 61 |
| --- www/encryptedrepos.wiki | |
| +++ www/encryptedrepos.wiki | |
| @@ -50,11 +50,11 @@ | |
| 50 | prevents fossil from trying to remember the previous sync password. |
| 51 | <blockquote><pre> |
| 52 | export FOSSIL_SECURITY_LEVEL=2 |
| 53 | </pre></blockquote> |
| 54 | A setting of 2 or greater |
| 55 | causes all password prompts to be preceded by a random translation matrix similar |
| 56 | to the following: |
| 57 | <blockquote><pre> |
| 58 | abcde fghij klmno pqrst uvwyz |
| 59 | qresw gjymu dpcoa fhkzv inlbt |
| 60 | </pre></blockquote> |
| 61 |
+1
-1
| --- www/env-opts.md | ||
| +++ www/env-opts.md | ||
| @@ -148,11 +148,11 @@ | ||
| 148 | 148 | `HOMEPATH` (Windows, used together), and `HOME` is used as the |
| 149 | 149 | location of the `~/.fossil` file. |
| 150 | 150 | |
| 151 | 151 | |
| 152 | 152 | `FOSSIL_USE_SEE_TEXTKEY`: If set, treat the encryption key string for |
| 153 | -SEE as text to be hashed into the actaul encryption key. This has no | |
| 153 | +SEE as text to be hashed into the actual encryption key. This has no | |
| 154 | 154 | effect if Fossil was not compiled with SEE support enabled. |
| 155 | 155 | |
| 156 | 156 | |
| 157 | 157 | `FOSSIL_USER`: Name of the default user account if the checkout, local |
| 158 | 158 | or global `default-user` setting is not present. The first environment |
| 159 | 159 |
| --- www/env-opts.md | |
| +++ www/env-opts.md | |
| @@ -148,11 +148,11 @@ | |
| 148 | `HOMEPATH` (Windows, used together), and `HOME` is used as the |
| 149 | location of the `~/.fossil` file. |
| 150 | |
| 151 | |
| 152 | `FOSSIL_USE_SEE_TEXTKEY`: If set, treat the encryption key string for |
| 153 | SEE as text to be hashed into the actaul encryption key. This has no |
| 154 | effect if Fossil was not compiled with SEE support enabled. |
| 155 | |
| 156 | |
| 157 | `FOSSIL_USER`: Name of the default user account if the checkout, local |
| 158 | or global `default-user` setting is not present. The first environment |
| 159 |
| --- www/env-opts.md | |
| +++ www/env-opts.md | |
| @@ -148,11 +148,11 @@ | |
| 148 | `HOMEPATH` (Windows, used together), and `HOME` is used as the |
| 149 | location of the `~/.fossil` file. |
| 150 | |
| 151 | |
| 152 | `FOSSIL_USE_SEE_TEXTKEY`: If set, treat the encryption key string for |
| 153 | SEE as text to be hashed into the actual encryption key. This has no |
| 154 | effect if Fossil was not compiled with SEE support enabled. |
| 155 | |
| 156 | |
| 157 | `FOSSIL_USER`: Name of the default user account if the checkout, local |
| 158 | or global `default-user` setting is not present. The first environment |
| 159 |
+8
-8
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -171,11 +171,11 @@ | ||
| 171 | 171 | |
| 172 | 172 | Fossil, on the other hand, parses essential information about check-ins |
| 173 | 173 | (parents, children, committers, comments, files changed, etc.) |
| 174 | 174 | into a relational database that can be easily |
| 175 | 175 | queried using concise SQL statements to find both ancestors and |
| 176 | -descendents of a check-in. | |
| 176 | +descendants of a check-in. | |
| 177 | 177 | |
| 178 | 178 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 179 | 179 | difficult to locate and subject to garbage collection. This |
| 180 | 180 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 181 | 181 | state] problem has caused untold grief for countless Git users. With |
| @@ -357,11 +357,11 @@ | ||
| 357 | 357 | <li><p><b>Branch names sync:</b> Unlike in Git, branch names in |
| 358 | 358 | Fossil are not purely local labels. They sync along with everything |
| 359 | 359 | else, so everyone sees the same set of branch names. Fossil's design |
| 360 | 360 | choice here is a direct reflection of the Linux vs. SQLite project |
| 361 | 361 | outlook: SQLite's developers collaborate closely on a single |
| 362 | - conherent project, whereas Linux's developers go off on tangents and | |
| 362 | + coherent project, whereas Linux's developers go off on tangents and | |
| 363 | 363 | occasionally sync changes up with each other.</p></li> |
| 364 | 364 | |
| 365 | 365 | <li><p><b>Private branches are rare:</b> |
| 366 | 366 | [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but |
| 367 | 367 | they're normally used to handle rare exception cases, whereas in |
| @@ -468,11 +468,11 @@ | ||
| 468 | 468 | sync the entire DAG. Git commands, |
| 469 | 469 | GitHub, and GitLab tend to show only a single branch at |
| 470 | 470 | a time, whereas Fossil usually shows all parallel branches at |
| 471 | 471 | once. Git has commands like "rebase" that help keep all relevant |
| 472 | 472 | changes on a single branch, whereas Fossil encourages a style of |
| 473 | -many concurrent branches constantly springing into existance, | |
| 473 | +many concurrent branches constantly springing into existence, | |
| 474 | 474 | undergoing active development in parallel for a few days or weeks, then |
| 475 | 475 | merging back into the main line and disappearing. |
| 476 | 476 | |
| 477 | 477 | This difference in emphasis arises from the different purposes of |
| 478 | 478 | the two systems. Git focuses on individual branches, because that |
| @@ -569,11 +569,11 @@ | ||
| 569 | 569 | |
| 570 | 570 | Here in mid-2019, that feature is now in every OS and package repository |
| 571 | 571 | known to include Fossil so that the next release as of this writing |
| 572 | 572 | (Fossil 2.10) will default to enforcing SHA-3 hashes by default. This |
| 573 | 573 | not only solves the SHAttered problem, it should prevent a reoccurrence |
| 574 | -for the forseeable future. Only repositories created before the | |
| 574 | +for the foreseeable future. Only repositories created before the | |
| 575 | 575 | transition to Fossil 2 are still using SHA-1, and then only if the |
| 576 | 576 | repository's maintainer chose not to switch them into SHA-3 mode some |
| 577 | 577 | time over the past 2 years. |
| 578 | 578 | |
| 579 | 579 | Meanwhile, the Git community took until August 2018 to announce |
| @@ -581,11 +581,11 @@ | ||
| 581 | 581 | for solving the same problem by moving to SHA-256 (a variant of the |
| 582 | 582 | [https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until |
| 583 | 583 | February 2019 to release a version containing the change. It's looking |
| 584 | 584 | like this will take years more to percolate through the community. |
| 585 | 585 | |
| 586 | -The practical impact of SHAttered on structred data stores like the one | |
| 586 | +The practical impact of SHAttered on structured data stores like the one | |
| 587 | 587 | in Git and Fossil isn't clear, but you want to have your repositories |
| 588 | 588 | moved over to a stronger hash algorithm before someone figures out how |
| 589 | 589 | to make use of the weaknesses in the old one. Fossil's developers moved |
| 590 | 590 | on this problem quickly and had a widely-deployed solution to it years |
| 591 | 591 | ago. |
| @@ -630,11 +630,11 @@ | ||
| 630 | 630 | * <b>Rebase</b> |
| 631 | 631 | |
| 632 | 632 | Because of its emphasis on recording history exactly as it happened, |
| 633 | 633 | rather than as we would have liked it to happen, Fossil deliberately |
| 634 | 634 | does not provide a "rebase" command. One can rebase manually in Fossil, |
| 635 | - with sufficient perserverence, but it is not something that can be done with | |
| 635 | + with sufficient perseverance, but it is not something that can be done with | |
| 636 | 636 | a single command. |
| 637 | 637 | |
| 638 | 638 | * <b>Push or pull a single branch</b> |
| 639 | 639 | |
| 640 | 640 | The [/help?cmd=push|fossil push], [/help?cmd=pull|fossil pull], and |
| @@ -678,10 +678,10 @@ | ||
| 678 | 678 | |
| 679 | 679 | <li><p>Both Fossil and Git support |
| 680 | 680 | [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt> |
| 681 | 681 | files], a common way to allow drive-by contributions, but it's a |
| 682 | 682 | lossy contribution path for both systems. Unlike Git PRs and Fossil |
| 683 | - bundles, patch files collapse mulitple checkins together, they don't | |
| 683 | + bundles, patch files collapse multiple checkins together, they don't | |
| 684 | 684 | include check-in comments, and they cannot encode changes made above |
| 685 | - the individual file content layer: you lose branching decisisions, | |
| 685 | + the individual file content layer: you lose branching decisions, | |
| 686 | 686 | tag changes, file renames, and more when using patch files.</p></li> |
| 687 | 687 | </ol></i></small> |
| 688 | 688 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -171,11 +171,11 @@ | |
| 171 | |
| 172 | Fossil, on the other hand, parses essential information about check-ins |
| 173 | (parents, children, committers, comments, files changed, etc.) |
| 174 | into a relational database that can be easily |
| 175 | queried using concise SQL statements to find both ancestors and |
| 176 | descendents of a check-in. |
| 177 | |
| 178 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 179 | difficult to locate and subject to garbage collection. This |
| 180 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 181 | state] problem has caused untold grief for countless Git users. With |
| @@ -357,11 +357,11 @@ | |
| 357 | <li><p><b>Branch names sync:</b> Unlike in Git, branch names in |
| 358 | Fossil are not purely local labels. They sync along with everything |
| 359 | else, so everyone sees the same set of branch names. Fossil's design |
| 360 | choice here is a direct reflection of the Linux vs. SQLite project |
| 361 | outlook: SQLite's developers collaborate closely on a single |
| 362 | conherent project, whereas Linux's developers go off on tangents and |
| 363 | occasionally sync changes up with each other.</p></li> |
| 364 | |
| 365 | <li><p><b>Private branches are rare:</b> |
| 366 | [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but |
| 367 | they're normally used to handle rare exception cases, whereas in |
| @@ -468,11 +468,11 @@ | |
| 468 | sync the entire DAG. Git commands, |
| 469 | GitHub, and GitLab tend to show only a single branch at |
| 470 | a time, whereas Fossil usually shows all parallel branches at |
| 471 | once. Git has commands like "rebase" that help keep all relevant |
| 472 | changes on a single branch, whereas Fossil encourages a style of |
| 473 | many concurrent branches constantly springing into existance, |
| 474 | undergoing active development in parallel for a few days or weeks, then |
| 475 | merging back into the main line and disappearing. |
| 476 | |
| 477 | This difference in emphasis arises from the different purposes of |
| 478 | the two systems. Git focuses on individual branches, because that |
| @@ -569,11 +569,11 @@ | |
| 569 | |
| 570 | Here in mid-2019, that feature is now in every OS and package repository |
| 571 | known to include Fossil so that the next release as of this writing |
| 572 | (Fossil 2.10) will default to enforcing SHA-3 hashes by default. This |
| 573 | not only solves the SHAttered problem, it should prevent a reoccurrence |
| 574 | for the forseeable future. Only repositories created before the |
| 575 | transition to Fossil 2 are still using SHA-1, and then only if the |
| 576 | repository's maintainer chose not to switch them into SHA-3 mode some |
| 577 | time over the past 2 years. |
| 578 | |
| 579 | Meanwhile, the Git community took until August 2018 to announce |
| @@ -581,11 +581,11 @@ | |
| 581 | for solving the same problem by moving to SHA-256 (a variant of the |
| 582 | [https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until |
| 583 | February 2019 to release a version containing the change. It's looking |
| 584 | like this will take years more to percolate through the community. |
| 585 | |
| 586 | The practical impact of SHAttered on structred data stores like the one |
| 587 | in Git and Fossil isn't clear, but you want to have your repositories |
| 588 | moved over to a stronger hash algorithm before someone figures out how |
| 589 | to make use of the weaknesses in the old one. Fossil's developers moved |
| 590 | on this problem quickly and had a widely-deployed solution to it years |
| 591 | ago. |
| @@ -630,11 +630,11 @@ | |
| 630 | * <b>Rebase</b> |
| 631 | |
| 632 | Because of its emphasis on recording history exactly as it happened, |
| 633 | rather than as we would have liked it to happen, Fossil deliberately |
| 634 | does not provide a "rebase" command. One can rebase manually in Fossil, |
| 635 | with sufficient perserverence, but it is not something that can be done with |
| 636 | a single command. |
| 637 | |
| 638 | * <b>Push or pull a single branch</b> |
| 639 | |
| 640 | The [/help?cmd=push|fossil push], [/help?cmd=pull|fossil pull], and |
| @@ -678,10 +678,10 @@ | |
| 678 | |
| 679 | <li><p>Both Fossil and Git support |
| 680 | [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt> |
| 681 | files], a common way to allow drive-by contributions, but it's a |
| 682 | lossy contribution path for both systems. Unlike Git PRs and Fossil |
| 683 | bundles, patch files collapse mulitple checkins together, they don't |
| 684 | include check-in comments, and they cannot encode changes made above |
| 685 | the individual file content layer: you lose branching decisisions, |
| 686 | tag changes, file renames, and more when using patch files.</p></li> |
| 687 | </ol></i></small> |
| 688 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -171,11 +171,11 @@ | |
| 171 | |
| 172 | Fossil, on the other hand, parses essential information about check-ins |
| 173 | (parents, children, committers, comments, files changed, etc.) |
| 174 | into a relational database that can be easily |
| 175 | queried using concise SQL statements to find both ancestors and |
| 176 | descendants of a check-in. |
| 177 | |
| 178 | Leaf check-ins in Git that lack a "ref" become "detached," making them |
| 179 | difficult to locate and subject to garbage collection. This |
| 180 | [http://gitfaq.org/articles/what-is-a-detached-head.html|detached head |
| 181 | state] problem has caused untold grief for countless Git users. With |
| @@ -357,11 +357,11 @@ | |
| 357 | <li><p><b>Branch names sync:</b> Unlike in Git, branch names in |
| 358 | Fossil are not purely local labels. They sync along with everything |
| 359 | else, so everyone sees the same set of branch names. Fossil's design |
| 360 | choice here is a direct reflection of the Linux vs. SQLite project |
| 361 | outlook: SQLite's developers collaborate closely on a single |
| 362 | coherent project, whereas Linux's developers go off on tangents and |
| 363 | occasionally sync changes up with each other.</p></li> |
| 364 | |
| 365 | <li><p><b>Private branches are rare:</b> |
| 366 | [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but |
| 367 | they're normally used to handle rare exception cases, whereas in |
| @@ -468,11 +468,11 @@ | |
| 468 | sync the entire DAG. Git commands, |
| 469 | GitHub, and GitLab tend to show only a single branch at |
| 470 | a time, whereas Fossil usually shows all parallel branches at |
| 471 | once. Git has commands like "rebase" that help keep all relevant |
| 472 | changes on a single branch, whereas Fossil encourages a style of |
| 473 | many concurrent branches constantly springing into existence, |
| 474 | undergoing active development in parallel for a few days or weeks, then |
| 475 | merging back into the main line and disappearing. |
| 476 | |
| 477 | This difference in emphasis arises from the different purposes of |
| 478 | the two systems. Git focuses on individual branches, because that |
| @@ -569,11 +569,11 @@ | |
| 569 | |
| 570 | Here in mid-2019, that feature is now in every OS and package repository |
| 571 | known to include Fossil so that the next release as of this writing |
| 572 | (Fossil 2.10) will default to enforcing SHA-3 hashes by default. This |
| 573 | not only solves the SHAttered problem, it should prevent a reoccurrence |
| 574 | for the foreseeable future. Only repositories created before the |
| 575 | transition to Fossil 2 are still using SHA-1, and then only if the |
| 576 | repository's maintainer chose not to switch them into SHA-3 mode some |
| 577 | time over the past 2 years. |
| 578 | |
| 579 | Meanwhile, the Git community took until August 2018 to announce |
| @@ -581,11 +581,11 @@ | |
| 581 | for solving the same problem by moving to SHA-256 (a variant of the |
| 582 | [https://en.wikipedia.org/wiki/SHA-2|older SHA-2 algorithm]) and until |
| 583 | February 2019 to release a version containing the change. It's looking |
| 584 | like this will take years more to percolate through the community. |
| 585 | |
| 586 | The practical impact of SHAttered on structured data stores like the one |
| 587 | in Git and Fossil isn't clear, but you want to have your repositories |
| 588 | moved over to a stronger hash algorithm before someone figures out how |
| 589 | to make use of the weaknesses in the old one. Fossil's developers moved |
| 590 | on this problem quickly and had a widely-deployed solution to it years |
| 591 | ago. |
| @@ -630,11 +630,11 @@ | |
| 630 | * <b>Rebase</b> |
| 631 | |
| 632 | Because of its emphasis on recording history exactly as it happened, |
| 633 | rather than as we would have liked it to happen, Fossil deliberately |
| 634 | does not provide a "rebase" command. One can rebase manually in Fossil, |
| 635 | with sufficient perseverance, but it is not something that can be done with |
| 636 | a single command. |
| 637 | |
| 638 | * <b>Push or pull a single branch</b> |
| 639 | |
| 640 | The [/help?cmd=push|fossil push], [/help?cmd=pull|fossil pull], and |
| @@ -678,10 +678,10 @@ | |
| 678 | |
| 679 | <li><p>Both Fossil and Git support |
| 680 | [https://en.wikipedia.org/wiki/Patch_(Unix)|<tt>patch(1)</tt> |
| 681 | files], a common way to allow drive-by contributions, but it's a |
| 682 | lossy contribution path for both systems. Unlike Git PRs and Fossil |
| 683 | bundles, patch files collapse multiple checkins together, they don't |
| 684 | include check-in comments, and they cannot encode changes made above |
| 685 | the individual file content layer: you lose branching decisions, |
| 686 | tag changes, file renames, and more when using patch files.</p></li> |
| 687 | </ol></i></small> |
| 688 |
+1
-1
| --- www/hashpolicy.wiki | ||
| +++ www/hashpolicy.wiki | ||
| @@ -112,11 +112,11 @@ | ||
| 112 | 112 | </tr> |
| 113 | 113 | <tr> |
| 114 | 114 | <td valign='top'>sha3-only</td> |
| 115 | 115 | <td>Name new artifacts using the SHA3 hash algorithm even if the artifact |
| 116 | 116 | already has a SHA1 name. In other words, force the use of SHA3. This can |
| 117 | -cause some artifacts to be added to the respository twice, once under their | |
| 117 | +cause some artifacts to be added to the repository twice, once under their | |
| 118 | 118 | SHA1 name and again under their SHA3 name. But delta compression will |
| 119 | 119 | prevent that from causing repository size problems.</td> |
| 120 | 120 | </tr> |
| 121 | 121 | <tr> |
| 122 | 122 | <td valign='top'>shun-sha1</td> |
| 123 | 123 |
| --- www/hashpolicy.wiki | |
| +++ www/hashpolicy.wiki | |
| @@ -112,11 +112,11 @@ | |
| 112 | </tr> |
| 113 | <tr> |
| 114 | <td valign='top'>sha3-only</td> |
| 115 | <td>Name new artifacts using the SHA3 hash algorithm even if the artifact |
| 116 | already has a SHA1 name. In other words, force the use of SHA3. This can |
| 117 | cause some artifacts to be added to the respository twice, once under their |
| 118 | SHA1 name and again under their SHA3 name. But delta compression will |
| 119 | prevent that from causing repository size problems.</td> |
| 120 | </tr> |
| 121 | <tr> |
| 122 | <td valign='top'>shun-sha1</td> |
| 123 |
| --- www/hashpolicy.wiki | |
| +++ www/hashpolicy.wiki | |
| @@ -112,11 +112,11 @@ | |
| 112 | </tr> |
| 113 | <tr> |
| 114 | <td valign='top'>sha3-only</td> |
| 115 | <td>Name new artifacts using the SHA3 hash algorithm even if the artifact |
| 116 | already has a SHA1 name. In other words, force the use of SHA3. This can |
| 117 | cause some artifacts to be added to the repository twice, once under their |
| 118 | SHA1 name and again under their SHA3 name. But delta compression will |
| 119 | prevent that from causing repository size problems.</td> |
| 120 | </tr> |
| 121 | <tr> |
| 122 | <td valign='top'>shun-sha1</td> |
| 123 |
+3
-3
| --- www/image-format-vs-repo-size.md | ||
| +++ www/image-format-vs-repo-size.md | ||
| @@ -106,11 +106,11 @@ | ||
| 106 | 106 | modify the notebook to try different things. Want to see how the |
| 107 | 107 | results change with a different image size? Easy, change the `size` |
| 108 | 108 | value in the second cell of the notebook. Want to try more image |
| 109 | 109 | formats? You can put anything ImageMagick can recognize into the |
| 110 | 110 | `formats` list. Want to find the break-even point for images like those |
| 111 | -in your own respository? Easily done with a small amount of code. | |
| 111 | +in your own repository? Easily done with a small amount of code. | |
| 112 | 112 | |
| 113 | 113 | [im]: https://www.imagemagick.org/ |
| 114 | 114 | [jp]: https://jupyter.org/ |
| 115 | 115 | [nbd]: ./image-format-vs-repo-size.ipynb |
| 116 | 116 | [nbp]: https://nbviewer.jupyter.org/urls/fossil-scm.org/fossil/doc/trunk/www/image-format-vs-repo-size.ipynb |
| @@ -201,11 +201,11 @@ | ||
| 201 | 201 | doesn’t need to be run by hand. |
| 202 | 202 | |
| 203 | 203 | This `Makefile` illustrates two primary strategies: |
| 204 | 204 | |
| 205 | 205 | |
| 206 | -### Input and Ouput File Formats Differ by Extension | |
| 206 | +### Input and Output File Formats Differ by Extension | |
| 207 | 207 | |
| 208 | 208 | In the case of SVG and the bitmap image formats, the file name extension |
| 209 | 209 | differs between the cases, so we can use `make` suffix rules to get the |
| 210 | 210 | behavior we want. The top half of the `Makefile` just tells `make` how |
| 211 | 211 | to map from `*.svg` to `*.svgz` and vice versa, and the same for `*.bmp` |
| @@ -256,11 +256,11 @@ | ||
| 256 | 256 | PNG, which is always zlib-compressed. |
| 257 | 257 | |
| 258 | 258 | 4. The raw data changes somewhat from one run to the next due to the |
| 259 | 259 | use of random noise in the image to make the zlib/PNG compression |
| 260 | 260 | more difficult, and the random pixel changes. Those test design |
| 261 | - choices make this a [Monte Carlo experient][mce]. We’ve found that | |
| 261 | + choices make this a [Monte Carlo experiment][mce]. We’ve found that | |
| 262 | 262 | the overall character of the results doesn’t change from one run to |
| 263 | 263 | the next. |
| 264 | 264 | |
| 265 | 265 | The code in the notebook’s third cell drops the first three columns |
| 266 | 266 | of data because the first column (the empty repository size) is |
| 267 | 267 |
| --- www/image-format-vs-repo-size.md | |
| +++ www/image-format-vs-repo-size.md | |
| @@ -106,11 +106,11 @@ | |
| 106 | modify the notebook to try different things. Want to see how the |
| 107 | results change with a different image size? Easy, change the `size` |
| 108 | value in the second cell of the notebook. Want to try more image |
| 109 | formats? You can put anything ImageMagick can recognize into the |
| 110 | `formats` list. Want to find the break-even point for images like those |
| 111 | in your own respository? Easily done with a small amount of code. |
| 112 | |
| 113 | [im]: https://www.imagemagick.org/ |
| 114 | [jp]: https://jupyter.org/ |
| 115 | [nbd]: ./image-format-vs-repo-size.ipynb |
| 116 | [nbp]: https://nbviewer.jupyter.org/urls/fossil-scm.org/fossil/doc/trunk/www/image-format-vs-repo-size.ipynb |
| @@ -201,11 +201,11 @@ | |
| 201 | doesn’t need to be run by hand. |
| 202 | |
| 203 | This `Makefile` illustrates two primary strategies: |
| 204 | |
| 205 | |
| 206 | ### Input and Ouput File Formats Differ by Extension |
| 207 | |
| 208 | In the case of SVG and the bitmap image formats, the file name extension |
| 209 | differs between the cases, so we can use `make` suffix rules to get the |
| 210 | behavior we want. The top half of the `Makefile` just tells `make` how |
| 211 | to map from `*.svg` to `*.svgz` and vice versa, and the same for `*.bmp` |
| @@ -256,11 +256,11 @@ | |
| 256 | PNG, which is always zlib-compressed. |
| 257 | |
| 258 | 4. The raw data changes somewhat from one run to the next due to the |
| 259 | use of random noise in the image to make the zlib/PNG compression |
| 260 | more difficult, and the random pixel changes. Those test design |
| 261 | choices make this a [Monte Carlo experient][mce]. We’ve found that |
| 262 | the overall character of the results doesn’t change from one run to |
| 263 | the next. |
| 264 | |
| 265 | The code in the notebook’s third cell drops the first three columns |
| 266 | of data because the first column (the empty repository size) is |
| 267 |
| --- www/image-format-vs-repo-size.md | |
| +++ www/image-format-vs-repo-size.md | |
| @@ -106,11 +106,11 @@ | |
| 106 | modify the notebook to try different things. Want to see how the |
| 107 | results change with a different image size? Easy, change the `size` |
| 108 | value in the second cell of the notebook. Want to try more image |
| 109 | formats? You can put anything ImageMagick can recognize into the |
| 110 | `formats` list. Want to find the break-even point for images like those |
| 111 | in your own repository? Easily done with a small amount of code. |
| 112 | |
| 113 | [im]: https://www.imagemagick.org/ |
| 114 | [jp]: https://jupyter.org/ |
| 115 | [nbd]: ./image-format-vs-repo-size.ipynb |
| 116 | [nbp]: https://nbviewer.jupyter.org/urls/fossil-scm.org/fossil/doc/trunk/www/image-format-vs-repo-size.ipynb |
| @@ -201,11 +201,11 @@ | |
| 201 | doesn’t need to be run by hand. |
| 202 | |
| 203 | This `Makefile` illustrates two primary strategies: |
| 204 | |
| 205 | |
| 206 | ### Input and Output File Formats Differ by Extension |
| 207 | |
| 208 | In the case of SVG and the bitmap image formats, the file name extension |
| 209 | differs between the cases, so we can use `make` suffix rules to get the |
| 210 | behavior we want. The top half of the `Makefile` just tells `make` how |
| 211 | to map from `*.svg` to `*.svgz` and vice versa, and the same for `*.bmp` |
| @@ -256,11 +256,11 @@ | |
| 256 | PNG, which is always zlib-compressed. |
| 257 | |
| 258 | 4. The raw data changes somewhat from one run to the next due to the |
| 259 | use of random noise in the image to make the zlib/PNG compression |
| 260 | more difficult, and the random pixel changes. Those test design |
| 261 | choices make this a [Monte Carlo experiment][mce]. We’ve found that |
| 262 | the overall character of the results doesn’t change from one run to |
| 263 | the next. |
| 264 | |
| 265 | The code in the notebook’s third cell drops the first three columns |
| 266 | of data because the first column (the empty repository size) is |
| 267 |
+2
-2
| --- www/mirrorlimitations.md | ||
| +++ www/mirrorlimitations.md | ||
| @@ -14,11 +14,11 @@ | ||
| 14 | 14 | as Wiki, Tickets, Technotes, and the Forum are not supported in Git and |
| 15 | 15 | so those features are not included in an export. |
| 16 | 16 | |
| 17 | 17 | ## (2) Cherrypick Merges |
| 18 | 18 | |
| 19 | -The Git client supports cherrypick mergs but does not remember them. | |
| 19 | +The Git client supports cherrypick merges but does not remember them. | |
| 20 | 20 | In other words, Git does not record a history of cherrypick merges |
| 21 | 21 | in its blockchain. |
| 22 | 22 | |
| 23 | 23 | Fossil tracks cherrypick merges in its blockchain and display cherrypicks |
| 24 | 24 | (as dashed lines) in its timeline ([example](/timeline?c=0a9f12ce6655b7a5)). |
| @@ -30,11 +30,11 @@ | ||
| 30 | 30 | Git has only limited support for named branches. Git identifies the head |
| 31 | 31 | check-in of each branch. Depending on the check-in graph topology, this |
| 32 | 32 | is sufficient to infer the branch for many historical check-ins as well. |
| 33 | 33 | However, complex histories with lots of cross-merging |
| 34 | 34 | can lead to ambiguities. Fossil keeps |
| 35 | -track of historical branch names unambigously. | |
| 35 | +track of historical branch names unambiguously. | |
| 36 | 36 | But the extra details about branch names that Fossil keeps |
| 37 | 37 | at hand cannot be exported to Git. |
| 38 | 38 | |
| 39 | 39 | ## (4) Non-unique Tags |
| 40 | 40 | |
| 41 | 41 |
| --- www/mirrorlimitations.md | |
| +++ www/mirrorlimitations.md | |
| @@ -14,11 +14,11 @@ | |
| 14 | as Wiki, Tickets, Technotes, and the Forum are not supported in Git and |
| 15 | so those features are not included in an export. |
| 16 | |
| 17 | ## (2) Cherrypick Merges |
| 18 | |
| 19 | The Git client supports cherrypick mergs but does not remember them. |
| 20 | In other words, Git does not record a history of cherrypick merges |
| 21 | in its blockchain. |
| 22 | |
| 23 | Fossil tracks cherrypick merges in its blockchain and display cherrypicks |
| 24 | (as dashed lines) in its timeline ([example](/timeline?c=0a9f12ce6655b7a5)). |
| @@ -30,11 +30,11 @@ | |
| 30 | Git has only limited support for named branches. Git identifies the head |
| 31 | check-in of each branch. Depending on the check-in graph topology, this |
| 32 | is sufficient to infer the branch for many historical check-ins as well. |
| 33 | However, complex histories with lots of cross-merging |
| 34 | can lead to ambiguities. Fossil keeps |
| 35 | track of historical branch names unambigously. |
| 36 | But the extra details about branch names that Fossil keeps |
| 37 | at hand cannot be exported to Git. |
| 38 | |
| 39 | ## (4) Non-unique Tags |
| 40 | |
| 41 |
| --- www/mirrorlimitations.md | |
| +++ www/mirrorlimitations.md | |
| @@ -14,11 +14,11 @@ | |
| 14 | as Wiki, Tickets, Technotes, and the Forum are not supported in Git and |
| 15 | so those features are not included in an export. |
| 16 | |
| 17 | ## (2) Cherrypick Merges |
| 18 | |
| 19 | The Git client supports cherrypick merges but does not remember them. |
| 20 | In other words, Git does not record a history of cherrypick merges |
| 21 | in its blockchain. |
| 22 | |
| 23 | Fossil tracks cherrypick merges in its blockchain and display cherrypicks |
| 24 | (as dashed lines) in its timeline ([example](/timeline?c=0a9f12ce6655b7a5)). |
| @@ -30,11 +30,11 @@ | |
| 30 | Git has only limited support for named branches. Git identifies the head |
| 31 | check-in of each branch. Depending on the check-in graph topology, this |
| 32 | is sufficient to infer the branch for many historical check-ins as well. |
| 33 | However, complex histories with lots of cross-merging |
| 34 | can lead to ambiguities. Fossil keeps |
| 35 | track of historical branch names unambiguously. |
| 36 | But the extra details about branch names that Fossil keeps |
| 37 | at hand cannot be exported to Git. |
| 38 | |
| 39 | ## (4) Non-unique Tags |
| 40 | |
| 41 |
+1
-1
| --- www/password.wiki | ||
| +++ www/password.wiki | ||
| @@ -73,11 +73,11 @@ | ||
| 73 | 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | 76 | of the USER table on the server. |
| 77 | 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | -for the cookie, encoded as a julian day number. On all subsequent | |
| 78 | +for the cookie, encoded as a Julian day number. On all subsequent | |
| 79 | 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | 80 | enable access to the repository. |
| 81 | 81 | |
| 82 | 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 | 84 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -73,11 +73,11 @@ | |
| 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | of the USER table on the server. |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -73,11 +73,11 @@ | |
| 73 | login. This cookie contains a large amount of high-quality randomness |
| 74 | and is thus intractable to guess. The value of the cookie and the IP |
| 75 | address of the client is stored in the USER.COOKIE and USER.IPADDR fields |
| 76 | of the USER table on the server. |
| 77 | The USER.CEXPIRE field holds an expiration date |
| 78 | for the cookie, encoded as a Julian day number. On all subsequent |
| 79 | HTTP requests, the cookie value is matched against the USER table to |
| 80 | enable access to the repository. |
| 81 | |
| 82 | A login cookie will only work if the IP address matches. This feature |
| 83 | is designed to make it more difficult for an attacker to sniff the cookie |
| 84 |
+4
-4
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -83,11 +83,11 @@ | ||
| 83 | 83 | <h4>2.0.1 Encrypted Transport</h4> |
| 84 | 84 | |
| 85 | 85 | <p>In the current implementation of Fossil, the server only |
| 86 | 86 | understands HTTP requests. The client can send either |
| 87 | 87 | clear-text HTTP requests or encrypted HTTPS requests. But when |
| 88 | -HTTPS requests are sent, they first must be decrypted by a webserver | |
| 88 | +HTTPS requests are sent, they first must be decrypted by a web server | |
| 89 | 89 | or proxy before being passed to the Fossil server. This limitation |
| 90 | 90 | may be relaxed in a future release.</p> |
| 91 | 91 | |
| 92 | 92 | <h3>2.1 Server Identification</h3> |
| 93 | 93 | |
| @@ -448,11 +448,11 @@ | ||
| 448 | 448 | The server might also send a uvigot card when it receives a uvgimme card |
| 449 | 449 | but its reply message size is already oversized and hence unable to hold |
| 450 | 450 | the usual uvfile reply. |
| 451 | 451 | |
| 452 | 452 | <p>When a client receives a "uvigot" card, it checks to see if the |
| 453 | -file needs to be transfered from client to server or from server to client. | |
| 453 | +file needs to be transferred from client to server or from server to client. | |
| 454 | 454 | If a client-to-server transmission is needed, the client schedules that |
| 455 | 455 | transfer to occur on a subsequent HTTP request. If a server-to-client |
| 456 | 456 | transfer is needed, then the client sends a "uvgimme" card back to the |
| 457 | 457 | server to request the file content. |
| 458 | 458 | |
| @@ -689,20 +689,20 @@ | ||
| 689 | 689 | |
| 690 | 690 | <li><p><b>uv-pull-only</b></i> |
| 691 | 691 | <p>A server sends the uv-pull-only pragma to the client in response |
| 692 | 692 | to a uv-hash pragma with a mismatched content hash argument. This |
| 693 | 693 | pragma indicates that there are differences in unversioned content |
| 694 | -between the client and server but that content can only be transfered | |
| 694 | +between the client and server but that content can only be transferred | |
| 695 | 695 | from server to client. The server is unwilling to accept content from |
| 696 | 696 | the client because the client login lacks the "write-unversioned" |
| 697 | 697 | permission.</p> |
| 698 | 698 | |
| 699 | 699 | <li><p><b>uv-push-ok</b></i> |
| 700 | 700 | <p>A server sends the uv-push-ok pragma to the client in response |
| 701 | 701 | to a uv-hash pragma with a mismatched content hash argument. This |
| 702 | 702 | pragma indicates that there are differences in unversioned content |
| 703 | -between the client and server and that content can only be transfered | |
| 703 | +between the client and server and that content can only be transferred | |
| 704 | 704 | in either direction. The server is willing to accept content from |
| 705 | 705 | the client because the client login has the "write-unversioned" |
| 706 | 706 | permission.</p> |
| 707 | 707 | |
| 708 | 708 | <li><p><b>ci-lock</b> <i>CHECKIN-HASH CLIENT-ID</i></p> |
| 709 | 709 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -83,11 +83,11 @@ | |
| 83 | <h4>2.0.1 Encrypted Transport</h4> |
| 84 | |
| 85 | <p>In the current implementation of Fossil, the server only |
| 86 | understands HTTP requests. The client can send either |
| 87 | clear-text HTTP requests or encrypted HTTPS requests. But when |
| 88 | HTTPS requests are sent, they first must be decrypted by a webserver |
| 89 | or proxy before being passed to the Fossil server. This limitation |
| 90 | may be relaxed in a future release.</p> |
| 91 | |
| 92 | <h3>2.1 Server Identification</h3> |
| 93 | |
| @@ -448,11 +448,11 @@ | |
| 448 | The server might also send a uvigot card when it receives a uvgimme card |
| 449 | but its reply message size is already oversized and hence unable to hold |
| 450 | the usual uvfile reply. |
| 451 | |
| 452 | <p>When a client receives a "uvigot" card, it checks to see if the |
| 453 | file needs to be transfered from client to server or from server to client. |
| 454 | If a client-to-server transmission is needed, the client schedules that |
| 455 | transfer to occur on a subsequent HTTP request. If a server-to-client |
| 456 | transfer is needed, then the client sends a "uvgimme" card back to the |
| 457 | server to request the file content. |
| 458 | |
| @@ -689,20 +689,20 @@ | |
| 689 | |
| 690 | <li><p><b>uv-pull-only</b></i> |
| 691 | <p>A server sends the uv-pull-only pragma to the client in response |
| 692 | to a uv-hash pragma with a mismatched content hash argument. This |
| 693 | pragma indicates that there are differences in unversioned content |
| 694 | between the client and server but that content can only be transfered |
| 695 | from server to client. The server is unwilling to accept content from |
| 696 | the client because the client login lacks the "write-unversioned" |
| 697 | permission.</p> |
| 698 | |
| 699 | <li><p><b>uv-push-ok</b></i> |
| 700 | <p>A server sends the uv-push-ok pragma to the client in response |
| 701 | to a uv-hash pragma with a mismatched content hash argument. This |
| 702 | pragma indicates that there are differences in unversioned content |
| 703 | between the client and server and that content can only be transfered |
| 704 | in either direction. The server is willing to accept content from |
| 705 | the client because the client login has the "write-unversioned" |
| 706 | permission.</p> |
| 707 | |
| 708 | <li><p><b>ci-lock</b> <i>CHECKIN-HASH CLIENT-ID</i></p> |
| 709 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -83,11 +83,11 @@ | |
| 83 | <h4>2.0.1 Encrypted Transport</h4> |
| 84 | |
| 85 | <p>In the current implementation of Fossil, the server only |
| 86 | understands HTTP requests. The client can send either |
| 87 | clear-text HTTP requests or encrypted HTTPS requests. But when |
| 88 | HTTPS requests are sent, they first must be decrypted by a web server |
| 89 | or proxy before being passed to the Fossil server. This limitation |
| 90 | may be relaxed in a future release.</p> |
| 91 | |
| 92 | <h3>2.1 Server Identification</h3> |
| 93 | |
| @@ -448,11 +448,11 @@ | |
| 448 | The server might also send a uvigot card when it receives a uvgimme card |
| 449 | but its reply message size is already oversized and hence unable to hold |
| 450 | the usual uvfile reply. |
| 451 | |
| 452 | <p>When a client receives a "uvigot" card, it checks to see if the |
| 453 | file needs to be transferred from client to server or from server to client. |
| 454 | If a client-to-server transmission is needed, the client schedules that |
| 455 | transfer to occur on a subsequent HTTP request. If a server-to-client |
| 456 | transfer is needed, then the client sends a "uvgimme" card back to the |
| 457 | server to request the file content. |
| 458 | |
| @@ -689,20 +689,20 @@ | |
| 689 | |
| 690 | <li><p><b>uv-pull-only</b></i> |
| 691 | <p>A server sends the uv-pull-only pragma to the client in response |
| 692 | to a uv-hash pragma with a mismatched content hash argument. This |
| 693 | pragma indicates that there are differences in unversioned content |
| 694 | between the client and server but that content can only be transferred |
| 695 | from server to client. The server is unwilling to accept content from |
| 696 | the client because the client login lacks the "write-unversioned" |
| 697 | permission.</p> |
| 698 | |
| 699 | <li><p><b>uv-push-ok</b></i> |
| 700 | <p>A server sends the uv-push-ok pragma to the client in response |
| 701 | to a uv-hash pragma with a mismatched content hash argument. This |
| 702 | pragma indicates that there are differences in unversioned content |
| 703 | between the client and server and that content can only be transferred |
| 704 | in either direction. The server is willing to accept content from |
| 705 | the client because the client login has the "write-unversioned" |
| 706 | permission.</p> |
| 707 | |
| 708 | <li><p><b>ci-lock</b> <i>CHECKIN-HASH CLIENT-ID</i></p> |
| 709 |
+3
-3
| --- www/tls-nginx.md | ||
| +++ www/tls-nginx.md | ||
| @@ -371,11 +371,11 @@ | ||
| 371 | 371 | but also because it might need to work after a certificate is |
| 372 | 372 | accidentally allowed to lapse, to get that server back into a state |
| 373 | 373 | where it can speak HTTPS safely again. |
| 374 | 374 | |
| 375 | 375 | So, from the second `service { }` block, we include this file to set up |
| 376 | -the minimal HTTP service we reqiure, `local/http-certbot-only`: | |
| 376 | +the minimal HTTP service we require, `local/http-certbot-only`: | |
| 377 | 377 | |
| 378 | 378 | listen 80; |
| 379 | 379 | listen [::]:80; |
| 380 | 380 | |
| 381 | 381 | # This is expressed as a rewrite rule instead of an "if" because |
| @@ -410,17 +410,17 @@ | ||
| 410 | 410 | |
| 411 | 411 | root /var/www/$host; |
| 412 | 412 | access_log /var/log/nginx/$host-http-access.log; |
| 413 | 413 | error_log /var/log/nginx/$host-http-error.log; |
| 414 | 414 | |
| 415 | -Sadly, nginx doesn’t allow variable subtitution into these particular | |
| 415 | +Sadly, nginx doesn’t allow variable substitution into these particular | |
| 416 | 416 | directives. As I understand it, allowing that would make nginx slower, |
| 417 | 417 | so we must largely repeat these directives in each HTTP `server { }` |
| 418 | 418 | block. |
| 419 | 419 | |
| 420 | 420 | These configurations are, as shown, as small as I know how to get them. |
| 421 | -If you know of a way to reduce some of this repitition, [I solicit your | |
| 421 | +If you know of a way to reduce some of this repetition, [I solicit your | |
| 422 | 422 | advice][fd]. |
| 423 | 423 | |
| 424 | 424 | |
| 425 | 425 | ## Step 3: Dry Run |
| 426 | 426 | |
| 427 | 427 |
| --- www/tls-nginx.md | |
| +++ www/tls-nginx.md | |
| @@ -371,11 +371,11 @@ | |
| 371 | but also because it might need to work after a certificate is |
| 372 | accidentally allowed to lapse, to get that server back into a state |
| 373 | where it can speak HTTPS safely again. |
| 374 | |
| 375 | So, from the second `service { }` block, we include this file to set up |
| 376 | the minimal HTTP service we reqiure, `local/http-certbot-only`: |
| 377 | |
| 378 | listen 80; |
| 379 | listen [::]:80; |
| 380 | |
| 381 | # This is expressed as a rewrite rule instead of an "if" because |
| @@ -410,17 +410,17 @@ | |
| 410 | |
| 411 | root /var/www/$host; |
| 412 | access_log /var/log/nginx/$host-http-access.log; |
| 413 | error_log /var/log/nginx/$host-http-error.log; |
| 414 | |
| 415 | Sadly, nginx doesn’t allow variable subtitution into these particular |
| 416 | directives. As I understand it, allowing that would make nginx slower, |
| 417 | so we must largely repeat these directives in each HTTP `server { }` |
| 418 | block. |
| 419 | |
| 420 | These configurations are, as shown, as small as I know how to get them. |
| 421 | If you know of a way to reduce some of this repitition, [I solicit your |
| 422 | advice][fd]. |
| 423 | |
| 424 | |
| 425 | ## Step 3: Dry Run |
| 426 | |
| 427 |
| --- www/tls-nginx.md | |
| +++ www/tls-nginx.md | |
| @@ -371,11 +371,11 @@ | |
| 371 | but also because it might need to work after a certificate is |
| 372 | accidentally allowed to lapse, to get that server back into a state |
| 373 | where it can speak HTTPS safely again. |
| 374 | |
| 375 | So, from the second `service { }` block, we include this file to set up |
| 376 | the minimal HTTP service we require, `local/http-certbot-only`: |
| 377 | |
| 378 | listen 80; |
| 379 | listen [::]:80; |
| 380 | |
| 381 | # This is expressed as a rewrite rule instead of an "if" because |
| @@ -410,17 +410,17 @@ | |
| 410 | |
| 411 | root /var/www/$host; |
| 412 | access_log /var/log/nginx/$host-http-access.log; |
| 413 | error_log /var/log/nginx/$host-http-error.log; |
| 414 | |
| 415 | Sadly, nginx doesn’t allow variable substitution into these particular |
| 416 | directives. As I understand it, allowing that would make nginx slower, |
| 417 | so we must largely repeat these directives in each HTTP `server { }` |
| 418 | block. |
| 419 | |
| 420 | These configurations are, as shown, as small as I know how to get them. |
| 421 | If you know of a way to reduce some of this repetition, [I solicit your |
| 422 | advice][fd]. |
| 423 | |
| 424 | |
| 425 | ## Step 3: Dry Run |
| 426 | |
| 427 |
+3
-3
| --- www/unvers.wiki | ||
| +++ www/unvers.wiki | ||
| @@ -4,11 +4,11 @@ | ||
| 4 | 4 | "Unversioned content" or "unversioned files" are |
| 5 | 5 | files stored in a Fossil repository without history. |
| 6 | 6 | Only the newest version of each unversioned file is retained. |
| 7 | 7 | |
| 8 | 8 | Though history is omitted, unversioned content is synced between |
| 9 | -respositories. In the event of a conflict during a sync, the most recent | |
| 9 | +repositories. In the event of a conflict during a sync, the most recent | |
| 10 | 10 | version of each unversioned file is retained and older versions are discarded. |
| 11 | 11 | |
| 12 | 12 | Unversioned files are useful for storing ephemeral content such as builds |
| 13 | 13 | or frequently changing web pages. |
| 14 | 14 | The [https://www.fossil-scm.org/fossil/uv/download.html|download] page of |
| @@ -20,21 +20,21 @@ | ||
| 20 | 20 | Unversioned files are <u>not</u> a part of a check-out. |
| 21 | 21 | Unversioned files are intended to be accessible as web pages using |
| 22 | 22 | URLs of the form: "http://domain/cgi-script/<b>uv</b>/<i>FILENAME</i>". |
| 23 | 23 | In other words, the URI method "<b>uv</b>" (short for "unversioned") |
| 24 | 24 | followed by the name of the unversioned file will retrieve the content |
| 25 | -of the file. The mimetype is inferred from the filename suffix. | |
| 25 | +of the file. The MIME type is inferred from the filename suffix. | |
| 26 | 26 | |
| 27 | 27 | The content of unversioned files can also be retrieved using the |
| 28 | 28 | [/help?cmd=unversioned|fossil unvers cat <i>FILENAME</i>] command. |
| 29 | 29 | |
| 30 | 30 | A list of all unversioned files on a server can be seen using |
| 31 | 31 | the [/help?cmd=/uvlist|/uvlist] URL. ([/uvlist|example]). |
| 32 | 32 | |
| 33 | 33 | <h2>Syncing Unversioned Files</h2> |
| 34 | 34 | |
| 35 | -Unversioned content is synced between respositories, though not by default. | |
| 35 | +Unversioned content is synced between repositories, though not by default. | |
| 36 | 36 | Special commands or command-line options are required. |
| 37 | 37 | Unversioned content can be synced using the following commands: |
| 38 | 38 | |
| 39 | 39 | <blockquote><pre> |
| 40 | 40 | fossil sync <b>-u</b> |
| 41 | 41 |
| --- www/unvers.wiki | |
| +++ www/unvers.wiki | |
| @@ -4,11 +4,11 @@ | |
| 4 | "Unversioned content" or "unversioned files" are |
| 5 | files stored in a Fossil repository without history. |
| 6 | Only the newest version of each unversioned file is retained. |
| 7 | |
| 8 | Though history is omitted, unversioned content is synced between |
| 9 | respositories. In the event of a conflict during a sync, the most recent |
| 10 | version of each unversioned file is retained and older versions are discarded. |
| 11 | |
| 12 | Unversioned files are useful for storing ephemeral content such as builds |
| 13 | or frequently changing web pages. |
| 14 | The [https://www.fossil-scm.org/fossil/uv/download.html|download] page of |
| @@ -20,21 +20,21 @@ | |
| 20 | Unversioned files are <u>not</u> a part of a check-out. |
| 21 | Unversioned files are intended to be accessible as web pages using |
| 22 | URLs of the form: "http://domain/cgi-script/<b>uv</b>/<i>FILENAME</i>". |
| 23 | In other words, the URI method "<b>uv</b>" (short for "unversioned") |
| 24 | followed by the name of the unversioned file will retrieve the content |
| 25 | of the file. The mimetype is inferred from the filename suffix. |
| 26 | |
| 27 | The content of unversioned files can also be retrieved using the |
| 28 | [/help?cmd=unversioned|fossil unvers cat <i>FILENAME</i>] command. |
| 29 | |
| 30 | A list of all unversioned files on a server can be seen using |
| 31 | the [/help?cmd=/uvlist|/uvlist] URL. ([/uvlist|example]). |
| 32 | |
| 33 | <h2>Syncing Unversioned Files</h2> |
| 34 | |
| 35 | Unversioned content is synced between respositories, though not by default. |
| 36 | Special commands or command-line options are required. |
| 37 | Unversioned content can be synced using the following commands: |
| 38 | |
| 39 | <blockquote><pre> |
| 40 | fossil sync <b>-u</b> |
| 41 |
| --- www/unvers.wiki | |
| +++ www/unvers.wiki | |
| @@ -4,11 +4,11 @@ | |
| 4 | "Unversioned content" or "unversioned files" are |
| 5 | files stored in a Fossil repository without history. |
| 6 | Only the newest version of each unversioned file is retained. |
| 7 | |
| 8 | Though history is omitted, unversioned content is synced between |
| 9 | repositories. In the event of a conflict during a sync, the most recent |
| 10 | version of each unversioned file is retained and older versions are discarded. |
| 11 | |
| 12 | Unversioned files are useful for storing ephemeral content such as builds |
| 13 | or frequently changing web pages. |
| 14 | The [https://www.fossil-scm.org/fossil/uv/download.html|download] page of |
| @@ -20,21 +20,21 @@ | |
| 20 | Unversioned files are <u>not</u> a part of a check-out. |
| 21 | Unversioned files are intended to be accessible as web pages using |
| 22 | URLs of the form: "http://domain/cgi-script/<b>uv</b>/<i>FILENAME</i>". |
| 23 | In other words, the URI method "<b>uv</b>" (short for "unversioned") |
| 24 | followed by the name of the unversioned file will retrieve the content |
| 25 | of the file. The MIME type is inferred from the filename suffix. |
| 26 | |
| 27 | The content of unversioned files can also be retrieved using the |
| 28 | [/help?cmd=unversioned|fossil unvers cat <i>FILENAME</i>] command. |
| 29 | |
| 30 | A list of all unversioned files on a server can be seen using |
| 31 | the [/help?cmd=/uvlist|/uvlist] URL. ([/uvlist|example]). |
| 32 | |
| 33 | <h2>Syncing Unversioned Files</h2> |
| 34 | |
| 35 | Unversioned content is synced between repositories, though not by default. |
| 36 | Special commands or command-line options are required. |
| 37 | Unversioned content can be synced using the following commands: |
| 38 | |
| 39 | <blockquote><pre> |
| 40 | fossil sync <b>-u</b> |
| 41 |