Fossil SCM
fixed a number of typos in WWW-docs, as suggested on ML
Commit
05fc09c5ddc1b00f19a639bbc396be7f29f997aa
Parent
e7ec49815b98881…
16 files changed
+4
-4
+2
-2
+2
-2
+1
-1
+2
-2
+2
-2
+1
-1
+3
-3
+2
-2
+1
-1
+2
-2
+1
-1
+2
-2
+2
-2
+1
-1
+1
-1
~
www/changes.wiki
~
www/checkin_names.wiki
~
www/copyright-release.html
~
www/delta_format.wiki
~
www/faq.tcl
~
www/faq.wiki
~
www/fileformat.wiki
~
www/fiveminutes.wiki
~
www/fossil-v-git.wiki
~
www/inout.wiki
~
www/private.wiki
~
www/quotes.wiki
~
www/server.wiki
~
www/stats.wiki
~
www/th1.md
~
www/webui.wiki
+4
-4
| --- www/changes.wiki | ||
| +++ www/changes.wiki | ||
| @@ -363,11 +363,11 @@ | ||
| 363 | 363 | --allow-conflict. |
| 364 | 364 | * Optionally require a CAPTCHA (controlled by a setting on the |
| 365 | 365 | Admin/Access webpage) when a user who is not logged in tries to |
| 366 | 366 | edit wiki, or a ticket, or an attachment. |
| 367 | 367 | * Improvements to the "ssh://" sync protocol, to help it move past |
| 368 | - noisey motd comments. | |
| 368 | + noisy motd comments. | |
| 369 | 369 | * Add the uf=FILE-SHA1-HASH query parameter to the timeline, causing the |
| 370 | 370 | timeline to show only check-ins that contain the specific file identified |
| 371 | 371 | by FILE-SHA1-HASH. ("uf" stands for "uses file".) |
| 372 | 372 | * Enhance the file change annotator so that it follows the file across |
| 373 | 373 | name changes. |
| @@ -413,14 +413,14 @@ | ||
| 413 | 413 | * Added the "fossil stash show" command. |
| 414 | 414 | * Added the "fileage" webpage with links to this page from the check-in |
| 415 | 415 | information page and from the file browser. |
| 416 | 416 | * Added --age and -t options to the "fossil ls" command. |
| 417 | 417 | * Added the --setmtime option to "fossil update". When used, the mtime |
| 418 | - of all mananged files is set to the time when the most recent version of | |
| 418 | + of all managed files is set to the time when the most recent version of | |
| 419 | 419 | the file was checked in. |
| 420 | 420 | * Changed the "vdiff" webpage to show the complete text of files that |
| 421 | - were added or removed (the equivelent of using the -N or --newfile | |
| 421 | + were added or removed (the equivalent of using the -N or --newfile | |
| 422 | 422 | options with the "fossil diff" command-line.) |
| 423 | 423 | * Added the --temp option to "fossil clean" and "fossil extra", causing |
| 424 | 424 | those commands to only look at temporary files generated by Fossil, |
| 425 | 425 | such as merge-conflict reports or aborted check-in messages. |
| 426 | 426 | * Enhance the raw page download so that it can guess the mimetype of |
| @@ -591,11 +591,11 @@ | ||
| 591 | 591 | * Added the "[/help/winsrv | fossil winsrv]" command |
| 592 | 592 | for creating a Fossil service on windows systems. |
| 593 | 593 | * Added "versionable settings" where settings that affect |
| 594 | 594 | the local tree can be stored in versioned files in the |
| 595 | 595 | .fossil-settings directory. |
| 596 | - * Background colors for branches are choosen automatically if no | |
| 596 | + * Background colors for branches are chosen automatically if no | |
| 597 | 597 | color is specified by the user. |
| 598 | 598 | * The status, changes and extras commands now show |
| 599 | 599 | pathnames relative to the current working directory, |
| 600 | 600 | unless overridden by command line options or the |
| 601 | 601 | "relative-paths" setting.<br><b>WARNING:</b> This |
| 602 | 602 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -363,11 +363,11 @@ | |
| 363 | --allow-conflict. |
| 364 | * Optionally require a CAPTCHA (controlled by a setting on the |
| 365 | Admin/Access webpage) when a user who is not logged in tries to |
| 366 | edit wiki, or a ticket, or an attachment. |
| 367 | * Improvements to the "ssh://" sync protocol, to help it move past |
| 368 | noisey motd comments. |
| 369 | * Add the uf=FILE-SHA1-HASH query parameter to the timeline, causing the |
| 370 | timeline to show only check-ins that contain the specific file identified |
| 371 | by FILE-SHA1-HASH. ("uf" stands for "uses file".) |
| 372 | * Enhance the file change annotator so that it follows the file across |
| 373 | name changes. |
| @@ -413,14 +413,14 @@ | |
| 413 | * Added the "fossil stash show" command. |
| 414 | * Added the "fileage" webpage with links to this page from the check-in |
| 415 | information page and from the file browser. |
| 416 | * Added --age and -t options to the "fossil ls" command. |
| 417 | * Added the --setmtime option to "fossil update". When used, the mtime |
| 418 | of all mananged files is set to the time when the most recent version of |
| 419 | the file was checked in. |
| 420 | * Changed the "vdiff" webpage to show the complete text of files that |
| 421 | were added or removed (the equivelent of using the -N or --newfile |
| 422 | options with the "fossil diff" command-line.) |
| 423 | * Added the --temp option to "fossil clean" and "fossil extra", causing |
| 424 | those commands to only look at temporary files generated by Fossil, |
| 425 | such as merge-conflict reports or aborted check-in messages. |
| 426 | * Enhance the raw page download so that it can guess the mimetype of |
| @@ -591,11 +591,11 @@ | |
| 591 | * Added the "[/help/winsrv | fossil winsrv]" command |
| 592 | for creating a Fossil service on windows systems. |
| 593 | * Added "versionable settings" where settings that affect |
| 594 | the local tree can be stored in versioned files in the |
| 595 | .fossil-settings directory. |
| 596 | * Background colors for branches are choosen automatically if no |
| 597 | color is specified by the user. |
| 598 | * The status, changes and extras commands now show |
| 599 | pathnames relative to the current working directory, |
| 600 | unless overridden by command line options or the |
| 601 | "relative-paths" setting.<br><b>WARNING:</b> This |
| 602 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -363,11 +363,11 @@ | |
| 363 | --allow-conflict. |
| 364 | * Optionally require a CAPTCHA (controlled by a setting on the |
| 365 | Admin/Access webpage) when a user who is not logged in tries to |
| 366 | edit wiki, or a ticket, or an attachment. |
| 367 | * Improvements to the "ssh://" sync protocol, to help it move past |
| 368 | noisy motd comments. |
| 369 | * Add the uf=FILE-SHA1-HASH query parameter to the timeline, causing the |
| 370 | timeline to show only check-ins that contain the specific file identified |
| 371 | by FILE-SHA1-HASH. ("uf" stands for "uses file".) |
| 372 | * Enhance the file change annotator so that it follows the file across |
| 373 | name changes. |
| @@ -413,14 +413,14 @@ | |
| 413 | * Added the "fossil stash show" command. |
| 414 | * Added the "fileage" webpage with links to this page from the check-in |
| 415 | information page and from the file browser. |
| 416 | * Added --age and -t options to the "fossil ls" command. |
| 417 | * Added the --setmtime option to "fossil update". When used, the mtime |
| 418 | of all managed files is set to the time when the most recent version of |
| 419 | the file was checked in. |
| 420 | * Changed the "vdiff" webpage to show the complete text of files that |
| 421 | were added or removed (the equivalent of using the -N or --newfile |
| 422 | options with the "fossil diff" command-line.) |
| 423 | * Added the --temp option to "fossil clean" and "fossil extra", causing |
| 424 | those commands to only look at temporary files generated by Fossil, |
| 425 | such as merge-conflict reports or aborted check-in messages. |
| 426 | * Enhance the raw page download so that it can guess the mimetype of |
| @@ -591,11 +591,11 @@ | |
| 591 | * Added the "[/help/winsrv | fossil winsrv]" command |
| 592 | for creating a Fossil service on windows systems. |
| 593 | * Added "versionable settings" where settings that affect |
| 594 | the local tree can be stored in versioned files in the |
| 595 | .fossil-settings directory. |
| 596 | * Background colors for branches are chosen automatically if no |
| 597 | color is specified by the user. |
| 598 | * The status, changes and extras commands now show |
| 599 | pathnames relative to the current working directory, |
| 600 | unless overridden by command line options or the |
| 601 | "relative-paths" setting.<br><b>WARNING:</b> This |
| 602 |
+2
-2
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -117,18 +117,18 @@ | ||
| 117 | 117 | tagged with "deed2" not to the |
| 118 | 118 | check-in whose canonical name begins with "deed2". |
| 119 | 119 | |
| 120 | 120 | <h2>Whole Branches</h2> |
| 121 | 121 | |
| 122 | -Usually whan a branch name is specified, it means the latest checkin on | |
| 122 | +Usually when a branch name is specified, it means the latest checkin on | |
| 123 | 123 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 124 | 124 | on the argument means the earliest connected checkin on the branch. This |
| 125 | 125 | seems confusing when being explained here, but it works out to be intuitive |
| 126 | 126 | in practice. |
| 127 | 127 | |
| 128 | 128 | For example, the command "fossil purge XYZ" means to purge the checkin XYZ |
| 129 | -and all of its descendents. But when XYZ is in the form of a branch name, one | |
| 129 | +and all of its descendants. But when XYZ is in the form of a branch name, one | |
| 130 | 130 | generally wants to purge the entire branch, not just the last checkin on the |
| 131 | 131 | branch. And so for this reason, commands like purge will interpret a branch |
| 132 | 132 | name to be the first checkin of the branch rather than the last. If there |
| 133 | 133 | are two or more branches with the same name, then these commands will select |
| 134 | 134 | the first check-in of the branch that has the most recent checkin. What |
| 135 | 135 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -117,18 +117,18 @@ | |
| 117 | tagged with "deed2" not to the |
| 118 | check-in whose canonical name begins with "deed2". |
| 119 | |
| 120 | <h2>Whole Branches</h2> |
| 121 | |
| 122 | Usually whan a branch name is specified, it means the latest checkin on |
| 123 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 124 | on the argument means the earliest connected checkin on the branch. This |
| 125 | seems confusing when being explained here, but it works out to be intuitive |
| 126 | in practice. |
| 127 | |
| 128 | For example, the command "fossil purge XYZ" means to purge the checkin XYZ |
| 129 | and all of its descendents. But when XYZ is in the form of a branch name, one |
| 130 | generally wants to purge the entire branch, not just the last checkin on the |
| 131 | branch. And so for this reason, commands like purge will interpret a branch |
| 132 | name to be the first checkin of the branch rather than the last. If there |
| 133 | are two or more branches with the same name, then these commands will select |
| 134 | the first check-in of the branch that has the most recent checkin. What |
| 135 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -117,18 +117,18 @@ | |
| 117 | tagged with "deed2" not to the |
| 118 | check-in whose canonical name begins with "deed2". |
| 119 | |
| 120 | <h2>Whole Branches</h2> |
| 121 | |
| 122 | Usually when a branch name is specified, it means the latest checkin on |
| 123 | that branch. But for some commands (ex: [/help/purge|purge]) a branch name |
| 124 | on the argument means the earliest connected checkin on the branch. This |
| 125 | seems confusing when being explained here, but it works out to be intuitive |
| 126 | in practice. |
| 127 | |
| 128 | For example, the command "fossil purge XYZ" means to purge the checkin XYZ |
| 129 | and all of its descendants. But when XYZ is in the form of a branch name, one |
| 130 | generally wants to purge the entire branch, not just the last checkin on the |
| 131 | branch. And so for this reason, commands like purge will interpret a branch |
| 132 | name to be the first checkin of the branch rather than the last. If there |
| 133 | are two or more branches with the same name, then these commands will select |
| 134 | the first check-in of the branch that has the most recent checkin. What |
| 135 |
+2
-2
| --- www/copyright-release.html | ||
| +++ www/copyright-release.html | ||
| @@ -3,11 +3,11 @@ | ||
| 3 | 3 | </h1> |
| 4 | 4 | |
| 5 | 5 | <p> |
| 6 | 6 | This agreement applies to your contribution of material to the |
| 7 | 7 | Fossil Software Configuration Management System ("Fossil") that is |
| 8 | -mananged by Hipp, Wyrick & Company, Inc. ("Hwaci") and | |
| 8 | +managed by Hipp, Wyrick & Company, Inc. ("Hwaci") and | |
| 9 | 9 | sets out the intellectual property rights you grant to Hwaci in the |
| 10 | 10 | contributed material. |
| 11 | 11 | The terms "contribution" and "contributed material" mean any source code, |
| 12 | 12 | object code, patch, tool, sample, graphic, specification, manual, |
| 13 | 13 | documentation, or any other material posted, submitted, or uploaded by |
| @@ -66,11 +66,11 @@ | ||
| 66 | 66 | grant the rights set out in this agreement. |
| 67 | 67 | <li> Your contribution does not, to the best of your knowledge and belief, |
| 68 | 68 | violate any third party's copyrights, trademarks, patents, |
| 69 | 69 | or other intellectual property rights. |
| 70 | 70 | <li> You are authorized to sign this agreement on behalf of your |
| 71 | - company (if appliable). | |
| 71 | + company (if applicable). | |
| 72 | 72 | </ul> |
| 73 | 73 | </ol> |
| 74 | 74 | |
| 75 | 75 | <p>By filling in the following information and signing your name, |
| 76 | 76 | you agree to be bound by all of the terms |
| 77 | 77 |
| --- www/copyright-release.html | |
| +++ www/copyright-release.html | |
| @@ -3,11 +3,11 @@ | |
| 3 | </h1> |
| 4 | |
| 5 | <p> |
| 6 | This agreement applies to your contribution of material to the |
| 7 | Fossil Software Configuration Management System ("Fossil") that is |
| 8 | mananged by Hipp, Wyrick & Company, Inc. ("Hwaci") and |
| 9 | sets out the intellectual property rights you grant to Hwaci in the |
| 10 | contributed material. |
| 11 | The terms "contribution" and "contributed material" mean any source code, |
| 12 | object code, patch, tool, sample, graphic, specification, manual, |
| 13 | documentation, or any other material posted, submitted, or uploaded by |
| @@ -66,11 +66,11 @@ | |
| 66 | grant the rights set out in this agreement. |
| 67 | <li> Your contribution does not, to the best of your knowledge and belief, |
| 68 | violate any third party's copyrights, trademarks, patents, |
| 69 | or other intellectual property rights. |
| 70 | <li> You are authorized to sign this agreement on behalf of your |
| 71 | company (if appliable). |
| 72 | </ul> |
| 73 | </ol> |
| 74 | |
| 75 | <p>By filling in the following information and signing your name, |
| 76 | you agree to be bound by all of the terms |
| 77 |
| --- www/copyright-release.html | |
| +++ www/copyright-release.html | |
| @@ -3,11 +3,11 @@ | |
| 3 | </h1> |
| 4 | |
| 5 | <p> |
| 6 | This agreement applies to your contribution of material to the |
| 7 | Fossil Software Configuration Management System ("Fossil") that is |
| 8 | managed by Hipp, Wyrick & Company, Inc. ("Hwaci") and |
| 9 | sets out the intellectual property rights you grant to Hwaci in the |
| 10 | contributed material. |
| 11 | The terms "contribution" and "contributed material" mean any source code, |
| 12 | object code, patch, tool, sample, graphic, specification, manual, |
| 13 | documentation, or any other material posted, submitted, or uploaded by |
| @@ -66,11 +66,11 @@ | |
| 66 | grant the rights set out in this agreement. |
| 67 | <li> Your contribution does not, to the best of your knowledge and belief, |
| 68 | violate any third party's copyrights, trademarks, patents, |
| 69 | or other intellectual property rights. |
| 70 | <li> You are authorized to sign this agreement on behalf of your |
| 71 | company (if applicable). |
| 72 | </ul> |
| 73 | </ol> |
| 74 | |
| 75 | <p>By filling in the following information and signing your name, |
| 76 | you agree to be bound by all of the terms |
| 77 |
+1
-1
| --- www/delta_format.wiki | ||
| +++ www/delta_format.wiki | ||
| @@ -155,11 +155,11 @@ | ||
| 155 | 155 | <tr><td> </td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr> |
| 156 | 156 | <tr><td> </td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr> |
| 157 | 157 | <tr><td> </td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr> |
| 158 | 158 | <tr><td> </td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr> |
| 159 | 159 | <tr><td> </td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr> |
| 160 | -<tr><td>Trailer</td><td>2zMM3E </td><td>Ckecksum</td><td> -1101438770 </td></tr> | |
| 160 | +<tr><td>Trailer</td><td>2zMM3E </td><td>Checksum</td><td> -1101438770 </td></tr> | |
| 161 | 161 | </table> |
| 162 | 162 | |
| 163 | 163 | <p>The unified diff behind the above delta is</p> |
| 164 | 164 | |
| 165 | 165 | <table border=1><tr><td><pre> |
| 166 | 166 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -155,11 +155,11 @@ | |
| 155 | <tr><td> </td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr> |
| 156 | <tr><td> </td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr> |
| 157 | <tr><td> </td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr> |
| 158 | <tr><td> </td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr> |
| 159 | <tr><td> </td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr> |
| 160 | <tr><td>Trailer</td><td>2zMM3E </td><td>Ckecksum</td><td> -1101438770 </td></tr> |
| 161 | </table> |
| 162 | |
| 163 | <p>The unified diff behind the above delta is</p> |
| 164 | |
| 165 | <table border=1><tr><td><pre> |
| 166 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -155,11 +155,11 @@ | |
| 155 | <tr><td> </td> <td>5x@Kt, </td><td>Copy </td><td> 380 @ 1336 </td></tr> |
| 156 | <tr><td> </td> <td>6:pieces </td><td>Literal </td><td> 6 'pieces' </td></tr> |
| 157 | <tr><td> </td> <td>79@Qt, </td><td>Copy </td><td> 457 @ 1720 </td></tr> |
| 158 | <tr><td> </td> <td>F: Example: eskil</td><td>Literal </td><td> 15 ' Example: eskil'</td></tr> |
| 159 | <tr><td> </td> <td>~E@Y0, </td><td>Copy </td><td> 4046 @ 2176 </td></tr> |
| 160 | <tr><td>Trailer</td><td>2zMM3E </td><td>Checksum</td><td> -1101438770 </td></tr> |
| 161 | </table> |
| 162 | |
| 163 | <p>The unified diff behind the above delta is</p> |
| 164 | |
| 165 | <table border=1><tr><td><pre> |
| 166 |
+2
-2
| --- www/faq.tcl | ||
| +++ www/faq.tcl | ||
| @@ -84,11 +84,11 @@ | ||
| 84 | 84 | The CHECK-IN in the previous line can be any |
| 85 | 85 | [./checkin_names.wiki | valid check-in name format]. |
| 86 | 86 | |
| 87 | 87 | You can also add (and remove) tags from a check-in using the |
| 88 | 88 | [./webui.wiki | web interface]. First locate the check-in that you |
| 89 | - what to tag on the tmline, then click on the link to go the detailed | |
| 89 | + what to tag on the timeline, then click on the link to go the detailed | |
| 90 | 90 | information page for that check-in. Then find the "<b>edit</b>" |
| 91 | 91 | link (near the "Commands:" label) and click on that. There are |
| 92 | 92 | controls on the edit page that allow new tags to be added and existing |
| 93 | 93 | tags to be removed. |
| 94 | 94 | } |
| @@ -98,11 +98,11 @@ | ||
| 98 | 98 | main repository. |
| 99 | 99 | } { |
| 100 | 100 | Use the <b>--private</b> command-line option on the |
| 101 | 101 | <b>commit</b> command. The result will be a check-in which exists on |
| 102 | 102 | your local repository only and is never pushed to other repositories. |
| 103 | - All descendents of a private check-in are also private. | |
| 103 | + All descendants of a private check-in are also private. | |
| 104 | 104 | |
| 105 | 105 | Unless you specify something different using the <b>--branch</b> and/or |
| 106 | 106 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 107 | 107 | named "private" with an orange background color. |
| 108 | 108 | |
| 109 | 109 |
| --- www/faq.tcl | |
| +++ www/faq.tcl | |
| @@ -84,11 +84,11 @@ | |
| 84 | The CHECK-IN in the previous line can be any |
| 85 | [./checkin_names.wiki | valid check-in name format]. |
| 86 | |
| 87 | You can also add (and remove) tags from a check-in using the |
| 88 | [./webui.wiki | web interface]. First locate the check-in that you |
| 89 | what to tag on the tmline, then click on the link to go the detailed |
| 90 | information page for that check-in. Then find the "<b>edit</b>" |
| 91 | link (near the "Commands:" label) and click on that. There are |
| 92 | controls on the edit page that allow new tags to be added and existing |
| 93 | tags to be removed. |
| 94 | } |
| @@ -98,11 +98,11 @@ | |
| 98 | main repository. |
| 99 | } { |
| 100 | Use the <b>--private</b> command-line option on the |
| 101 | <b>commit</b> command. The result will be a check-in which exists on |
| 102 | your local repository only and is never pushed to other repositories. |
| 103 | All descendents of a private check-in are also private. |
| 104 | |
| 105 | Unless you specify something different using the <b>--branch</b> and/or |
| 106 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 107 | named "private" with an orange background color. |
| 108 | |
| 109 |
| --- www/faq.tcl | |
| +++ www/faq.tcl | |
| @@ -84,11 +84,11 @@ | |
| 84 | The CHECK-IN in the previous line can be any |
| 85 | [./checkin_names.wiki | valid check-in name format]. |
| 86 | |
| 87 | You can also add (and remove) tags from a check-in using the |
| 88 | [./webui.wiki | web interface]. First locate the check-in that you |
| 89 | what to tag on the timeline, then click on the link to go the detailed |
| 90 | information page for that check-in. Then find the "<b>edit</b>" |
| 91 | link (near the "Commands:" label) and click on that. There are |
| 92 | controls on the edit page that allow new tags to be added and existing |
| 93 | tags to be removed. |
| 94 | } |
| @@ -98,11 +98,11 @@ | |
| 98 | main repository. |
| 99 | } { |
| 100 | Use the <b>--private</b> command-line option on the |
| 101 | <b>commit</b> command. The result will be a check-in which exists on |
| 102 | your local repository only and is never pushed to other repositories. |
| 103 | All descendants of a private check-in are also private. |
| 104 | |
| 105 | Unless you specify something different using the <b>--branch</b> and/or |
| 106 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 107 | named "private" with an orange background color. |
| 108 | |
| 109 |
+2
-2
| --- www/faq.wiki | ||
| +++ www/faq.wiki | ||
| @@ -87,11 +87,11 @@ | ||
| 87 | 87 | The CHECK-IN in the previous line can be any |
| 88 | 88 | [./checkin_names.wiki | valid check-in name format]. |
| 89 | 89 | |
| 90 | 90 | You can also add (and remove) tags from a check-in using the |
| 91 | 91 | [./webui.wiki | web interface]. First locate the check-in that you |
| 92 | -what to tag on the tmline, then click on the link to go the detailed | |
| 92 | +what to tag on the timeline, then click on the link to go the detailed | |
| 93 | 93 | information page for that check-in. Then find the "<b>edit</b>" |
| 94 | 94 | link (near the "Commands:" label) and click on that. There are |
| 95 | 95 | controls on the edit page that allow new tags to be added and existing |
| 96 | 96 | tags to be removed.</blockquote></li> |
| 97 | 97 | |
| @@ -100,11 +100,11 @@ | ||
| 100 | 100 | main repository.</b></p> |
| 101 | 101 | |
| 102 | 102 | <blockquote>Use the <b>--private</b> command-line option on the |
| 103 | 103 | <b>commit</b> command. The result will be a check-in which exists on |
| 104 | 104 | your local repository only and is never pushed to other repositories. |
| 105 | -All descendents of a private check-in are also private. | |
| 105 | +All descendants of a private check-in are also private. | |
| 106 | 106 | |
| 107 | 107 | Unless you specify something different using the <b>--branch</b> and/or |
| 108 | 108 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 109 | 109 | named "private" with an orange background color. |
| 110 | 110 | |
| 111 | 111 |
| --- www/faq.wiki | |
| +++ www/faq.wiki | |
| @@ -87,11 +87,11 @@ | |
| 87 | The CHECK-IN in the previous line can be any |
| 88 | [./checkin_names.wiki | valid check-in name format]. |
| 89 | |
| 90 | You can also add (and remove) tags from a check-in using the |
| 91 | [./webui.wiki | web interface]. First locate the check-in that you |
| 92 | what to tag on the tmline, then click on the link to go the detailed |
| 93 | information page for that check-in. Then find the "<b>edit</b>" |
| 94 | link (near the "Commands:" label) and click on that. There are |
| 95 | controls on the edit page that allow new tags to be added and existing |
| 96 | tags to be removed.</blockquote></li> |
| 97 | |
| @@ -100,11 +100,11 @@ | |
| 100 | main repository.</b></p> |
| 101 | |
| 102 | <blockquote>Use the <b>--private</b> command-line option on the |
| 103 | <b>commit</b> command. The result will be a check-in which exists on |
| 104 | your local repository only and is never pushed to other repositories. |
| 105 | All descendents of a private check-in are also private. |
| 106 | |
| 107 | Unless you specify something different using the <b>--branch</b> and/or |
| 108 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 109 | named "private" with an orange background color. |
| 110 | |
| 111 |
| --- www/faq.wiki | |
| +++ www/faq.wiki | |
| @@ -87,11 +87,11 @@ | |
| 87 | The CHECK-IN in the previous line can be any |
| 88 | [./checkin_names.wiki | valid check-in name format]. |
| 89 | |
| 90 | You can also add (and remove) tags from a check-in using the |
| 91 | [./webui.wiki | web interface]. First locate the check-in that you |
| 92 | what to tag on the timeline, then click on the link to go the detailed |
| 93 | information page for that check-in. Then find the "<b>edit</b>" |
| 94 | link (near the "Commands:" label) and click on that. There are |
| 95 | controls on the edit page that allow new tags to be added and existing |
| 96 | tags to be removed.</blockquote></li> |
| 97 | |
| @@ -100,11 +100,11 @@ | |
| 100 | main repository.</b></p> |
| 101 | |
| 102 | <blockquote>Use the <b>--private</b> command-line option on the |
| 103 | <b>commit</b> command. The result will be a check-in which exists on |
| 104 | your local repository only and is never pushed to other repositories. |
| 105 | All descendants of a private check-in are also private. |
| 106 | |
| 107 | Unless you specify something different using the <b>--branch</b> and/or |
| 108 | <b>--bgcolor</b> options, the new private check-in will be put on a branch |
| 109 | named "private" with an orange background color. |
| 110 | |
| 111 |
+1
-1
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -313,11 +313,11 @@ | ||
| 313 | 313 | to which the tag is to be applied. The |
| 314 | 314 | first value is the tag name. The first character of the tag |
| 315 | 315 | is either "+", "-", or "*". The "+" means the tag should be added |
| 316 | 316 | to the artifact. The "-" means the tag should be removed. |
| 317 | 317 | The "*" character means the tag should be added to the artifact |
| 318 | -and all direct descendants (but not descendents through a merge) down | |
| 318 | +and all direct descendants (but not descendants through a merge) down | |
| 319 | 319 | to but not including the first descendant that contains a |
| 320 | 320 | more recent "-", "*", or "+" tag with the same name. |
| 321 | 321 | The optional third argument is the value of the tag. A tag |
| 322 | 322 | without a value is a boolean. |
| 323 | 323 | |
| 324 | 324 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -313,11 +313,11 @@ | |
| 313 | to which the tag is to be applied. The |
| 314 | first value is the tag name. The first character of the tag |
| 315 | is either "+", "-", or "*". The "+" means the tag should be added |
| 316 | to the artifact. The "-" means the tag should be removed. |
| 317 | The "*" character means the tag should be added to the artifact |
| 318 | and all direct descendants (but not descendents through a merge) down |
| 319 | to but not including the first descendant that contains a |
| 320 | more recent "-", "*", or "+" tag with the same name. |
| 321 | The optional third argument is the value of the tag. A tag |
| 322 | without a value is a boolean. |
| 323 | |
| 324 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -313,11 +313,11 @@ | |
| 313 | to which the tag is to be applied. The |
| 314 | first value is the tag name. The first character of the tag |
| 315 | is either "+", "-", or "*". The "+" means the tag should be added |
| 316 | to the artifact. The "-" means the tag should be removed. |
| 317 | The "*" character means the tag should be added to the artifact |
| 318 | and all direct descendants (but not descendants through a merge) down |
| 319 | to but not including the first descendant that contains a |
| 320 | more recent "-", "*", or "+" tag with the same name. |
| 321 | The optional third argument is the value of the tag. A tag |
| 322 | without a value is a boolean. |
| 323 | |
| 324 |
+3
-3
| --- www/fiveminutes.wiki | ||
| +++ www/fiveminutes.wiki | ||
| @@ -32,18 +32,18 @@ | ||
| 32 | 32 | to add all the files in the current directory recursively, ie. including all |
| 33 | 33 | the files in all the subdirectories.</p> |
| 34 | 34 | <p>Note: To tell Fossil to ignore some extensions:</p> |
| 35 | 35 | <p>fossil settings ignore-glob "*.o,*.obj,*.exe" --global</p> |
| 36 | 36 | |
| 37 | -<h2>Remove files that haven't been commited yet</h2> | |
| 37 | +<h2>Remove files that haven't been committed yet</h2> | |
| 38 | 38 | <p>fossil delete myfile.c</p> |
| 39 | 39 | <p>This will simply remove the item from the list of files that were previously |
| 40 | 40 | added through "fossil add".</p> |
| 41 | 41 | |
| 42 | 42 | <h2>Check current status</h2> |
| 43 | 43 | <p>fossil changes</p> |
| 44 | -<p>This shows the list of changes that have been done and will be commited the | |
| 44 | +<p>This shows the list of changes that have been done and will be committed the | |
| 45 | 45 | next time you run "fossil commit". It's a useful command to run before |
| 46 | 46 | running "fossil commit" just to check that things are OK before proceeding.</p> |
| 47 | 47 | |
| 48 | 48 | <h2>Commit changes</h2> |
| 49 | 49 | <p>To actually apply the pending changes to the repository, eg. new files marked |
| @@ -59,11 +59,11 @@ | ||
| 59 | 59 | <p>If you wish to compare the last revision of a file and its checked out version |
| 60 | 60 | in your work directory:</p> |
| 61 | 61 | <p>fossil gdiff myfile.c</p> |
| 62 | 62 | <p>If you wish to compare two different revisions of a file in the repository:</p> |
| 63 | 63 | <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit |
| 64 | -when the file was commited</p> | |
| 64 | +when the file was committed</p> | |
| 65 | 65 | <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p> |
| 66 | 66 | <h2>Cancel changes and go back to previous revision</h2> |
| 67 | 67 | <p>fossil revert myfile.c</p> |
| 68 | 68 | <p>Fossil does not prompt when reverting a file. It simply reminds the user about the |
| 69 | 69 | "undo" command, just in case the revert was a mistake.</p> |
| 70 | 70 |
| --- www/fiveminutes.wiki | |
| +++ www/fiveminutes.wiki | |
| @@ -32,18 +32,18 @@ | |
| 32 | to add all the files in the current directory recursively, ie. including all |
| 33 | the files in all the subdirectories.</p> |
| 34 | <p>Note: To tell Fossil to ignore some extensions:</p> |
| 35 | <p>fossil settings ignore-glob "*.o,*.obj,*.exe" --global</p> |
| 36 | |
| 37 | <h2>Remove files that haven't been commited yet</h2> |
| 38 | <p>fossil delete myfile.c</p> |
| 39 | <p>This will simply remove the item from the list of files that were previously |
| 40 | added through "fossil add".</p> |
| 41 | |
| 42 | <h2>Check current status</h2> |
| 43 | <p>fossil changes</p> |
| 44 | <p>This shows the list of changes that have been done and will be commited the |
| 45 | next time you run "fossil commit". It's a useful command to run before |
| 46 | running "fossil commit" just to check that things are OK before proceeding.</p> |
| 47 | |
| 48 | <h2>Commit changes</h2> |
| 49 | <p>To actually apply the pending changes to the repository, eg. new files marked |
| @@ -59,11 +59,11 @@ | |
| 59 | <p>If you wish to compare the last revision of a file and its checked out version |
| 60 | in your work directory:</p> |
| 61 | <p>fossil gdiff myfile.c</p> |
| 62 | <p>If you wish to compare two different revisions of a file in the repository:</p> |
| 63 | <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit |
| 64 | when the file was commited</p> |
| 65 | <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p> |
| 66 | <h2>Cancel changes and go back to previous revision</h2> |
| 67 | <p>fossil revert myfile.c</p> |
| 68 | <p>Fossil does not prompt when reverting a file. It simply reminds the user about the |
| 69 | "undo" command, just in case the revert was a mistake.</p> |
| 70 |
| --- www/fiveminutes.wiki | |
| +++ www/fiveminutes.wiki | |
| @@ -32,18 +32,18 @@ | |
| 32 | to add all the files in the current directory recursively, ie. including all |
| 33 | the files in all the subdirectories.</p> |
| 34 | <p>Note: To tell Fossil to ignore some extensions:</p> |
| 35 | <p>fossil settings ignore-glob "*.o,*.obj,*.exe" --global</p> |
| 36 | |
| 37 | <h2>Remove files that haven't been committed yet</h2> |
| 38 | <p>fossil delete myfile.c</p> |
| 39 | <p>This will simply remove the item from the list of files that were previously |
| 40 | added through "fossil add".</p> |
| 41 | |
| 42 | <h2>Check current status</h2> |
| 43 | <p>fossil changes</p> |
| 44 | <p>This shows the list of changes that have been done and will be committed the |
| 45 | next time you run "fossil commit". It's a useful command to run before |
| 46 | running "fossil commit" just to check that things are OK before proceeding.</p> |
| 47 | |
| 48 | <h2>Commit changes</h2> |
| 49 | <p>To actually apply the pending changes to the repository, eg. new files marked |
| @@ -59,11 +59,11 @@ | |
| 59 | <p>If you wish to compare the last revision of a file and its checked out version |
| 60 | in your work directory:</p> |
| 61 | <p>fossil gdiff myfile.c</p> |
| 62 | <p>If you wish to compare two different revisions of a file in the repository:</p> |
| 63 | <p>fossil finfo myfile: Note the first hash, which is the UUID of the commit |
| 64 | when the file was committed</p> |
| 65 | <p>fossil gdiff --from UUID#1 --to UUID#2 myfile.c</p> |
| 66 | <h2>Cancel changes and go back to previous revision</h2> |
| 67 | <p>fossil revert myfile.c</p> |
| 68 | <p>Fossil does not prompt when reverting a file. It simply reminds the user about the |
| 69 | "undo" command, just in case the revert was a mistake.</p> |
| 70 |
+2
-2
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -56,11 +56,11 @@ | ||
| 56 | 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | 57 | of integrators merge changes from individual developers into collaborative |
| 58 | 58 | branches, until all the changes are merged together at the top-level master |
| 59 | 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | 60 | code in any one repository. Developers or groups of developers can share |
| 61 | -only those branches that they want to share and keep other branchs of the | |
| 61 | +only those branches that they want to share and keep other branches of the | |
| 62 | 62 | project private. This is analogous to sharding an a distributed database. |
| 63 | 63 | |
| 64 | 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | 66 | content at all times. This is analogous to replication in a |
| @@ -220,11 +220,11 @@ | ||
| 220 | 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | 221 | to understand. This is important if you view the history of a project |
| 222 | 222 | as part of the documentation for the project. |
| 223 | 223 | |
| 224 | 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | -stubornly refuses to change it. | |
| 225 | +stubbornly refuses to change it. | |
| 226 | 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | 229 | and the original actions are preserved and displayed alongside |
| 230 | 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 | 231 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -56,11 +56,11 @@ | |
| 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | of integrators merge changes from individual developers into collaborative |
| 58 | branches, until all the changes are merged together at the top-level master |
| 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | code in any one repository. Developers or groups of developers can share |
| 61 | only those branches that they want to share and keep other branchs of the |
| 62 | project private. This is analogous to sharding an a distributed database. |
| 63 | |
| 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | content at all times. This is analogous to replication in a |
| @@ -220,11 +220,11 @@ | |
| 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | to understand. This is important if you view the history of a project |
| 222 | as part of the documentation for the project. |
| 223 | |
| 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | stubornly refuses to change it. |
| 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | and the original actions are preserved and displayed alongside |
| 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -56,11 +56,11 @@ | |
| 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | of integrators merge changes from individual developers into collaborative |
| 58 | branches, until all the changes are merged together at the top-level master |
| 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | code in any one repository. Developers or groups of developers can share |
| 61 | only those branches that they want to share and keep other branches of the |
| 62 | project private. This is analogous to sharding an a distributed database. |
| 63 | |
| 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | content at all times. This is analogous to replication in a |
| @@ -220,11 +220,11 @@ | |
| 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | to understand. This is important if you view the history of a project |
| 222 | as part of the documentation for the project. |
| 223 | |
| 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | stubbornly refuses to change it. |
| 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | and the original actions are preserved and displayed alongside |
| 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 |
+1
-1
| --- www/inout.wiki | ||
| +++ www/inout.wiki | ||
| @@ -47,11 +47,11 @@ | ||
| 47 | 47 | As with the "import" command, the --git option is not required |
| 48 | 48 | since the git-fast-export file format is currently the only VCS interchange |
| 49 | 49 | format that Fossil will generate. However, |
| 50 | 50 | future versions of Fossil might add the ability to generate other |
| 51 | 51 | VCS interchange formats, and so for compatibility, the use of the --git |
| 52 | -option recommented. | |
| 52 | +option recommended. | |
| 53 | 53 | |
| 54 | 54 | An anonymous user sends this comment: |
| 55 | 55 | |
| 56 | 56 | <blockquote> |
| 57 | 57 | The main Fossil branch is called "trunk", while the main git branch is |
| 58 | 58 |
| --- www/inout.wiki | |
| +++ www/inout.wiki | |
| @@ -47,11 +47,11 @@ | |
| 47 | As with the "import" command, the --git option is not required |
| 48 | since the git-fast-export file format is currently the only VCS interchange |
| 49 | format that Fossil will generate. However, |
| 50 | future versions of Fossil might add the ability to generate other |
| 51 | VCS interchange formats, and so for compatibility, the use of the --git |
| 52 | option recommented. |
| 53 | |
| 54 | An anonymous user sends this comment: |
| 55 | |
| 56 | <blockquote> |
| 57 | The main Fossil branch is called "trunk", while the main git branch is |
| 58 |
| --- www/inout.wiki | |
| +++ www/inout.wiki | |
| @@ -47,11 +47,11 @@ | |
| 47 | As with the "import" command, the --git option is not required |
| 48 | since the git-fast-export file format is currently the only VCS interchange |
| 49 | format that Fossil will generate. However, |
| 50 | future versions of Fossil might add the ability to generate other |
| 51 | VCS interchange formats, and so for compatibility, the use of the --git |
| 52 | option recommended. |
| 53 | |
| 54 | An anonymous user sends this comment: |
| 55 | |
| 56 | <blockquote> |
| 57 | The main Fossil branch is called "trunk", while the main git branch is |
| 58 |
+2
-2
| --- www/private.wiki | ||
| +++ www/private.wiki | ||
| @@ -41,12 +41,12 @@ | ||
| 41 | 41 | <h2>Syncing Private Branches</h2> |
| 42 | 42 | |
| 43 | 43 | A private branch normally stays on the one repository where it was |
| 44 | 44 | originally created. But sometimes you want to share private branches |
| 45 | 45 | with another repository. For example, you might be building a cross-platform |
| 46 | -application and have separate repositories on your windows laptop, | |
| 47 | -your linux desktop, and your iMac. You can transfer private branches | |
| 46 | +application and have separate repositories on your Windows laptop, | |
| 47 | +your Linux desktop, and your iMac. You can transfer private branches | |
| 48 | 48 | between these machines by using the --private option on the "sync", |
| 49 | 49 | "push", "pull", and "clone" commands. For example, if you are running |
| 50 | 50 | "fossil server" on your linux box and you want to clone that repository |
| 51 | 51 | to your Mac, including all private branches, use: |
| 52 | 52 | |
| 53 | 53 |
| --- www/private.wiki | |
| +++ www/private.wiki | |
| @@ -41,12 +41,12 @@ | |
| 41 | <h2>Syncing Private Branches</h2> |
| 42 | |
| 43 | A private branch normally stays on the one repository where it was |
| 44 | originally created. But sometimes you want to share private branches |
| 45 | with another repository. For example, you might be building a cross-platform |
| 46 | application and have separate repositories on your windows laptop, |
| 47 | your linux desktop, and your iMac. You can transfer private branches |
| 48 | between these machines by using the --private option on the "sync", |
| 49 | "push", "pull", and "clone" commands. For example, if you are running |
| 50 | "fossil server" on your linux box and you want to clone that repository |
| 51 | to your Mac, including all private branches, use: |
| 52 | |
| 53 |
| --- www/private.wiki | |
| +++ www/private.wiki | |
| @@ -41,12 +41,12 @@ | |
| 41 | <h2>Syncing Private Branches</h2> |
| 42 | |
| 43 | A private branch normally stays on the one repository where it was |
| 44 | originally created. But sometimes you want to share private branches |
| 45 | with another repository. For example, you might be building a cross-platform |
| 46 | application and have separate repositories on your Windows laptop, |
| 47 | your Linux desktop, and your iMac. You can transfer private branches |
| 48 | between these machines by using the --private option on the "sync", |
| 49 | "push", "pull", and "clone" commands. For example, if you are running |
| 50 | "fossil server" on your linux box and you want to clone that repository |
| 51 | to your Mac, including all private branches, use: |
| 52 | |
| 53 |
+1
-1
| --- www/quotes.wiki | ||
| +++ www/quotes.wiki | ||
| @@ -5,11 +5,11 @@ | ||
| 5 | 5 | by the creator of Fossil, so of course there is selection bias... |
| 6 | 6 | |
| 7 | 7 | <h2>On The Usability Of Git:</h2> |
| 8 | 8 | |
| 9 | 9 | <ol> |
| 10 | -<li>Git approaches the useability of iptables, which is to say, utterly | |
| 10 | +<li>Git approaches the usability of iptables, which is to say, utterly | |
| 11 | 11 | unusable unless you have the manpage tattooed on you arm. |
| 12 | 12 | |
| 13 | 13 | <blockquote> |
| 14 | 14 | <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i> |
| 15 | 15 | </blockquote> |
| 16 | 16 |
| --- www/quotes.wiki | |
| +++ www/quotes.wiki | |
| @@ -5,11 +5,11 @@ | |
| 5 | by the creator of Fossil, so of course there is selection bias... |
| 6 | |
| 7 | <h2>On The Usability Of Git:</h2> |
| 8 | |
| 9 | <ol> |
| 10 | <li>Git approaches the useability of iptables, which is to say, utterly |
| 11 | unusable unless you have the manpage tattooed on you arm. |
| 12 | |
| 13 | <blockquote> |
| 14 | <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i> |
| 15 | </blockquote> |
| 16 |
| --- www/quotes.wiki | |
| +++ www/quotes.wiki | |
| @@ -5,11 +5,11 @@ | |
| 5 | by the creator of Fossil, so of course there is selection bias... |
| 6 | |
| 7 | <h2>On The Usability Of Git:</h2> |
| 8 | |
| 9 | <ol> |
| 10 | <li>Git approaches the usability of iptables, which is to say, utterly |
| 11 | unusable unless you have the manpage tattooed on you arm. |
| 12 | |
| 13 | <blockquote> |
| 14 | <i>by mml at [http://news.ycombinator.com/item?id=1433387]</i> |
| 15 | </blockquote> |
| 16 |
+2
-2
| --- www/server.wiki | ||
| +++ www/server.wiki | ||
| @@ -99,11 +99,11 @@ | ||
| 99 | 99 | off of the wire. |
| 100 | 100 | </p> |
| 101 | 101 | <p> |
| 102 | 102 | [http://www.stunnel.org/ | Stunnel version 4] is an inetd-like process that |
| 103 | 103 | accepts and decodes SSL-encrypted connections. Fossil can be run directly from |
| 104 | -stunnel in a mannar similar to inetd and xinetd. This can be used to provide | |
| 104 | +stunnel in a manner similar to inetd and xinetd. This can be used to provide | |
| 105 | 105 | a secure link to a Fossil project. The configuration needed to get stunnel4 |
| 106 | 106 | to invoke Fossil is very similar to the inetd and xinetd examples shown above. |
| 107 | 107 | The relevant parts of an stunnel configuration might look something |
| 108 | 108 | like the following: |
| 109 | 109 | <blockquote><pre><nowiki> |
| @@ -266,11 +266,11 @@ | ||
| 266 | 266 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 267 | 267 | requests can be arriving at a continuous rate of 20 or more per second |
| 268 | 268 | and the CPU can still be mostly idle. |
| 269 | 269 | <p> |
| 270 | 270 | However, there are some Fossil web pages that can consume large |
| 271 | -amounts of CPU time, expecially on repositories with a large number | |
| 271 | +amounts of CPU time, especially on repositories with a large number | |
| 272 | 272 | of files or with long revision histories. High CPU usage pages include |
| 273 | 273 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 274 | 274 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 275 | 275 | these commands can take 15 seconds or more of CPU time. |
| 276 | 276 | If these kinds of requests arrive too quickly, the load average on the |
| 277 | 277 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -99,11 +99,11 @@ | |
| 99 | off of the wire. |
| 100 | </p> |
| 101 | <p> |
| 102 | [http://www.stunnel.org/ | Stunnel version 4] is an inetd-like process that |
| 103 | accepts and decodes SSL-encrypted connections. Fossil can be run directly from |
| 104 | stunnel in a mannar similar to inetd and xinetd. This can be used to provide |
| 105 | a secure link to a Fossil project. The configuration needed to get stunnel4 |
| 106 | to invoke Fossil is very similar to the inetd and xinetd examples shown above. |
| 107 | The relevant parts of an stunnel configuration might look something |
| 108 | like the following: |
| 109 | <blockquote><pre><nowiki> |
| @@ -266,11 +266,11 @@ | |
| 266 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 267 | requests can be arriving at a continuous rate of 20 or more per second |
| 268 | and the CPU can still be mostly idle. |
| 269 | <p> |
| 270 | However, there are some Fossil web pages that can consume large |
| 271 | amounts of CPU time, expecially on repositories with a large number |
| 272 | of files or with long revision histories. High CPU usage pages include |
| 273 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 274 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 275 | these commands can take 15 seconds or more of CPU time. |
| 276 | If these kinds of requests arrive too quickly, the load average on the |
| 277 |
| --- www/server.wiki | |
| +++ www/server.wiki | |
| @@ -99,11 +99,11 @@ | |
| 99 | off of the wire. |
| 100 | </p> |
| 101 | <p> |
| 102 | [http://www.stunnel.org/ | Stunnel version 4] is an inetd-like process that |
| 103 | accepts and decodes SSL-encrypted connections. Fossil can be run directly from |
| 104 | stunnel in a manner similar to inetd and xinetd. This can be used to provide |
| 105 | a secure link to a Fossil project. The configuration needed to get stunnel4 |
| 106 | to invoke Fossil is very similar to the inetd and xinetd examples shown above. |
| 107 | The relevant parts of an stunnel configuration might look something |
| 108 | like the following: |
| 109 | <blockquote><pre><nowiki> |
| @@ -266,11 +266,11 @@ | |
| 266 | normally takes less than 10 milliseconds of CPU time to complete. So |
| 267 | requests can be arriving at a continuous rate of 20 or more per second |
| 268 | and the CPU can still be mostly idle. |
| 269 | <p> |
| 270 | However, there are some Fossil web pages that can consume large |
| 271 | amounts of CPU time, especially on repositories with a large number |
| 272 | of files or with long revision histories. High CPU usage pages include |
| 273 | [/help?cmd=/zip | /zip], [/help?cmd=/tarball | /tarball], |
| 274 | [/help?cmd=/annotate | /annotate] and others. On very large repositories, |
| 275 | these commands can take 15 seconds or more of CPU time. |
| 276 | If these kinds of requests arrive too quickly, the load average on the |
| 277 |
+2
-2
| --- www/stats.wiki | ||
| +++ www/stats.wiki | ||
| @@ -123,20 +123,20 @@ | ||
| 123 | 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | 124 | be 20% larger without that rebuild. |
| 125 | 125 | |
| 126 | 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | 127 | total number of bytes sent from server back to the client. The number of |
| 128 | -bytes sent from client to server is neglible in comparison. | |
| 128 | +bytes sent from client to server is negligible in comparison. | |
| 129 | 129 | These byte counts include HTTP protocol overhead. |
| 130 | 130 | |
| 131 | 131 | In the table and throughout this article, |
| 132 | 132 | "GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
| 133 | 133 | not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
| 134 | 134 | (2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
| 135 | 135 | means megabytes and kilobytes, not mebibytes and kibibytes. |
| 136 | 136 | |
| 137 | -<h2>Analysis And Supplimental Data</h2> | |
| 137 | +<h2>Analysis And Supplemental Data</h2> | |
| 138 | 138 | |
| 139 | 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| 143 | 143 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -123,20 +123,20 @@ | |
| 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | be 20% larger without that rebuild. |
| 125 | |
| 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | total number of bytes sent from server back to the client. The number of |
| 128 | bytes sent from client to server is neglible in comparison. |
| 129 | These byte counts include HTTP protocol overhead. |
| 130 | |
| 131 | In the table and throughout this article, |
| 132 | "GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
| 133 | not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
| 134 | (2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
| 135 | means megabytes and kilobytes, not mebibytes and kibibytes. |
| 136 | |
| 137 | <h2>Analysis And Supplimental Data</h2> |
| 138 | |
| 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| 143 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -123,20 +123,20 @@ | |
| 123 | prior to measuring its compressed size. Repository sizes would typically |
| 124 | be 20% larger without that rebuild. |
| 125 | |
| 126 | On the right end of the table, we show the "Clone Bandwidth". This is the |
| 127 | total number of bytes sent from server back to the client. The number of |
| 128 | bytes sent from client to server is negligible in comparison. |
| 129 | These byte counts include HTTP protocol overhead. |
| 130 | |
| 131 | In the table and throughout this article, |
| 132 | "GB" means gigabytes (10<sup><small>9</small></sup> bytes) |
| 133 | not <a href="http://en.wikipedia.org/wiki/Gibibyte">gibibytes</a> |
| 134 | (2<sup><small>30</small></sup> bytes). Similarly, "MB" and "KB" |
| 135 | means megabytes and kilobytes, not mebibytes and kibibytes. |
| 136 | |
| 137 | <h2>Analysis And Supplemental Data</h2> |
| 138 | |
| 139 | Perhaps the two most interesting datapoints in the above table are SQLite |
| 140 | and SLT. SQLite is a long-running project with long revision chains. |
| 141 | Some of the files in SQLite have been edited over a thousand times. |
| 142 | Each of these edits is stored as a delta, and hence the SQLite project |
| 143 |
+1
-1
| --- www/th1.md | ||
| +++ www/th1.md | ||
| @@ -79,11 +79,11 @@ | ||
| 79 | 79 | |
| 80 | 80 | Summary of Core TH1 Commands |
| 81 | 81 | ---------------------------- |
| 82 | 82 | |
| 83 | 83 | The original TCL language after when TH1 is modeled has a very rich |
| 84 | -repetoire of commands. TH1, as it is designed to be minimalist and | |
| 84 | +repertoire of commands. TH1, as it is designed to be minimalist and | |
| 85 | 85 | embedded has a greatly reduced command set. The following bullets |
| 86 | 86 | summarize the commands available in TH1: |
| 87 | 87 | |
| 88 | 88 | * break |
| 89 | 89 | * catch SCRIPT ?VARIABLE? |
| 90 | 90 |
| --- www/th1.md | |
| +++ www/th1.md | |
| @@ -79,11 +79,11 @@ | |
| 79 | |
| 80 | Summary of Core TH1 Commands |
| 81 | ---------------------------- |
| 82 | |
| 83 | The original TCL language after when TH1 is modeled has a very rich |
| 84 | repetoire of commands. TH1, as it is designed to be minimalist and |
| 85 | embedded has a greatly reduced command set. The following bullets |
| 86 | summarize the commands available in TH1: |
| 87 | |
| 88 | * break |
| 89 | * catch SCRIPT ?VARIABLE? |
| 90 |
| --- www/th1.md | |
| +++ www/th1.md | |
| @@ -79,11 +79,11 @@ | |
| 79 | |
| 80 | Summary of Core TH1 Commands |
| 81 | ---------------------------- |
| 82 | |
| 83 | The original TCL language after when TH1 is modeled has a very rich |
| 84 | repertoire of commands. TH1, as it is designed to be minimalist and |
| 85 | embedded has a greatly reduced command set. The following bullets |
| 86 | summarize the commands available in TH1: |
| 87 | |
| 88 | * break |
| 89 | * catch SCRIPT ?VARIABLE? |
| 90 |
+1
-1
| --- www/webui.wiki | ||
| +++ www/webui.wiki | ||
| @@ -104,11 +104,11 @@ | ||
| 104 | 104 | of time learning a new markup language. And, as with tickets, all of |
| 105 | 105 | your edits will automatically merge with those of your co-workers when |
| 106 | 106 | your repository synchronizes. |
| 107 | 107 | |
| 108 | 108 | You can view summary reports of <b>branches</b> in the |
| 109 | -check-in graph by visiting the "Branche" links on the | |
| 109 | +check-in graph by visiting the "Branches" link on the | |
| 110 | 110 | menu bar. From those pages you can follow hyperlinks to get additional |
| 111 | 111 | details. These screens allow you to easily keep track of what is going |
| 112 | 112 | on with separate subteams within your project team. |
| 113 | 113 | |
| 114 | 114 | The "Files" link on the menu allows you to browse though the <b>file |
| 115 | 115 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -104,11 +104,11 @@ | |
| 104 | of time learning a new markup language. And, as with tickets, all of |
| 105 | your edits will automatically merge with those of your co-workers when |
| 106 | your repository synchronizes. |
| 107 | |
| 108 | You can view summary reports of <b>branches</b> in the |
| 109 | check-in graph by visiting the "Branche" links on the |
| 110 | menu bar. From those pages you can follow hyperlinks to get additional |
| 111 | details. These screens allow you to easily keep track of what is going |
| 112 | on with separate subteams within your project team. |
| 113 | |
| 114 | The "Files" link on the menu allows you to browse though the <b>file |
| 115 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -104,11 +104,11 @@ | |
| 104 | of time learning a new markup language. And, as with tickets, all of |
| 105 | your edits will automatically merge with those of your co-workers when |
| 106 | your repository synchronizes. |
| 107 | |
| 108 | You can view summary reports of <b>branches</b> in the |
| 109 | check-in graph by visiting the "Branches" link on the |
| 110 | menu bar. From those pages you can follow hyperlinks to get additional |
| 111 | details. These screens allow you to easily keep track of what is going |
| 112 | on with separate subteams within your project team. |
| 113 | |
| 114 | The "Files" link on the menu allows you to browse though the <b>file |
| 115 |