Fossil SCM
Changes for the following files under www: password.wiki patchcmd.md pikchr.md quickstart.wiki rebaseharm.md selfcheck.wiki selfhost.wiki
Commit
445d1a86bac9ddf1800949a3a9019af7f473a56285021a594eea8bdb98e59bf7
Parent
601d09c1e97e3d9…
7 files changed
+1
-1
+4
-4
+2
-2
+1
-1
+2
-2
+1
-1
+1
-1
+1
-1
| --- www/password.wiki | ||
| +++ www/password.wiki | ||
| @@ -123,11 +123,11 @@ | ||
| 123 | 123 | </pre> |
| 124 | 124 | |
| 125 | 125 | For older clients, the password is used for the shared secret as stated |
| 126 | 126 | in the URL and with no encoding. |
| 127 | 127 | For newer clients, the shared secret is derived from the password |
| 128 | -by transformed the password using the SHA1 hash encoding | |
| 128 | +by transforming the password using the SHA1 hash encoding | |
| 129 | 129 | described above. However, if the first character of the password is |
| 130 | 130 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 131 | 131 | is used directly as the share secret without the SHA1 encoding. |
| 132 | 132 | |
| 133 | 133 | <pre> |
| 134 | 134 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -123,11 +123,11 @@ | |
| 123 | </pre> |
| 124 | |
| 125 | For older clients, the password is used for the shared secret as stated |
| 126 | in the URL and with no encoding. |
| 127 | For newer clients, the shared secret is derived from the password |
| 128 | by transformed the password using the SHA1 hash encoding |
| 129 | described above. However, if the first character of the password is |
| 130 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 131 | is used directly as the share secret without the SHA1 encoding. |
| 132 | |
| 133 | <pre> |
| 134 |
| --- www/password.wiki | |
| +++ www/password.wiki | |
| @@ -123,11 +123,11 @@ | |
| 123 | </pre> |
| 124 | |
| 125 | For older clients, the password is used for the shared secret as stated |
| 126 | in the URL and with no encoding. |
| 127 | For newer clients, the shared secret is derived from the password |
| 128 | by transforming the password using the SHA1 hash encoding |
| 129 | described above. However, if the first character of the password is |
| 130 | "*" (ASCII 0x2a) then the "*" is skipped and the rest of the password |
| 131 | is used directly as the share secret without the SHA1 encoding. |
| 132 | |
| 133 | <pre> |
| 134 |
+4
-4
| --- www/patchcmd.md | ||
| +++ www/patchcmd.md | ||
| @@ -9,11 +9,11 @@ | ||
| 9 | 9 | "fossil patch push" command to make a copy of all your changes on the |
| 10 | 10 | remote Linux server: |
| 11 | 11 | |
| 12 | 12 | fossil patch push linuxserver:/path/to/checkout |
| 13 | 13 | |
| 14 | -In the previous "linuxserver" is the name of the remote machine and | |
| 14 | +In the previous line "linuxserver" is the name of the remote machine and | |
| 15 | 15 | "/path/to/checkout" is an existing checkout directory for the same project |
| 16 | 16 | on the remote machine. |
| 17 | 17 | |
| 18 | 18 | The "fossil patch push" command works by first creating a patch file, |
| 19 | 19 | then transfering that patch file to the remote machine using "ssh", then |
| @@ -85,11 +85,11 @@ | ||
| 85 | 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | 87 | is a filename, then the patch-file database is written into that file. |
| 88 | 88 | If the argument is "-" then the database is written on standard output. |
| 89 | 89 | |
| 90 | -The "fossil patch apply" command reads the database that is the patch file | |
| 90 | +The "fossil patch apply" command reads the patch-file database | |
| 91 | 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | 92 | argument, then the database is read from that file. If the argument is "-" |
| 93 | 93 | then the database is read from standard input. |
| 94 | 94 | |
| 95 | 95 | Hence the command: |
| @@ -102,11 +102,11 @@ | ||
| 102 | 102 | |
| 103 | 103 | Likewise, a command like this: |
| 104 | 104 | |
| 105 | 105 | fossil patch pull remote:projB |
| 106 | 106 | |
| 107 | -Could be entered like this: | |
| 107 | +could be entered like this: | |
| 108 | 108 | |
| 109 | 109 | ssh -T remote 'cd projB;fossil patch create -' | fossil patch apply - |
| 110 | 110 | |
| 111 | -The "fossil patch view" command just opens the database file and prints | |
| 111 | +The "fossil patch view" command just opens the patch-file database and prints | |
| 112 | 112 | a summary of its contents on standard output. |
| 113 | 113 |
| --- www/patchcmd.md | |
| +++ www/patchcmd.md | |
| @@ -9,11 +9,11 @@ | |
| 9 | "fossil patch push" command to make a copy of all your changes on the |
| 10 | remote Linux server: |
| 11 | |
| 12 | fossil patch push linuxserver:/path/to/checkout |
| 13 | |
| 14 | In the previous "linuxserver" is the name of the remote machine and |
| 15 | "/path/to/checkout" is an existing checkout directory for the same project |
| 16 | on the remote machine. |
| 17 | |
| 18 | The "fossil patch push" command works by first creating a patch file, |
| 19 | then transfering that patch file to the remote machine using "ssh", then |
| @@ -85,11 +85,11 @@ | |
| 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | is a filename, then the patch-file database is written into that file. |
| 88 | If the argument is "-" then the database is written on standard output. |
| 89 | |
| 90 | The "fossil patch apply" command reads the database that is the patch file |
| 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | argument, then the database is read from that file. If the argument is "-" |
| 93 | then the database is read from standard input. |
| 94 | |
| 95 | Hence the command: |
| @@ -102,11 +102,11 @@ | |
| 102 | |
| 103 | Likewise, a command like this: |
| 104 | |
| 105 | fossil patch pull remote:projB |
| 106 | |
| 107 | Could be entered like this: |
| 108 | |
| 109 | ssh -T remote 'cd projB;fossil patch create -' | fossil patch apply - |
| 110 | |
| 111 | The "fossil patch view" command just opens the database file and prints |
| 112 | a summary of its contents on standard output. |
| 113 |
| --- www/patchcmd.md | |
| +++ www/patchcmd.md | |
| @@ -9,11 +9,11 @@ | |
| 9 | "fossil patch push" command to make a copy of all your changes on the |
| 10 | remote Linux server: |
| 11 | |
| 12 | fossil patch push linuxserver:/path/to/checkout |
| 13 | |
| 14 | In the previous line "linuxserver" is the name of the remote machine and |
| 15 | "/path/to/checkout" is an existing checkout directory for the same project |
| 16 | on the remote machine. |
| 17 | |
| 18 | The "fossil patch push" command works by first creating a patch file, |
| 19 | then transfering that patch file to the remote machine using "ssh", then |
| @@ -85,11 +85,11 @@ | |
| 85 | The "fossil patch create" command records all of the local, uncommitted |
| 86 | changes in an SQLite database file. If the argument to "fossil patch create" |
| 87 | is a filename, then the patch-file database is written into that file. |
| 88 | If the argument is "-" then the database is written on standard output. |
| 89 | |
| 90 | The "fossil patch apply" command reads the patch-file database |
| 91 | and applies it to the local check-out. If a filename is given as an |
| 92 | argument, then the database is read from that file. If the argument is "-" |
| 93 | then the database is read from standard input. |
| 94 | |
| 95 | Hence the command: |
| @@ -102,11 +102,11 @@ | |
| 102 | |
| 103 | Likewise, a command like this: |
| 104 | |
| 105 | fossil patch pull remote:projB |
| 106 | |
| 107 | could be entered like this: |
| 108 | |
| 109 | ssh -T remote 'cd projB;fossil patch create -' | fossil patch apply - |
| 110 | |
| 111 | The "fossil patch view" command just opens the patch-file database and prints |
| 112 | a summary of its contents on standard output. |
| 113 |
+2
-2
| --- www/pikchr.md | ||
| +++ www/pikchr.md | ||
| @@ -1,9 +1,9 @@ | ||
| 1 | 1 | # The Pikchr Diagram Language |
| 2 | 2 | |
| 3 | 3 | Pikchr (pronounced "picture") is a [PIC][1]-like markup language for creating |
| 4 | -diagrams in technical documentation. Pikchr diagrams source text | |
| 4 | +diagrams in technical documentation. Source text for Pikchr diagrams | |
| 5 | 5 | can be embedded directly in either [Markdown][2] or [Fossil Wiki][3]. |
| 6 | 6 | Fossil translates the Pikchr source text into SVG which is displayed as |
| 7 | 7 | part of the rendered wiki. |
| 8 | 8 | |
| 9 | 9 | [1]: wikipedia:/wiki/Pic_language |
| @@ -134,6 +134,6 @@ | ||
| 134 | 134 | |
| 135 | 135 | * **float-right** → The diagram is shown at the right margin and |
| 136 | 136 | text fills in around the diagram. |
| 137 | 137 | |
| 138 | 138 | * **source** → The display starts out showing the Pikchr source text. |
| 139 | - The reader must click (or Alt-click or Ctrl-click) to set the diagram. | |
| 139 | + The reader must click (or Alt-click or Ctrl-click) to show the diagram. | |
| 140 | 140 |
| --- www/pikchr.md | |
| +++ www/pikchr.md | |
| @@ -1,9 +1,9 @@ | |
| 1 | # The Pikchr Diagram Language |
| 2 | |
| 3 | Pikchr (pronounced "picture") is a [PIC][1]-like markup language for creating |
| 4 | diagrams in technical documentation. Pikchr diagrams source text |
| 5 | can be embedded directly in either [Markdown][2] or [Fossil Wiki][3]. |
| 6 | Fossil translates the Pikchr source text into SVG which is displayed as |
| 7 | part of the rendered wiki. |
| 8 | |
| 9 | [1]: wikipedia:/wiki/Pic_language |
| @@ -134,6 +134,6 @@ | |
| 134 | |
| 135 | * **float-right** → The diagram is shown at the right margin and |
| 136 | text fills in around the diagram. |
| 137 | |
| 138 | * **source** → The display starts out showing the Pikchr source text. |
| 139 | The reader must click (or Alt-click or Ctrl-click) to set the diagram. |
| 140 |
| --- www/pikchr.md | |
| +++ www/pikchr.md | |
| @@ -1,9 +1,9 @@ | |
| 1 | # The Pikchr Diagram Language |
| 2 | |
| 3 | Pikchr (pronounced "picture") is a [PIC][1]-like markup language for creating |
| 4 | diagrams in technical documentation. Source text for Pikchr diagrams |
| 5 | can be embedded directly in either [Markdown][2] or [Fossil Wiki][3]. |
| 6 | Fossil translates the Pikchr source text into SVG which is displayed as |
| 7 | part of the rendered wiki. |
| 8 | |
| 9 | [1]: wikipedia:/wiki/Pic_language |
| @@ -134,6 +134,6 @@ | |
| 134 | |
| 135 | * **float-right** → The diagram is shown at the right margin and |
| 136 | text fills in around the diagram. |
| 137 | |
| 138 | * **source** → The display starts out showing the Pikchr source text. |
| 139 | The reader must click (or Alt-click or Ctrl-click) to show the diagram. |
| 140 |
+1
-1
| --- www/quickstart.wiki | ||
| +++ www/quickstart.wiki | ||
| @@ -364,11 +364,11 @@ | ||
| 364 | 364 | abbreviation to the 40-character |
| 365 | 365 | artifact identifier for a particular check-in, or it can be a |
| 366 | 366 | date/time stamp. ([./checkin_names.wiki | more info]) |
| 367 | 367 | If you omit |
| 368 | 368 | the <i>VERSION</i>, then fossil moves you to the |
| 369 | -latest version of the branch your are currently on. | |
| 369 | +latest version of the branch you are currently on. | |
| 370 | 370 | |
| 371 | 371 | The default behavior is for [./concepts.wiki#workflow|autosync] to |
| 372 | 372 | be turned on. That means that a [/help/pull|pull] automatically occurs |
| 373 | 373 | when you run [/help/update|update] and a [/help/push|push] happens |
| 374 | 374 | automatically after you [/help/commit|commit]. So in normal practice, |
| 375 | 375 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -364,11 +364,11 @@ | |
| 364 | abbreviation to the 40-character |
| 365 | artifact identifier for a particular check-in, or it can be a |
| 366 | date/time stamp. ([./checkin_names.wiki | more info]) |
| 367 | If you omit |
| 368 | the <i>VERSION</i>, then fossil moves you to the |
| 369 | latest version of the branch your are currently on. |
| 370 | |
| 371 | The default behavior is for [./concepts.wiki#workflow|autosync] to |
| 372 | be turned on. That means that a [/help/pull|pull] automatically occurs |
| 373 | when you run [/help/update|update] and a [/help/push|push] happens |
| 374 | automatically after you [/help/commit|commit]. So in normal practice, |
| 375 |
| --- www/quickstart.wiki | |
| +++ www/quickstart.wiki | |
| @@ -364,11 +364,11 @@ | |
| 364 | abbreviation to the 40-character |
| 365 | artifact identifier for a particular check-in, or it can be a |
| 366 | date/time stamp. ([./checkin_names.wiki | more info]) |
| 367 | If you omit |
| 368 | the <i>VERSION</i>, then fossil moves you to the |
| 369 | latest version of the branch you are currently on. |
| 370 | |
| 371 | The default behavior is for [./concepts.wiki#workflow|autosync] to |
| 372 | be turned on. That means that a [/help/pull|pull] automatically occurs |
| 373 | when you run [/help/update|update] and a [/help/push|push] happens |
| 374 | automatically after you [/help/commit|commit]. So in normal practice, |
| 375 |
+2
-2
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -224,16 +224,16 @@ | ||
| 224 | 224 | you are keeping private branches. Or, to put it another way, you are |
| 225 | 225 | doing siloed development. You are not sharing your intermediate work |
| 226 | 226 | with collaborators. This is not good for product quality. |
| 227 | 227 | |
| 228 | 228 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 229 | -that best predictor of bugs is the distance on the org-chart between | |
| 229 | +that the best predictor of bugs is the distance on the org-chart between | |
| 230 | 230 | the stake-holders. The bug rate is inversely related to the |
| 231 | 231 | amount of communication among the engineers. |
| 232 | 232 | Similar findings arise in other disciplines. Keeping |
| 233 | 233 | private branches does not prove that developers are communicating |
| 234 | -insufficiently, but it is a key symptom that problem. | |
| 234 | +insufficiently, but it is a key symptom of that problem. | |
| 235 | 235 | |
| 236 | 236 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 237 | 237 | is to say, programmers should avoid linking their code with their sense of |
| 238 | 238 | self, as that makes it more difficult for them to find and respond |
| 239 | 239 | to bugs, and hence makes them less productive. Many developers are |
| 240 | 240 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -224,16 +224,16 @@ | |
| 224 | you are keeping private branches. Or, to put it another way, you are |
| 225 | doing siloed development. You are not sharing your intermediate work |
| 226 | with collaborators. This is not good for product quality. |
| 227 | |
| 228 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 229 | that best predictor of bugs is the distance on the org-chart between |
| 230 | the stake-holders. The bug rate is inversely related to the |
| 231 | amount of communication among the engineers. |
| 232 | Similar findings arise in other disciplines. Keeping |
| 233 | private branches does not prove that developers are communicating |
| 234 | insufficiently, but it is a key symptom that problem. |
| 235 | |
| 236 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 237 | is to say, programmers should avoid linking their code with their sense of |
| 238 | self, as that makes it more difficult for them to find and respond |
| 239 | to bugs, and hence makes them less productive. Many developers are |
| 240 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -224,16 +224,16 @@ | |
| 224 | you are keeping private branches. Or, to put it another way, you are |
| 225 | doing siloed development. You are not sharing your intermediate work |
| 226 | with collaborators. This is not good for product quality. |
| 227 | |
| 228 | [Nagappan, et. al][nagappan] studied bugs in Windows Vista and found |
| 229 | that the best predictor of bugs is the distance on the org-chart between |
| 230 | the stake-holders. The bug rate is inversely related to the |
| 231 | amount of communication among the engineers. |
| 232 | Similar findings arise in other disciplines. Keeping |
| 233 | private branches does not prove that developers are communicating |
| 234 | insufficiently, but it is a key symptom of that problem. |
| 235 | |
| 236 | [Weinberg][weinberg] argues programming should be "egoless." That |
| 237 | is to say, programmers should avoid linking their code with their sense of |
| 238 | self, as that makes it more difficult for them to find and respond |
| 239 | to bugs, and hence makes them less productive. Many developers are |
| 240 |
+1
-1
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -13,11 +13,11 @@ | ||
| 13 | 13 | |
| 14 | 14 | <h2>Atomic Check-ins With Rollback</h2> |
| 15 | 15 | |
| 16 | 16 | The Fossil repository is stored in an |
| 17 | 17 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 18 | -([./tech_overview.wiki | Addition information] about the repository | |
| 18 | +([./tech_overview.wiki | Additional information] about the repository | |
| 19 | 19 | file format.) |
| 20 | 20 | SQLite is very mature and stable and has been in wide-spread use for many |
| 21 | 21 | years, so we are confident it will not cause repository |
| 22 | 22 | corruption. SQLite |
| 23 | 23 | databases do not corrupt even if a program or system crash or power |
| 24 | 24 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | |
| 14 | <h2>Atomic Check-ins With Rollback</h2> |
| 15 | |
| 16 | The Fossil repository is stored in an |
| 17 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 18 | ([./tech_overview.wiki | Addition information] about the repository |
| 19 | file format.) |
| 20 | SQLite is very mature and stable and has been in wide-spread use for many |
| 21 | years, so we are confident it will not cause repository |
| 22 | corruption. SQLite |
| 23 | databases do not corrupt even if a program or system crash or power |
| 24 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | |
| 14 | <h2>Atomic Check-ins With Rollback</h2> |
| 15 | |
| 16 | The Fossil repository is stored in an |
| 17 | <a href="http://www.sqlite.org/">SQLite</a> database file. |
| 18 | ([./tech_overview.wiki | Additional information] about the repository |
| 19 | file format.) |
| 20 | SQLite is very mature and stable and has been in wide-spread use for many |
| 21 | years, so we are confident it will not cause repository |
| 22 | corruption. SQLite |
| 23 | databases do not corrupt even if a program or system crash or power |
| 24 |
+1
-1
| --- www/selfhost.wiki | ||
| +++ www/selfhost.wiki | ||
| @@ -27,11 +27,11 @@ | ||
| 27 | 27 | hosts <a href="http://www.sqlite.org/">SQLite</a> and over a |
| 28 | 28 | dozen other smaller projects. This demonstrates that Fossil can run on |
| 29 | 29 | a low-power host processor. |
| 30 | 30 | Multiple fossil-based projects can easily be hosted on the same machine, |
| 31 | 31 | even if that machine is itself one of several dozen virtual machines on |
| 32 | -single physical box. The CGI script that runs the canonical Fossil | |
| 32 | +a single physical box. The CGI script that runs the canonical Fossil | |
| 33 | 33 | self-hosting repository is as follows: |
| 34 | 34 | |
| 35 | 35 | <pre> |
| 36 | 36 | #!/usr/bin/fossil |
| 37 | 37 | repository: /fossil/fossil.fossil |
| 38 | 38 |
| --- www/selfhost.wiki | |
| +++ www/selfhost.wiki | |
| @@ -27,11 +27,11 @@ | |
| 27 | hosts <a href="http://www.sqlite.org/">SQLite</a> and over a |
| 28 | dozen other smaller projects. This demonstrates that Fossil can run on |
| 29 | a low-power host processor. |
| 30 | Multiple fossil-based projects can easily be hosted on the same machine, |
| 31 | even if that machine is itself one of several dozen virtual machines on |
| 32 | single physical box. The CGI script that runs the canonical Fossil |
| 33 | self-hosting repository is as follows: |
| 34 | |
| 35 | <pre> |
| 36 | #!/usr/bin/fossil |
| 37 | repository: /fossil/fossil.fossil |
| 38 |
| --- www/selfhost.wiki | |
| +++ www/selfhost.wiki | |
| @@ -27,11 +27,11 @@ | |
| 27 | hosts <a href="http://www.sqlite.org/">SQLite</a> and over a |
| 28 | dozen other smaller projects. This demonstrates that Fossil can run on |
| 29 | a low-power host processor. |
| 30 | Multiple fossil-based projects can easily be hosted on the same machine, |
| 31 | even if that machine is itself one of several dozen virtual machines on |
| 32 | a single physical box. The CGI script that runs the canonical Fossil |
| 33 | self-hosting repository is as follows: |
| 34 | |
| 35 | <pre> |
| 36 | #!/usr/bin/fossil |
| 37 | repository: /fossil/fossil.fossil |
| 38 |