Fossil SCM
Merge brickviking's documentation typo fixes to trunk.
Commit
efd79f87f55bcfafb3ac8336d71951f2e9f154b48d0f560e0e8fee96dcc00fb7
Parent
d0730da076b9304…
13 files changed
+4
-4
+3
-3
+2
-2
+3
-3
+2
-2
+6
-6
+2
-2
+2
-2
+2
-2
+1
-1
+4
-4
+1
-1
+2
-2
+4
-4
| --- www/aboutcgi.wiki | ||
| +++ www/aboutcgi.wiki | ||
| @@ -8,30 +8,30 @@ | ||
| 8 | 8 | |
| 9 | 9 | This is a "how it works" guide. This document provides background |
| 10 | 10 | information on the CGI protocol so that you can better understand what |
| 11 | 11 | is going on behind the scenes. If you just want to set up Fossil |
| 12 | 12 | as a CGI server, see the [./server/ | Fossil Server Setup] page. Or |
| 13 | -if you want to development CGI-based extensions to Fossil, see | |
| 13 | +if you want to develop CGI-based extensions to Fossil, see | |
| 14 | 14 | the [./serverext.wiki|CGI Server Extensions] page. |
| 15 | 15 | |
| 16 | 16 | <h2>A Quick Review Of CGI</h2> |
| 17 | 17 | |
| 18 | 18 | An HTTP request is a block of text that is sent by a client application |
| 19 | 19 | (usually a web browser) and arrives at the web server over a network |
| 20 | 20 | connection. The HTTP request contains a URL that describes the information |
| 21 | 21 | being requested. The URL in the HTTP request is typically the same URL |
| 22 | 22 | that appears in the URL bar at the top of the web browser that is making |
| 23 | -the request. The URL might contain a "?" character followed | |
| 23 | +the request. The URL might contain a "?" character followed by | |
| 24 | 24 | query parameters. The HTTP will usually also contain other information |
| 25 | 25 | such as the name of the application that made the request, whether or |
| 26 | 26 | not the requesting application can accept a compressed reply, POST |
| 27 | 27 | parameters from forms, and so forth. |
| 28 | 28 | |
| 29 | 29 | The job of the web server is to interpret the HTTP request and formulate |
| 30 | 30 | an appropriate reply. |
| 31 | -The web server is free to interpret the HTTP request in any way it wants. | |
| 32 | -But most web servers follow a similar pattern, described below. | |
| 31 | +The web server is free to interpret the HTTP request in any way it wants, | |
| 32 | +but most web servers follow a similar pattern, described below. | |
| 33 | 33 | (Note: details may vary from one web server to another.) |
| 34 | 34 | |
| 35 | 35 | Suppose the filename component of the URL in the HTTP request looks like this: |
| 36 | 36 | |
| 37 | 37 | <pre>/one/two/timeline/four</pre> |
| 38 | 38 |
| --- www/aboutcgi.wiki | |
| +++ www/aboutcgi.wiki | |
| @@ -8,30 +8,30 @@ | |
| 8 | |
| 9 | This is a "how it works" guide. This document provides background |
| 10 | information on the CGI protocol so that you can better understand what |
| 11 | is going on behind the scenes. If you just want to set up Fossil |
| 12 | as a CGI server, see the [./server/ | Fossil Server Setup] page. Or |
| 13 | if you want to development CGI-based extensions to Fossil, see |
| 14 | the [./serverext.wiki|CGI Server Extensions] page. |
| 15 | |
| 16 | <h2>A Quick Review Of CGI</h2> |
| 17 | |
| 18 | An HTTP request is a block of text that is sent by a client application |
| 19 | (usually a web browser) and arrives at the web server over a network |
| 20 | connection. The HTTP request contains a URL that describes the information |
| 21 | being requested. The URL in the HTTP request is typically the same URL |
| 22 | that appears in the URL bar at the top of the web browser that is making |
| 23 | the request. The URL might contain a "?" character followed |
| 24 | query parameters. The HTTP will usually also contain other information |
| 25 | such as the name of the application that made the request, whether or |
| 26 | not the requesting application can accept a compressed reply, POST |
| 27 | parameters from forms, and so forth. |
| 28 | |
| 29 | The job of the web server is to interpret the HTTP request and formulate |
| 30 | an appropriate reply. |
| 31 | The web server is free to interpret the HTTP request in any way it wants. |
| 32 | But most web servers follow a similar pattern, described below. |
| 33 | (Note: details may vary from one web server to another.) |
| 34 | |
| 35 | Suppose the filename component of the URL in the HTTP request looks like this: |
| 36 | |
| 37 | <pre>/one/two/timeline/four</pre> |
| 38 |
| --- www/aboutcgi.wiki | |
| +++ www/aboutcgi.wiki | |
| @@ -8,30 +8,30 @@ | |
| 8 | |
| 9 | This is a "how it works" guide. This document provides background |
| 10 | information on the CGI protocol so that you can better understand what |
| 11 | is going on behind the scenes. If you just want to set up Fossil |
| 12 | as a CGI server, see the [./server/ | Fossil Server Setup] page. Or |
| 13 | if you want to develop CGI-based extensions to Fossil, see |
| 14 | the [./serverext.wiki|CGI Server Extensions] page. |
| 15 | |
| 16 | <h2>A Quick Review Of CGI</h2> |
| 17 | |
| 18 | An HTTP request is a block of text that is sent by a client application |
| 19 | (usually a web browser) and arrives at the web server over a network |
| 20 | connection. The HTTP request contains a URL that describes the information |
| 21 | being requested. The URL in the HTTP request is typically the same URL |
| 22 | that appears in the URL bar at the top of the web browser that is making |
| 23 | the request. The URL might contain a "?" character followed by |
| 24 | query parameters. The HTTP will usually also contain other information |
| 25 | such as the name of the application that made the request, whether or |
| 26 | not the requesting application can accept a compressed reply, POST |
| 27 | parameters from forms, and so forth. |
| 28 | |
| 29 | The job of the web server is to interpret the HTTP request and formulate |
| 30 | an appropriate reply. |
| 31 | The web server is free to interpret the HTTP request in any way it wants, |
| 32 | but most web servers follow a similar pattern, described below. |
| 33 | (Note: details may vary from one web server to another.) |
| 34 | |
| 35 | Suppose the filename component of the URL in the HTTP request looks like this: |
| 36 | |
| 37 | <pre>/one/two/timeline/four</pre> |
| 38 |
+3
-3
| --- www/adding_code.wiki | ||
| +++ www/adding_code.wiki | ||
| @@ -37,11 +37,11 @@ | ||
| 37 | 37 | The [./makefile.wiki|Makefile] for Fossil takes care of running these |
| 38 | 38 | preprocessors with all the right arguments and in the right order. So it is |
| 39 | 39 | not necessary to understand the details of how these preprocessors work. |
| 40 | 40 | (Though, the sources for all three preprocessors are included in the source |
| 41 | 41 | tree and are well commented, if you want to dig deeper.) It is only necessary |
| 42 | -to know that these preprocessors exist and hence will effect the way you | |
| 42 | +to know that these preprocessors exist and hence will affect the way you | |
| 43 | 43 | write code. |
| 44 | 44 | |
| 45 | 45 | <h2>3.0 Adding New Source Code Files</h2> |
| 46 | 46 | |
| 47 | 47 | New source code files are added in the "src/" subdirectory of the Fossil |
| @@ -98,11 +98,11 @@ | ||
| 98 | 98 | files. See [../tools/makeheaders.html | makeheaders.html] for additional |
| 99 | 99 | information. |
| 100 | 100 | |
| 101 | 101 | After creating a template file such as shown above, and after updating |
| 102 | 102 | the makefiles, you should be able to recompile Fossil and have it include |
| 103 | -your new source file, even before you source file contains any code. | |
| 103 | +your new source file, even before your source file contains any code. | |
| 104 | 104 | It is recommended that you try this. |
| 105 | 105 | |
| 106 | 106 | Be sure to [/help/add|fossil add] your new source file to the self-hosting |
| 107 | 107 | Fossil repository and then [/help/commit|commit] your changes! |
| 108 | 108 | |
| @@ -212,11 +212,11 @@ | ||
| 212 | 212 | non-HTML content. In the unlikely event that you need to generate |
| 213 | 213 | non-HTML content, look at existing webpage implementations |
| 214 | 214 | (ex: "logo" or "style.css") to see how that is done. |
| 215 | 215 | |
| 216 | 216 | There are lots of other things that a real web-page implementation will |
| 217 | -need to do, such verifying user credentials, parsing query parameters, | |
| 217 | +need to do, such as verifying user credentials, parsing query parameters, | |
| 218 | 218 | and interacting with the repository. But now that you have the general |
| 219 | 219 | idea of how webpages are implemented, you can look at the many other |
| 220 | 220 | webpage implementations already built into Fossil to see how all that |
| 221 | 221 | works. |
| 222 | 222 | |
| 223 | 223 |
| --- www/adding_code.wiki | |
| +++ www/adding_code.wiki | |
| @@ -37,11 +37,11 @@ | |
| 37 | The [./makefile.wiki|Makefile] for Fossil takes care of running these |
| 38 | preprocessors with all the right arguments and in the right order. So it is |
| 39 | not necessary to understand the details of how these preprocessors work. |
| 40 | (Though, the sources for all three preprocessors are included in the source |
| 41 | tree and are well commented, if you want to dig deeper.) It is only necessary |
| 42 | to know that these preprocessors exist and hence will effect the way you |
| 43 | write code. |
| 44 | |
| 45 | <h2>3.0 Adding New Source Code Files</h2> |
| 46 | |
| 47 | New source code files are added in the "src/" subdirectory of the Fossil |
| @@ -98,11 +98,11 @@ | |
| 98 | files. See [../tools/makeheaders.html | makeheaders.html] for additional |
| 99 | information. |
| 100 | |
| 101 | After creating a template file such as shown above, and after updating |
| 102 | the makefiles, you should be able to recompile Fossil and have it include |
| 103 | your new source file, even before you source file contains any code. |
| 104 | It is recommended that you try this. |
| 105 | |
| 106 | Be sure to [/help/add|fossil add] your new source file to the self-hosting |
| 107 | Fossil repository and then [/help/commit|commit] your changes! |
| 108 | |
| @@ -212,11 +212,11 @@ | |
| 212 | non-HTML content. In the unlikely event that you need to generate |
| 213 | non-HTML content, look at existing webpage implementations |
| 214 | (ex: "logo" or "style.css") to see how that is done. |
| 215 | |
| 216 | There are lots of other things that a real web-page implementation will |
| 217 | need to do, such verifying user credentials, parsing query parameters, |
| 218 | and interacting with the repository. But now that you have the general |
| 219 | idea of how webpages are implemented, you can look at the many other |
| 220 | webpage implementations already built into Fossil to see how all that |
| 221 | works. |
| 222 | |
| 223 |
| --- www/adding_code.wiki | |
| +++ www/adding_code.wiki | |
| @@ -37,11 +37,11 @@ | |
| 37 | The [./makefile.wiki|Makefile] for Fossil takes care of running these |
| 38 | preprocessors with all the right arguments and in the right order. So it is |
| 39 | not necessary to understand the details of how these preprocessors work. |
| 40 | (Though, the sources for all three preprocessors are included in the source |
| 41 | tree and are well commented, if you want to dig deeper.) It is only necessary |
| 42 | to know that these preprocessors exist and hence will affect the way you |
| 43 | write code. |
| 44 | |
| 45 | <h2>3.0 Adding New Source Code Files</h2> |
| 46 | |
| 47 | New source code files are added in the "src/" subdirectory of the Fossil |
| @@ -98,11 +98,11 @@ | |
| 98 | files. See [../tools/makeheaders.html | makeheaders.html] for additional |
| 99 | information. |
| 100 | |
| 101 | After creating a template file such as shown above, and after updating |
| 102 | the makefiles, you should be able to recompile Fossil and have it include |
| 103 | your new source file, even before your source file contains any code. |
| 104 | It is recommended that you try this. |
| 105 | |
| 106 | Be sure to [/help/add|fossil add] your new source file to the self-hosting |
| 107 | Fossil repository and then [/help/commit|commit] your changes! |
| 108 | |
| @@ -212,11 +212,11 @@ | |
| 212 | non-HTML content. In the unlikely event that you need to generate |
| 213 | non-HTML content, look at existing webpage implementations |
| 214 | (ex: "logo" or "style.css") to see how that is done. |
| 215 | |
| 216 | There are lots of other things that a real web-page implementation will |
| 217 | need to do, such as verifying user credentials, parsing query parameters, |
| 218 | and interacting with the repository. But now that you have the general |
| 219 | idea of how webpages are implemented, you can look at the many other |
| 220 | webpage implementations already built into Fossil to see how all that |
| 221 | works. |
| 222 | |
| 223 |
+2
-2
| --- www/antibot.wiki | ||
| +++ www/antibot.wiki | ||
| @@ -73,17 +73,17 @@ | ||
| 73 | 73 | In Fossil, under the Admin/Robot-Defense menu, there is a setting entitled |
| 74 | 74 | "<b>Enable hyperlinks based on User-Agent and/or Javascript</b>". |
| 75 | 75 | If this setting is set to "UserAgent only" or "UserAgent and Javascript", |
| 76 | 76 | and if the UserAgent string looks like a human and not a robot, then |
| 77 | 77 | Fossil will enable hyperlinks even if the <b>Hyperlink</b> capability |
| 78 | -is omitted from the user permissions. This settingn gives humans easy | |
| 78 | +is omitted from the user permissions. This setting gives humans easy | |
| 79 | 79 | access to the hyperlinks while preventing robots |
| 80 | 80 | from walking the billions of pages on a typical Fossil site. |
| 81 | 81 | |
| 82 | 82 | If the setting is "UserAgent only", then the hyperlinks are simply |
| 83 | 83 | enabled and that is all. But if the setting is "UserAgent and Javascript", |
| 84 | -then the hyperlinks are not enabled directly . | |
| 84 | +then the hyperlinks are not enabled directly. | |
| 85 | 85 | Instead, the HTML code that is generated contains anchor tags ("<a>") |
| 86 | 86 | with "href=" attributes that point to [/honeypot] rather than the correct |
| 87 | 87 | link. JavaScript code is added to the end of the page that goes back and |
| 88 | 88 | fills in the correct "href=" attributes of |
| 89 | 89 | the anchor tags with the true hyperlink targets, thus enabling the hyperlinks. |
| 90 | 90 |
| --- www/antibot.wiki | |
| +++ www/antibot.wiki | |
| @@ -73,17 +73,17 @@ | |
| 73 | In Fossil, under the Admin/Robot-Defense menu, there is a setting entitled |
| 74 | "<b>Enable hyperlinks based on User-Agent and/or Javascript</b>". |
| 75 | If this setting is set to "UserAgent only" or "UserAgent and Javascript", |
| 76 | and if the UserAgent string looks like a human and not a robot, then |
| 77 | Fossil will enable hyperlinks even if the <b>Hyperlink</b> capability |
| 78 | is omitted from the user permissions. This settingn gives humans easy |
| 79 | access to the hyperlinks while preventing robots |
| 80 | from walking the billions of pages on a typical Fossil site. |
| 81 | |
| 82 | If the setting is "UserAgent only", then the hyperlinks are simply |
| 83 | enabled and that is all. But if the setting is "UserAgent and Javascript", |
| 84 | then the hyperlinks are not enabled directly . |
| 85 | Instead, the HTML code that is generated contains anchor tags ("<a>") |
| 86 | with "href=" attributes that point to [/honeypot] rather than the correct |
| 87 | link. JavaScript code is added to the end of the page that goes back and |
| 88 | fills in the correct "href=" attributes of |
| 89 | the anchor tags with the true hyperlink targets, thus enabling the hyperlinks. |
| 90 |
| --- www/antibot.wiki | |
| +++ www/antibot.wiki | |
| @@ -73,17 +73,17 @@ | |
| 73 | In Fossil, under the Admin/Robot-Defense menu, there is a setting entitled |
| 74 | "<b>Enable hyperlinks based on User-Agent and/or Javascript</b>". |
| 75 | If this setting is set to "UserAgent only" or "UserAgent and Javascript", |
| 76 | and if the UserAgent string looks like a human and not a robot, then |
| 77 | Fossil will enable hyperlinks even if the <b>Hyperlink</b> capability |
| 78 | is omitted from the user permissions. This setting gives humans easy |
| 79 | access to the hyperlinks while preventing robots |
| 80 | from walking the billions of pages on a typical Fossil site. |
| 81 | |
| 82 | If the setting is "UserAgent only", then the hyperlinks are simply |
| 83 | enabled and that is all. But if the setting is "UserAgent and Javascript", |
| 84 | then the hyperlinks are not enabled directly. |
| 85 | Instead, the HTML code that is generated contains anchor tags ("<a>") |
| 86 | with "href=" attributes that point to [/honeypot] rather than the correct |
| 87 | link. JavaScript code is added to the end of the page that goes back and |
| 88 | fills in the correct "href=" attributes of |
| 89 | the anchor tags with the true hyperlink targets, thus enabling the hyperlinks. |
| 90 |
+3
-3
| --- www/backoffice.md | ||
| +++ www/backoffice.md | ||
| @@ -115,14 +115,14 @@ | ||
| 115 | 115 | launching the backoffice for all of them. There are additional useful |
| 116 | 116 | command-line options. See the "[fossil backoffice](/help?cmd=backoffice)" |
| 117 | 117 | documentation for details. |
| 118 | 118 | |
| 119 | 119 | The backoffice processes run manually using the "fossil backoffice" |
| 120 | -command do not normally use a lease. That means that you run the | |
| 120 | +command do not normally use a lease. That means that if you run the | |
| 121 | 121 | "fossil backoffice" command with --poll and you forget to disable |
| 122 | 122 | automatic backoffice by setting the "backoffice-disable" flag, then |
| 123 | -you might have one backoffice running due command and another due | |
| 123 | +you might have one backoffice running due to a command and another due | |
| 124 | 124 | to a webpage access, both at the same time. This is harmless. The |
| 125 | 125 | only downside is that it uses extra CPU time. |
| 126 | 126 | |
| 127 | 127 | How Backoffice Is Implemented |
| 128 | 128 | ----------------------------- |
| @@ -210,11 +210,11 @@ | ||
| 210 | 210 | backoffice processes to exit either immediately or after doing whatever |
| 211 | 211 | backoffice works needs to be done. If something is going wrong and |
| 212 | 212 | backoffice leases are causing delays in webpage processing, then setting |
| 213 | 213 | "backoffice-nodelay" to true can work around the problem until the bug |
| 214 | 214 | can be fixed. The "backoffice-logfile" setting is the name of a log |
| 215 | -file onto which is appended a short message everything a backoffice | |
| 215 | +file onto which is appended a short message every time a backoffice | |
| 216 | 216 | process actually starts to do the backoffice work. This log file can |
| 217 | 217 | be used to verify that backoffice really is running, if there is any |
| 218 | 218 | doubt. The "backoffice-disable" setting prevents automatic backoffice |
| 219 | 219 | processing, if true. Use this to completely disable backoffice processing |
| 220 | 220 | that occurs automatically after each HTTP request. The "backoffice-disable" |
| 221 | 221 |
| --- www/backoffice.md | |
| +++ www/backoffice.md | |
| @@ -115,14 +115,14 @@ | |
| 115 | launching the backoffice for all of them. There are additional useful |
| 116 | command-line options. See the "[fossil backoffice](/help?cmd=backoffice)" |
| 117 | documentation for details. |
| 118 | |
| 119 | The backoffice processes run manually using the "fossil backoffice" |
| 120 | command do not normally use a lease. That means that you run the |
| 121 | "fossil backoffice" command with --poll and you forget to disable |
| 122 | automatic backoffice by setting the "backoffice-disable" flag, then |
| 123 | you might have one backoffice running due command and another due |
| 124 | to a webpage access, both at the same time. This is harmless. The |
| 125 | only downside is that it uses extra CPU time. |
| 126 | |
| 127 | How Backoffice Is Implemented |
| 128 | ----------------------------- |
| @@ -210,11 +210,11 @@ | |
| 210 | backoffice processes to exit either immediately or after doing whatever |
| 211 | backoffice works needs to be done. If something is going wrong and |
| 212 | backoffice leases are causing delays in webpage processing, then setting |
| 213 | "backoffice-nodelay" to true can work around the problem until the bug |
| 214 | can be fixed. The "backoffice-logfile" setting is the name of a log |
| 215 | file onto which is appended a short message everything a backoffice |
| 216 | process actually starts to do the backoffice work. This log file can |
| 217 | be used to verify that backoffice really is running, if there is any |
| 218 | doubt. The "backoffice-disable" setting prevents automatic backoffice |
| 219 | processing, if true. Use this to completely disable backoffice processing |
| 220 | that occurs automatically after each HTTP request. The "backoffice-disable" |
| 221 |
| --- www/backoffice.md | |
| +++ www/backoffice.md | |
| @@ -115,14 +115,14 @@ | |
| 115 | launching the backoffice for all of them. There are additional useful |
| 116 | command-line options. See the "[fossil backoffice](/help?cmd=backoffice)" |
| 117 | documentation for details. |
| 118 | |
| 119 | The backoffice processes run manually using the "fossil backoffice" |
| 120 | command do not normally use a lease. That means that if you run the |
| 121 | "fossil backoffice" command with --poll and you forget to disable |
| 122 | automatic backoffice by setting the "backoffice-disable" flag, then |
| 123 | you might have one backoffice running due to a command and another due |
| 124 | to a webpage access, both at the same time. This is harmless. The |
| 125 | only downside is that it uses extra CPU time. |
| 126 | |
| 127 | How Backoffice Is Implemented |
| 128 | ----------------------------- |
| @@ -210,11 +210,11 @@ | |
| 210 | backoffice processes to exit either immediately or after doing whatever |
| 211 | backoffice works needs to be done. If something is going wrong and |
| 212 | backoffice leases are causing delays in webpage processing, then setting |
| 213 | "backoffice-nodelay" to true can work around the problem until the bug |
| 214 | can be fixed. The "backoffice-logfile" setting is the name of a log |
| 215 | file onto which is appended a short message every time a backoffice |
| 216 | process actually starts to do the backoffice work. This log file can |
| 217 | be used to verify that backoffice really is running, if there is any |
| 218 | doubt. The "backoffice-disable" setting prevents automatic backoffice |
| 219 | processing, if true. Use this to completely disable backoffice processing |
| 220 | that occurs automatically after each HTTP request. The "backoffice-disable" |
| 221 |
+2
-2
| --- www/blame.wiki | ||
| +++ www/blame.wiki | ||
| @@ -19,11 +19,11 @@ | ||
| 19 | 19 | annotated. Call this check-in C0. |
| 20 | 20 | <li>Find all direct ancestors of C0. A direct ancestor is the closure |
| 21 | 21 | of the primary parent of C0. Merged in branches are not part of |
| 22 | 22 | the direct ancestors of C0. |
| 23 | 23 | <li>Prune the list of ancestors of C0 so that it contains only |
| 24 | - check-in in which the file to be annotated was modified. | |
| 24 | + check-ins in which the file to be annotated was modified. | |
| 25 | 25 | <li>Load the complete text of the file to be annotated from check-in C0. |
| 26 | 26 | Call this version of the file F0. |
| 27 | 27 | <li>Parse F0 into lines. Mark each line as "unchanged". |
| 28 | 28 | <li>For each ancestor of C0 on the pruned list (call the ancestor CX), |
| 29 | 29 | beginning with the most |
| @@ -45,11 +45,11 @@ | ||
| 45 | 45 | |
| 46 | 46 | The time-consuming part of this algorithm is step 6b - computing the |
| 47 | 47 | diff from all historical versions of the file to the version of the file |
| 48 | 48 | under analysis. For a large file that has many historical changes, this |
| 49 | 49 | can take several seconds. For this reason, the default |
| 50 | -[/help?cmd=/annotate|/annotate] webpage only shows those lines that where | |
| 50 | +[/help?cmd=/annotate|/annotate] webpage only shows those lines that were | |
| 51 | 51 | changed by the 20 most recent modifications to the file. This allows |
| 52 | 52 | the loop on step 6 to terminate after only 19 diffs instead of the hundreds |
| 53 | 53 | or thousands of diffs that might be required for a frequently modified file. |
| 54 | 54 | |
| 55 | 55 | As currently implemented (as of 2015-12-12) the annotate algorithm does not |
| 56 | 56 |
| --- www/blame.wiki | |
| +++ www/blame.wiki | |
| @@ -19,11 +19,11 @@ | |
| 19 | annotated. Call this check-in C0. |
| 20 | <li>Find all direct ancestors of C0. A direct ancestor is the closure |
| 21 | of the primary parent of C0. Merged in branches are not part of |
| 22 | the direct ancestors of C0. |
| 23 | <li>Prune the list of ancestors of C0 so that it contains only |
| 24 | check-in in which the file to be annotated was modified. |
| 25 | <li>Load the complete text of the file to be annotated from check-in C0. |
| 26 | Call this version of the file F0. |
| 27 | <li>Parse F0 into lines. Mark each line as "unchanged". |
| 28 | <li>For each ancestor of C0 on the pruned list (call the ancestor CX), |
| 29 | beginning with the most |
| @@ -45,11 +45,11 @@ | |
| 45 | |
| 46 | The time-consuming part of this algorithm is step 6b - computing the |
| 47 | diff from all historical versions of the file to the version of the file |
| 48 | under analysis. For a large file that has many historical changes, this |
| 49 | can take several seconds. For this reason, the default |
| 50 | [/help?cmd=/annotate|/annotate] webpage only shows those lines that where |
| 51 | changed by the 20 most recent modifications to the file. This allows |
| 52 | the loop on step 6 to terminate after only 19 diffs instead of the hundreds |
| 53 | or thousands of diffs that might be required for a frequently modified file. |
| 54 | |
| 55 | As currently implemented (as of 2015-12-12) the annotate algorithm does not |
| 56 |
| --- www/blame.wiki | |
| +++ www/blame.wiki | |
| @@ -19,11 +19,11 @@ | |
| 19 | annotated. Call this check-in C0. |
| 20 | <li>Find all direct ancestors of C0. A direct ancestor is the closure |
| 21 | of the primary parent of C0. Merged in branches are not part of |
| 22 | the direct ancestors of C0. |
| 23 | <li>Prune the list of ancestors of C0 so that it contains only |
| 24 | check-ins in which the file to be annotated was modified. |
| 25 | <li>Load the complete text of the file to be annotated from check-in C0. |
| 26 | Call this version of the file F0. |
| 27 | <li>Parse F0 into lines. Mark each line as "unchanged". |
| 28 | <li>For each ancestor of C0 on the pruned list (call the ancestor CX), |
| 29 | beginning with the most |
| @@ -45,11 +45,11 @@ | |
| 45 | |
| 46 | The time-consuming part of this algorithm is step 6b - computing the |
| 47 | diff from all historical versions of the file to the version of the file |
| 48 | under analysis. For a large file that has many historical changes, this |
| 49 | can take several seconds. For this reason, the default |
| 50 | [/help?cmd=/annotate|/annotate] webpage only shows those lines that were |
| 51 | changed by the 20 most recent modifications to the file. This allows |
| 52 | the loop on step 6 to terminate after only 19 diffs instead of the hundreds |
| 53 | or thousands of diffs that might be required for a frequently modified file. |
| 54 | |
| 55 | As currently implemented (as of 2015-12-12) the annotate algorithm does not |
| 56 |
+6
-6
| --- www/bugtheory.wiki | ||
| +++ www/bugtheory.wiki | ||
| @@ -112,13 +112,13 @@ | ||
| 112 | 112 | and is not shared with other repositories during a sync, push, or pull. |
| 113 | 113 | |
| 114 | 114 | Each repository also defines scripts used to generate web pages for |
| 115 | 115 | creating new tickets, viewing existing tickets, and modifying an |
| 116 | 116 | existing ticket. These scripts consist of HTML with an embedded |
| 117 | -scripts written a Tcl-like language called "[./th1.md|TH1]". Every new fossil | |
| 118 | -repository is created with default scripts. Administrators wishing to | |
| 119 | -customize their ticket entry, viewing, and editing screens should | |
| 120 | -modify the default scripts to suit their needs. These screen generator | |
| 121 | -scripts are part of the local state of a repository and are not shared | |
| 122 | -with other repositories during a sync, push, or pull. | |
| 117 | +scripts written in a Tcl-like language called "[./th1.md|TH1]". Every | |
| 118 | +new fossil repository is created with default scripts. Administrators | |
| 119 | +wishing to customize their ticket entry, viewing, and editing screens | |
| 120 | +should modify the default scripts to suit their needs. These screen | |
| 121 | +generator scripts are part of the local state of a repository and are | |
| 122 | +not shared with other repositories during a sync, push, or pull. | |
| 123 | 123 | |
| 124 | 124 | <i>To be continued...</i> |
| 125 | 125 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -112,13 +112,13 @@ | |
| 112 | and is not shared with other repositories during a sync, push, or pull. |
| 113 | |
| 114 | Each repository also defines scripts used to generate web pages for |
| 115 | creating new tickets, viewing existing tickets, and modifying an |
| 116 | existing ticket. These scripts consist of HTML with an embedded |
| 117 | scripts written a Tcl-like language called "[./th1.md|TH1]". Every new fossil |
| 118 | repository is created with default scripts. Administrators wishing to |
| 119 | customize their ticket entry, viewing, and editing screens should |
| 120 | modify the default scripts to suit their needs. These screen generator |
| 121 | scripts are part of the local state of a repository and are not shared |
| 122 | with other repositories during a sync, push, or pull. |
| 123 | |
| 124 | <i>To be continued...</i> |
| 125 |
| --- www/bugtheory.wiki | |
| +++ www/bugtheory.wiki | |
| @@ -112,13 +112,13 @@ | |
| 112 | and is not shared with other repositories during a sync, push, or pull. |
| 113 | |
| 114 | Each repository also defines scripts used to generate web pages for |
| 115 | creating new tickets, viewing existing tickets, and modifying an |
| 116 | existing ticket. These scripts consist of HTML with an embedded |
| 117 | scripts written in a Tcl-like language called "[./th1.md|TH1]". Every |
| 118 | new fossil repository is created with default scripts. Administrators |
| 119 | wishing to customize their ticket entry, viewing, and editing screens |
| 120 | should modify the default scripts to suit their needs. These screen |
| 121 | generator scripts are part of the local state of a repository and are |
| 122 | not shared with other repositories during a sync, push, or pull. |
| 123 | |
| 124 | <i>To be continued...</i> |
| 125 |
+2
-2
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -55,11 +55,11 @@ | ||
| 55 | 55 | <h2>Aside: Is it really safe to use an unreleased development version of |
| 56 | 56 | the Fossil source code?</h2> |
| 57 | 57 | |
| 58 | 58 | Yes! Any check-in on the |
| 59 | 59 | [/timeline?t=trunk | trunk branch] of the Fossil |
| 60 | -[https://fossil-scm.org/ | Fossil self-hosting repository] | |
| 60 | +[https://fossil-scm.org/ | self-hosting repository] | |
| 61 | 61 | will work fine. (Dodgy code is always on a branch.) In the unlikely |
| 62 | 62 | event that you pick a version with a serious bug, it still won't |
| 63 | 63 | clobber your files. Fossil uses several |
| 64 | 64 | [./selfcheck.wiki | self-checks] prior to committing any |
| 65 | 65 | repository change that prevent loss-of-work due to bugs. |
| @@ -475,11 +475,11 @@ | ||
| 475 | 475 | environment variables which are required by <tt>emcc</tt> and will |
| 476 | 476 | fail if it cannot do so. Once it's set up the environment, it passes |
| 477 | 477 | on all of its arguments to <tt>emcc</tt>. |
| 478 | 478 | |
| 479 | 479 | The WASM-related build parts are set up such that none of them should |
| 480 | -ever trigger implicity (e.g. via dependencies resolution) in a normal | |
| 480 | +ever trigger implicitly (e.g. via dependencies resolution) in a normal | |
| 481 | 481 | build cycle. They are instead explicitly built as described below. |
| 482 | 482 | |
| 483 | 483 | From the top of the source tree, all WASM-related components can be |
| 484 | 484 | built with: |
| 485 | 485 | |
| 486 | 486 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -55,11 +55,11 @@ | |
| 55 | <h2>Aside: Is it really safe to use an unreleased development version of |
| 56 | the Fossil source code?</h2> |
| 57 | |
| 58 | Yes! Any check-in on the |
| 59 | [/timeline?t=trunk | trunk branch] of the Fossil |
| 60 | [https://fossil-scm.org/ | Fossil self-hosting repository] |
| 61 | will work fine. (Dodgy code is always on a branch.) In the unlikely |
| 62 | event that you pick a version with a serious bug, it still won't |
| 63 | clobber your files. Fossil uses several |
| 64 | [./selfcheck.wiki | self-checks] prior to committing any |
| 65 | repository change that prevent loss-of-work due to bugs. |
| @@ -475,11 +475,11 @@ | |
| 475 | environment variables which are required by <tt>emcc</tt> and will |
| 476 | fail if it cannot do so. Once it's set up the environment, it passes |
| 477 | on all of its arguments to <tt>emcc</tt>. |
| 478 | |
| 479 | The WASM-related build parts are set up such that none of them should |
| 480 | ever trigger implicity (e.g. via dependencies resolution) in a normal |
| 481 | build cycle. They are instead explicitly built as described below. |
| 482 | |
| 483 | From the top of the source tree, all WASM-related components can be |
| 484 | built with: |
| 485 | |
| 486 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -55,11 +55,11 @@ | |
| 55 | <h2>Aside: Is it really safe to use an unreleased development version of |
| 56 | the Fossil source code?</h2> |
| 57 | |
| 58 | Yes! Any check-in on the |
| 59 | [/timeline?t=trunk | trunk branch] of the Fossil |
| 60 | [https://fossil-scm.org/ | self-hosting repository] |
| 61 | will work fine. (Dodgy code is always on a branch.) In the unlikely |
| 62 | event that you pick a version with a serious bug, it still won't |
| 63 | clobber your files. Fossil uses several |
| 64 | [./selfcheck.wiki | self-checks] prior to committing any |
| 65 | repository change that prevent loss-of-work due to bugs. |
| @@ -475,11 +475,11 @@ | |
| 475 | environment variables which are required by <tt>emcc</tt> and will |
| 476 | fail if it cannot do so. Once it's set up the environment, it passes |
| 477 | on all of its arguments to <tt>emcc</tt>. |
| 478 | |
| 479 | The WASM-related build parts are set up such that none of them should |
| 480 | ever trigger implicitly (e.g. via dependencies resolution) in a normal |
| 481 | build cycle. They are instead explicitly built as described below. |
| 482 | |
| 483 | From the top of the source tree, all WASM-related components can be |
| 484 | built with: |
| 485 | |
| 486 |
+2
-2
| --- www/cgi.wiki | ||
| +++ www/cgi.wiki | ||
| @@ -13,11 +13,11 @@ | ||
| 13 | 13 | setting up a Fossil server, one of which is [./server/any/cgi.md | as a CGI |
| 14 | 14 | script]. CGI is the technique that the three |
| 15 | 15 | [./selfhost.wiki|self-hosting Fossil repositories] all use. |
| 16 | 16 | |
| 17 | 17 | Setting up a Fossil server using CGI is mostly about writing a short |
| 18 | -script (usually just 2 lines line) in the cgi-bin folder of an ordinary | |
| 18 | +script (usually just 2 lines) in the cgi-bin folder of an ordinary | |
| 19 | 19 | web-server. But there are a lot of extra options that can be added |
| 20 | 20 | to this script, to customize the configuration. This article describes |
| 21 | 21 | those options. |
| 22 | 22 | |
| 23 | 23 | <h1>CGI Script Options</h1> |
| @@ -191,11 +191,11 @@ | ||
| 191 | 191 | |
| 192 | 192 | |
| 193 | 193 | <h2 id="mainmenu">mainmenu: <i>FILE</i></h2> |
| 194 | 194 | |
| 195 | 195 | This parameter causes the contents of the given file to override the |
| 196 | -site's <tt>mainmenu</tt> configuration setting, much in the same way | |
| 196 | +site's <tt>mainmenu</tt> configuration setting, in much the same way | |
| 197 | 197 | that the <tt>skin</tt> setting overrides the skin. This can be used to |
| 198 | 198 | apply a common main menu to a number of sites, and centrally maintain |
| 199 | 199 | it, without having to copy its contents into each site. Note, however, |
| 200 | 200 | that the contents of this setting are not stored in the repository and |
| 201 | 201 | will not be cloned along with the repository. |
| 202 | 202 |
| --- www/cgi.wiki | |
| +++ www/cgi.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | setting up a Fossil server, one of which is [./server/any/cgi.md | as a CGI |
| 14 | script]. CGI is the technique that the three |
| 15 | [./selfhost.wiki|self-hosting Fossil repositories] all use. |
| 16 | |
| 17 | Setting up a Fossil server using CGI is mostly about writing a short |
| 18 | script (usually just 2 lines line) in the cgi-bin folder of an ordinary |
| 19 | web-server. But there are a lot of extra options that can be added |
| 20 | to this script, to customize the configuration. This article describes |
| 21 | those options. |
| 22 | |
| 23 | <h1>CGI Script Options</h1> |
| @@ -191,11 +191,11 @@ | |
| 191 | |
| 192 | |
| 193 | <h2 id="mainmenu">mainmenu: <i>FILE</i></h2> |
| 194 | |
| 195 | This parameter causes the contents of the given file to override the |
| 196 | site's <tt>mainmenu</tt> configuration setting, much in the same way |
| 197 | that the <tt>skin</tt> setting overrides the skin. This can be used to |
| 198 | apply a common main menu to a number of sites, and centrally maintain |
| 199 | it, without having to copy its contents into each site. Note, however, |
| 200 | that the contents of this setting are not stored in the repository and |
| 201 | will not be cloned along with the repository. |
| 202 |
| --- www/cgi.wiki | |
| +++ www/cgi.wiki | |
| @@ -13,11 +13,11 @@ | |
| 13 | setting up a Fossil server, one of which is [./server/any/cgi.md | as a CGI |
| 14 | script]. CGI is the technique that the three |
| 15 | [./selfhost.wiki|self-hosting Fossil repositories] all use. |
| 16 | |
| 17 | Setting up a Fossil server using CGI is mostly about writing a short |
| 18 | script (usually just 2 lines) in the cgi-bin folder of an ordinary |
| 19 | web-server. But there are a lot of extra options that can be added |
| 20 | to this script, to customize the configuration. This article describes |
| 21 | those options. |
| 22 | |
| 23 | <h1>CGI Script Options</h1> |
| @@ -191,11 +191,11 @@ | |
| 191 | |
| 192 | |
| 193 | <h2 id="mainmenu">mainmenu: <i>FILE</i></h2> |
| 194 | |
| 195 | This parameter causes the contents of the given file to override the |
| 196 | site's <tt>mainmenu</tt> configuration setting, in much the same way |
| 197 | that the <tt>skin</tt> setting overrides the skin. This can be used to |
| 198 | apply a common main menu to a number of sites, and centrally maintain |
| 199 | it, without having to copy its contents into each site. Note, however, |
| 200 | that the contents of this setting are not stored in the repository and |
| 201 | will not be cloned along with the repository. |
| 202 |
+2
-2
| --- www/chat.md | ||
| +++ www/chat.md | ||
| @@ -155,11 +155,11 @@ | ||
| 155 | 155 | Substitute the appropriate project URL, robot account |
| 156 | 156 | name and password, message text and file attachment, of course. |
| 157 | 157 | |
| 158 | 158 | ### <a id="chat-robot"></a> Chat Messages For Timeline Events |
| 159 | 159 | |
| 160 | -If the [chat-timeline-user setting](/help?cmd=chat-timeline-user) is not a | |
| 160 | +If the [chat-timeline-user setting](/help?cmd=chat-timeline-user) is not an | |
| 161 | 161 | empty string, then any change to the repository that would normally result |
| 162 | 162 | in a new timeline entry is announced in the chatroom. The announcement |
| 163 | 163 | appears to come from a user whose name is given by the chat-timeline-user |
| 164 | 164 | setting. |
| 165 | 165 | |
| @@ -193,11 +193,11 @@ | ||
| 193 | 193 | * [/chat-delete](/help?name=/chat-delete) → |
| 194 | 194 | Deletes a chat message. |
| 195 | 195 | |
| 196 | 196 | Fossil chat uses the venerable "hanging GET" or |
| 197 | 197 | "[long polling](wikipedia:/wiki/Push_technology#Long_polling)" |
| 198 | -technique to recieve asynchronous notification of new messages. | |
| 198 | +technique to receive asynchronous notification of new messages. | |
| 199 | 199 | This is done because long polling works well with CGI and SCGI, |
| 200 | 200 | which are the usual mechanisms for setting up a Fossil server. |
| 201 | 201 | More advanced notification techniques such as |
| 202 | 202 | [Server-sent events](wikipedia:/wiki/Server-sent_events) and especially |
| 203 | 203 | [WebSockets](wikipedia:/wiki/WebSocket) might seem more appropriate for |
| 204 | 204 |
| --- www/chat.md | |
| +++ www/chat.md | |
| @@ -155,11 +155,11 @@ | |
| 155 | Substitute the appropriate project URL, robot account |
| 156 | name and password, message text and file attachment, of course. |
| 157 | |
| 158 | ### <a id="chat-robot"></a> Chat Messages For Timeline Events |
| 159 | |
| 160 | If the [chat-timeline-user setting](/help?cmd=chat-timeline-user) is not a |
| 161 | empty string, then any change to the repository that would normally result |
| 162 | in a new timeline entry is announced in the chatroom. The announcement |
| 163 | appears to come from a user whose name is given by the chat-timeline-user |
| 164 | setting. |
| 165 | |
| @@ -193,11 +193,11 @@ | |
| 193 | * [/chat-delete](/help?name=/chat-delete) → |
| 194 | Deletes a chat message. |
| 195 | |
| 196 | Fossil chat uses the venerable "hanging GET" or |
| 197 | "[long polling](wikipedia:/wiki/Push_technology#Long_polling)" |
| 198 | technique to recieve asynchronous notification of new messages. |
| 199 | This is done because long polling works well with CGI and SCGI, |
| 200 | which are the usual mechanisms for setting up a Fossil server. |
| 201 | More advanced notification techniques such as |
| 202 | [Server-sent events](wikipedia:/wiki/Server-sent_events) and especially |
| 203 | [WebSockets](wikipedia:/wiki/WebSocket) might seem more appropriate for |
| 204 |
| --- www/chat.md | |
| +++ www/chat.md | |
| @@ -155,11 +155,11 @@ | |
| 155 | Substitute the appropriate project URL, robot account |
| 156 | name and password, message text and file attachment, of course. |
| 157 | |
| 158 | ### <a id="chat-robot"></a> Chat Messages For Timeline Events |
| 159 | |
| 160 | If the [chat-timeline-user setting](/help?cmd=chat-timeline-user) is not an |
| 161 | empty string, then any change to the repository that would normally result |
| 162 | in a new timeline entry is announced in the chatroom. The announcement |
| 163 | appears to come from a user whose name is given by the chat-timeline-user |
| 164 | setting. |
| 165 | |
| @@ -193,11 +193,11 @@ | |
| 193 | * [/chat-delete](/help?name=/chat-delete) → |
| 194 | Deletes a chat message. |
| 195 | |
| 196 | Fossil chat uses the venerable "hanging GET" or |
| 197 | "[long polling](wikipedia:/wiki/Push_technology#Long_polling)" |
| 198 | technique to receive asynchronous notification of new messages. |
| 199 | This is done because long polling works well with CGI and SCGI, |
| 200 | which are the usual mechanisms for setting up a Fossil server. |
| 201 | More advanced notification techniques such as |
| 202 | [Server-sent events](wikipedia:/wiki/Server-sent_events) and especially |
| 203 | [WebSockets](wikipedia:/wiki/WebSocket) might seem more appropriate for |
| 204 |
+1
-1
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -246,11 +246,11 @@ | ||
| 246 | 246 | |
| 247 | 247 | <pre> |
| 248 | 248 | fossil info merge-in:xyzzy:2022-03-01 |
| 249 | 249 | </pre> |
| 250 | 250 | |
| 251 | -to get informations about the most recent merge-in point on the branch | |
| 251 | +to get information about the most recent merge-in point on the branch | |
| 252 | 252 | "xyzzy" that happened on or before March 1, 2022. |
| 253 | 253 | |
| 254 | 254 | <h2 id="special">Special Tags</h2> |
| 255 | 255 | |
| 256 | 256 | The tag "tip" means the most recent check-in. The "tip" tag is practically |
| 257 | 257 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -246,11 +246,11 @@ | |
| 246 | |
| 247 | <pre> |
| 248 | fossil info merge-in:xyzzy:2022-03-01 |
| 249 | </pre> |
| 250 | |
| 251 | to get informations about the most recent merge-in point on the branch |
| 252 | "xyzzy" that happened on or before March 1, 2022. |
| 253 | |
| 254 | <h2 id="special">Special Tags</h2> |
| 255 | |
| 256 | The tag "tip" means the most recent check-in. The "tip" tag is practically |
| 257 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -246,11 +246,11 @@ | |
| 246 | |
| 247 | <pre> |
| 248 | fossil info merge-in:xyzzy:2022-03-01 |
| 249 | </pre> |
| 250 | |
| 251 | to get information about the most recent merge-in point on the branch |
| 252 | "xyzzy" that happened on or before March 1, 2022. |
| 253 | |
| 254 | <h2 id="special">Special Tags</h2> |
| 255 | |
| 256 | The tag "tip" means the most recent check-in. The "tip" tag is practically |
| 257 |
+4
-4
| --- www/concepts.wiki | ||
| +++ www/concepts.wiki | ||
| @@ -163,11 +163,11 @@ | ||
| 163 | 163 | The manifest file is not normally a real file on disk. Instead, |
| 164 | 164 | the manifest is computed in memory by Fossil whenever it needs it. |
| 165 | 165 | However, the "fossil setting manifest on" command will cause the |
| 166 | 166 | manifest file to be materialized to disk, if desired. Both Fossil |
| 167 | 167 | itself, and SQLite cause the manifest file to be materialized to disk |
| 168 | -so that the makefiles for these project can read the manifest and | |
| 168 | +so that the makefiles for these projects can read the manifest and | |
| 169 | 169 | embed version information in generated binaries. |
| 170 | 170 | |
| 171 | 171 | Fossil automatically generates a manifest whenever you "commit" |
| 172 | 172 | a new check-in. So this is not something that you, the developer, |
| 173 | 173 | need to worry with. The format of a manifest is intentionally |
| @@ -178,11 +178,11 @@ | ||
| 178 | 178 | |
| 179 | 179 | In addition to identifying all files in the check-in, a |
| 180 | 180 | manifest also contains a check-in comment, the date and time |
| 181 | 181 | when the check-in was established, who created the check-in, |
| 182 | 182 | and links to other check-ins from which the current check-in |
| 183 | -is derived. There is also a couple of checksums used to verify | |
| 183 | +is derived. There are also a couple of checksums used to verify | |
| 184 | 184 | the integrity of the check-in. And the whole manifest might |
| 185 | 185 | be PGP clearsigned. |
| 186 | 186 | |
| 187 | 187 | <h3 id="keyconc">2.3 Key concepts</h3> |
| 188 | 188 | |
| @@ -217,11 +217,11 @@ | ||
| 217 | 217 | SQLite, patch, or any similar software on your system in order to use |
| 218 | 218 | Fossil effectively. You will want to have some kind of text editor |
| 219 | 219 | for entering check-in comments. Fossil will use whatever text editor |
| 220 | 220 | is identified by your VISUAL environment variable. Fossil will also |
| 221 | 221 | use GPG to clearsign your manifests if you happen to have it installed, |
| 222 | -but Fossil will skip that step if GPG missing from your system. | |
| 222 | +but Fossil will skip that step if GPG is missing from your system. | |
| 223 | 223 | You can optionally set up Fossil to use external "diff" programs, |
| 224 | 224 | though Fossil has an excellent built-in "diff" algorithm that works |
| 225 | 225 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 226 | 226 | system, Fossil will use it to generate a graphical "diff" display when |
| 227 | 227 | you use the --tk option to the "diff" command, but this too is entirely |
| @@ -286,11 +286,11 @@ | ||
| 286 | 286 | fossil setting autosync off |
| 287 | 287 | fossil settings |
| 288 | 288 | </pre> |
| 289 | 289 | |
| 290 | 290 | By default, Fossil runs with autosync mode turned on. The |
| 291 | -authors finds that projects run more smoothly in autosync mode since | |
| 291 | +authors find that projects run more smoothly in autosync mode since | |
| 292 | 292 | autosync helps to prevent pointless forking and merging and helps keeps |
| 293 | 293 | all collaborators working on exactly the same code rather than on their |
| 294 | 294 | own personal forks of the code. In the author's view, manual-merge mode |
| 295 | 295 | should be reserved for disconnected operation. |
| 296 | 296 | |
| 297 | 297 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -163,11 +163,11 @@ | |
| 163 | The manifest file is not normally a real file on disk. Instead, |
| 164 | the manifest is computed in memory by Fossil whenever it needs it. |
| 165 | However, the "fossil setting manifest on" command will cause the |
| 166 | manifest file to be materialized to disk, if desired. Both Fossil |
| 167 | itself, and SQLite cause the manifest file to be materialized to disk |
| 168 | so that the makefiles for these project can read the manifest and |
| 169 | embed version information in generated binaries. |
| 170 | |
| 171 | Fossil automatically generates a manifest whenever you "commit" |
| 172 | a new check-in. So this is not something that you, the developer, |
| 173 | need to worry with. The format of a manifest is intentionally |
| @@ -178,11 +178,11 @@ | |
| 178 | |
| 179 | In addition to identifying all files in the check-in, a |
| 180 | manifest also contains a check-in comment, the date and time |
| 181 | when the check-in was established, who created the check-in, |
| 182 | and links to other check-ins from which the current check-in |
| 183 | is derived. There is also a couple of checksums used to verify |
| 184 | the integrity of the check-in. And the whole manifest might |
| 185 | be PGP clearsigned. |
| 186 | |
| 187 | <h3 id="keyconc">2.3 Key concepts</h3> |
| 188 | |
| @@ -217,11 +217,11 @@ | |
| 217 | SQLite, patch, or any similar software on your system in order to use |
| 218 | Fossil effectively. You will want to have some kind of text editor |
| 219 | for entering check-in comments. Fossil will use whatever text editor |
| 220 | is identified by your VISUAL environment variable. Fossil will also |
| 221 | use GPG to clearsign your manifests if you happen to have it installed, |
| 222 | but Fossil will skip that step if GPG missing from your system. |
| 223 | You can optionally set up Fossil to use external "diff" programs, |
| 224 | though Fossil has an excellent built-in "diff" algorithm that works |
| 225 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 226 | system, Fossil will use it to generate a graphical "diff" display when |
| 227 | you use the --tk option to the "diff" command, but this too is entirely |
| @@ -286,11 +286,11 @@ | |
| 286 | fossil setting autosync off |
| 287 | fossil settings |
| 288 | </pre> |
| 289 | |
| 290 | By default, Fossil runs with autosync mode turned on. The |
| 291 | authors finds that projects run more smoothly in autosync mode since |
| 292 | autosync helps to prevent pointless forking and merging and helps keeps |
| 293 | all collaborators working on exactly the same code rather than on their |
| 294 | own personal forks of the code. In the author's view, manual-merge mode |
| 295 | should be reserved for disconnected operation. |
| 296 | |
| 297 |
| --- www/concepts.wiki | |
| +++ www/concepts.wiki | |
| @@ -163,11 +163,11 @@ | |
| 163 | The manifest file is not normally a real file on disk. Instead, |
| 164 | the manifest is computed in memory by Fossil whenever it needs it. |
| 165 | However, the "fossil setting manifest on" command will cause the |
| 166 | manifest file to be materialized to disk, if desired. Both Fossil |
| 167 | itself, and SQLite cause the manifest file to be materialized to disk |
| 168 | so that the makefiles for these projects can read the manifest and |
| 169 | embed version information in generated binaries. |
| 170 | |
| 171 | Fossil automatically generates a manifest whenever you "commit" |
| 172 | a new check-in. So this is not something that you, the developer, |
| 173 | need to worry with. The format of a manifest is intentionally |
| @@ -178,11 +178,11 @@ | |
| 178 | |
| 179 | In addition to identifying all files in the check-in, a |
| 180 | manifest also contains a check-in comment, the date and time |
| 181 | when the check-in was established, who created the check-in, |
| 182 | and links to other check-ins from which the current check-in |
| 183 | is derived. There are also a couple of checksums used to verify |
| 184 | the integrity of the check-in. And the whole manifest might |
| 185 | be PGP clearsigned. |
| 186 | |
| 187 | <h3 id="keyconc">2.3 Key concepts</h3> |
| 188 | |
| @@ -217,11 +217,11 @@ | |
| 217 | SQLite, patch, or any similar software on your system in order to use |
| 218 | Fossil effectively. You will want to have some kind of text editor |
| 219 | for entering check-in comments. Fossil will use whatever text editor |
| 220 | is identified by your VISUAL environment variable. Fossil will also |
| 221 | use GPG to clearsign your manifests if you happen to have it installed, |
| 222 | but Fossil will skip that step if GPG is missing from your system. |
| 223 | You can optionally set up Fossil to use external "diff" programs, |
| 224 | though Fossil has an excellent built-in "diff" algorithm that works |
| 225 | fine for most people. If you happen to have Tcl/Tk installed on your |
| 226 | system, Fossil will use it to generate a graphical "diff" display when |
| 227 | you use the --tk option to the "diff" command, but this too is entirely |
| @@ -286,11 +286,11 @@ | |
| 286 | fossil setting autosync off |
| 287 | fossil settings |
| 288 | </pre> |
| 289 | |
| 290 | By default, Fossil runs with autosync mode turned on. The |
| 291 | authors find that projects run more smoothly in autosync mode since |
| 292 | autosync helps to prevent pointless forking and merging and helps keeps |
| 293 | all collaborators working on exactly the same code rather than on their |
| 294 | own personal forks of the code. In the author's view, manual-merge mode |
| 295 | should be reserved for disconnected operation. |
| 296 | |
| 297 |
+1
-1
| --- www/contribute.wiki | ||
| +++ www/contribute.wiki | ||
| @@ -1,8 +1,8 @@ | ||
| 1 | 1 | <title>Contributing To Fossil</title> |
| 2 | 2 | |
| 3 | -Fossil users are encouraged to contributed enhancements back to the | |
| 3 | +Fossil users are encouraged to contribute enhancements back to the | |
| 4 | 4 | project. This note outlines some of the procedures for making |
| 5 | 5 | useful contributions. |
| 6 | 6 | |
| 7 | 7 | <h2>1.0 Contributor Agreement</h2> |
| 8 | 8 | |
| 9 | 9 |
| --- www/contribute.wiki | |
| +++ www/contribute.wiki | |
| @@ -1,8 +1,8 @@ | |
| 1 | <title>Contributing To Fossil</title> |
| 2 | |
| 3 | Fossil users are encouraged to contributed enhancements back to the |
| 4 | project. This note outlines some of the procedures for making |
| 5 | useful contributions. |
| 6 | |
| 7 | <h2>1.0 Contributor Agreement</h2> |
| 8 | |
| 9 |
| --- www/contribute.wiki | |
| +++ www/contribute.wiki | |
| @@ -1,8 +1,8 @@ | |
| 1 | <title>Contributing To Fossil</title> |
| 2 | |
| 3 | Fossil users are encouraged to contribute enhancements back to the |
| 4 | project. This note outlines some of the procedures for making |
| 5 | useful contributions. |
| 6 | |
| 7 | <h2>1.0 Contributor Agreement</h2> |
| 8 | |
| 9 |
+2
-2
| --- www/custom_ticket.wiki | ||
| +++ www/custom_ticket.wiki | ||
| @@ -109,12 +109,12 @@ | ||
| 109 | 109 | </verbatim> |
| 110 | 110 | |
| 111 | 111 | That will give you a drop-down list of assignees. The first argument to the TH1 |
| 112 | 112 | command 'combobox' is the database field which the combobox is associated to. |
| 113 | 113 | The next argument is the list of choices you want to show in the combobox (and |
| 114 | -that you specified in the second step above. The last argument should be 1 for a | |
| 115 | -true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for | |
| 114 | +that you specified in the second step above.) The last argument should be 1 for | |
| 115 | +a true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for | |
| 116 | 116 | details). |
| 117 | 117 | |
| 118 | 118 | Now, similar to the previous |
| 119 | 119 | section, look for "Contact:" and add this: |
| 120 | 120 | |
| 121 | 121 |
| --- www/custom_ticket.wiki | |
| +++ www/custom_ticket.wiki | |
| @@ -109,12 +109,12 @@ | |
| 109 | </verbatim> |
| 110 | |
| 111 | That will give you a drop-down list of assignees. The first argument to the TH1 |
| 112 | command 'combobox' is the database field which the combobox is associated to. |
| 113 | The next argument is the list of choices you want to show in the combobox (and |
| 114 | that you specified in the second step above. The last argument should be 1 for a |
| 115 | true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for |
| 116 | details). |
| 117 | |
| 118 | Now, similar to the previous |
| 119 | section, look for "Contact:" and add this: |
| 120 | |
| 121 |
| --- www/custom_ticket.wiki | |
| +++ www/custom_ticket.wiki | |
| @@ -109,12 +109,12 @@ | |
| 109 | </verbatim> |
| 110 | |
| 111 | That will give you a drop-down list of assignees. The first argument to the TH1 |
| 112 | command 'combobox' is the database field which the combobox is associated to. |
| 113 | The next argument is the list of choices you want to show in the combobox (and |
| 114 | that you specified in the second step above.) The last argument should be 1 for |
| 115 | a true combobox (see the <a href="th1.md#combobox">TH1 documentation</a> for |
| 116 | details). |
| 117 | |
| 118 | Now, similar to the previous |
| 119 | section, look for "Contact:" and add this: |
| 120 | |
| 121 |