Fossil SCM
Changes for the following files under www/: settings.wiki shunning.wiki stats.wiki style.wiki sync.wiki
Commit
8e9fc86018293badfe961a20090dc4ac5c3938b7f9b6f3b5b2c037eb7dfa45ba
Parent
b69a35c61bda494…
5 files changed
+2
-3
+2
-2
+2
-2
+6
-5
+1
-1
+2
-3
| --- www/settings.wiki | ||
| +++ www/settings.wiki | ||
| @@ -44,13 +44,12 @@ | ||
| 44 | 44 | Because these options can change over time, and the inconvenience of |
| 45 | 45 | replicating changes, these settings are "versionable". As well as being |
| 46 | 46 | able to be set using the <tt>settings</tt> command or the web interface, |
| 47 | 47 | you can create versioned files in the <tt>.fossil-settings</tt> |
| 48 | 48 | subdirectory of the check-out root, named with the setting name. |
| 49 | -The contents of the file is the | |
| 50 | -value of the setting, and these files are checked in, committed, merged, | |
| 51 | -and so on, as with any other file. | |
| 49 | +Each file holds the value of a setting, and these files are checked in, | |
| 50 | +committed, merged, and so on, as with any other file. | |
| 52 | 51 | |
| 53 | 52 | Where a setting is a list of values, such as <tt>ignore-glob</tt>, you |
| 54 | 53 | can use a newline as a separator as well as a comma. |
| 55 | 54 | |
| 56 | 55 | For example, to set the list of ignored files, create a |
| 57 | 56 |
| --- www/settings.wiki | |
| +++ www/settings.wiki | |
| @@ -44,13 +44,12 @@ | |
| 44 | Because these options can change over time, and the inconvenience of |
| 45 | replicating changes, these settings are "versionable". As well as being |
| 46 | able to be set using the <tt>settings</tt> command or the web interface, |
| 47 | you can create versioned files in the <tt>.fossil-settings</tt> |
| 48 | subdirectory of the check-out root, named with the setting name. |
| 49 | The contents of the file is the |
| 50 | value of the setting, and these files are checked in, committed, merged, |
| 51 | and so on, as with any other file. |
| 52 | |
| 53 | Where a setting is a list of values, such as <tt>ignore-glob</tt>, you |
| 54 | can use a newline as a separator as well as a comma. |
| 55 | |
| 56 | For example, to set the list of ignored files, create a |
| 57 |
| --- www/settings.wiki | |
| +++ www/settings.wiki | |
| @@ -44,13 +44,12 @@ | |
| 44 | Because these options can change over time, and the inconvenience of |
| 45 | replicating changes, these settings are "versionable". As well as being |
| 46 | able to be set using the <tt>settings</tt> command or the web interface, |
| 47 | you can create versioned files in the <tt>.fossil-settings</tt> |
| 48 | subdirectory of the check-out root, named with the setting name. |
| 49 | Each file holds the value of a setting, and these files are checked in, |
| 50 | committed, merged, and so on, as with any other file. |
| 51 | |
| 52 | Where a setting is a list of values, such as <tt>ignore-glob</tt>, you |
| 53 | can use a newline as a separator as well as a comma. |
| 54 | |
| 55 | For example, to set the list of ignored files, create a |
| 56 |
+2
-2
| --- www/shunning.wiki | ||
| +++ www/shunning.wiki | ||
| @@ -33,11 +33,11 @@ | ||
| 33 | 33 | |
| 34 | 34 | All of these are rare cases: Fossil is [./antibot.wiki | designed to |
| 35 | 35 | foil spammers up front], legally problematic check-ins should range from |
| 36 | 36 | rare to nonexistent, and you have to go way out of your way to force |
| 37 | 37 | Fossil to insert bad control artifacts. Therefore, before we get to |
| 38 | -methods of permanently deleting content from a Fossil repos, let's give | |
| 38 | +methods of permanently deleting content from a Fossil repo, let's give | |
| 39 | 39 | some alternatives that usually suffice, which don't damage the project's |
| 40 | 40 | fossil record: |
| 41 | 41 | |
| 42 | 42 | * When a forum post or wiki article is "deleted," what actually |
| 43 | 43 | happens is that a new empty version is added to the Fossil repository. |
| @@ -133,11 +133,11 @@ | ||
| 133 | 133 | using the "configuration" command: |
| 134 | 134 | |
| 135 | 135 | <b>fossil configuration pull shun</b> <i>remote-url</i><br> |
| 136 | 136 | <b>fossil configuration push shun</b> <i>remote-url</i> |
| 137 | 137 | |
| 138 | -The two command above will pull or push shunning lists from or to | |
| 138 | +The two commands above will pull or push shunning lists from or to | |
| 139 | 139 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 140 | 140 | end. "Admin" privilege on the remote server is required in order to |
| 141 | 141 | push a shun list. In contrast, the shunning list will be automatically |
| 142 | 142 | received by default as part of a normal client "pull" operation unless |
| 143 | 143 | disabled by the "<tt>auto-shun</tt>" setting. |
| 144 | 144 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -33,11 +33,11 @@ | |
| 33 | |
| 34 | All of these are rare cases: Fossil is [./antibot.wiki | designed to |
| 35 | foil spammers up front], legally problematic check-ins should range from |
| 36 | rare to nonexistent, and you have to go way out of your way to force |
| 37 | Fossil to insert bad control artifacts. Therefore, before we get to |
| 38 | methods of permanently deleting content from a Fossil repos, let's give |
| 39 | some alternatives that usually suffice, which don't damage the project's |
| 40 | fossil record: |
| 41 | |
| 42 | * When a forum post or wiki article is "deleted," what actually |
| 43 | happens is that a new empty version is added to the Fossil repository. |
| @@ -133,11 +133,11 @@ | |
| 133 | using the "configuration" command: |
| 134 | |
| 135 | <b>fossil configuration pull shun</b> <i>remote-url</i><br> |
| 136 | <b>fossil configuration push shun</b> <i>remote-url</i> |
| 137 | |
| 138 | The two command above will pull or push shunning lists from or to |
| 139 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 140 | end. "Admin" privilege on the remote server is required in order to |
| 141 | push a shun list. In contrast, the shunning list will be automatically |
| 142 | received by default as part of a normal client "pull" operation unless |
| 143 | disabled by the "<tt>auto-shun</tt>" setting. |
| 144 |
| --- www/shunning.wiki | |
| +++ www/shunning.wiki | |
| @@ -33,11 +33,11 @@ | |
| 33 | |
| 34 | All of these are rare cases: Fossil is [./antibot.wiki | designed to |
| 35 | foil spammers up front], legally problematic check-ins should range from |
| 36 | rare to nonexistent, and you have to go way out of your way to force |
| 37 | Fossil to insert bad control artifacts. Therefore, before we get to |
| 38 | methods of permanently deleting content from a Fossil repo, let's give |
| 39 | some alternatives that usually suffice, which don't damage the project's |
| 40 | fossil record: |
| 41 | |
| 42 | * When a forum post or wiki article is "deleted," what actually |
| 43 | happens is that a new empty version is added to the Fossil repository. |
| @@ -133,11 +133,11 @@ | |
| 133 | using the "configuration" command: |
| 134 | |
| 135 | <b>fossil configuration pull shun</b> <i>remote-url</i><br> |
| 136 | <b>fossil configuration push shun</b> <i>remote-url</i> |
| 137 | |
| 138 | The two commands above will pull or push shunning lists from or to |
| 139 | the <i>remote-url</i> indicated and merge the lists on the receiving |
| 140 | end. "Admin" privilege on the remote server is required in order to |
| 141 | push a shun list. In contrast, the shunning list will be automatically |
| 142 | received by default as part of a normal client "pull" operation unless |
| 143 | disabled by the "<tt>auto-shun</tt>" setting. |
| 144 |
+2
-2
| --- www/stats.wiki | ||
| +++ www/stats.wiki | ||
| @@ -1,11 +1,11 @@ | ||
| 1 | 1 | <title>Fossil Performance</title> |
| 2 | 2 | |
| 3 | 3 | The questions will inevitably arise: How does Fossil perform? |
| 4 | 4 | Does it use a lot of disk space or bandwidth? Is it scalable? |
| 5 | 5 | |
| 6 | -In an attempt to answers these questions, this report looks at several | |
| 6 | +In an attempt to answer these questions, this report looks at several | |
| 7 | 7 | projects that use fossil for configuration management and examines how |
| 8 | 8 | well they are working. The following table is a summary of the results. |
| 9 | 9 | (Last updated on 2018-06-04.) |
| 10 | 10 | Explanation and analysis follows the table. |
| 11 | 11 | |
| @@ -100,11 +100,11 @@ | ||
| 100 | 100 | is the unordered collection of artifacts. In fact, one of the key |
| 101 | 101 | characteristics of Fossil is that the entire project history can be |
| 102 | 102 | reconstructed simply by scanning the artifacts in an arbitrary order. |
| 103 | 103 | |
| 104 | 104 | The number of check-ins is the number of times that the "commit" command |
| 105 | -has been run. A single check-in might change a 3 or 4 files, or it might | |
| 105 | +has been run. A single check-in might change 3 or 4 files, or it might | |
| 106 | 106 | change dozens or hundreds of files. Regardless of the number of files |
| 107 | 107 | changed, it still only counts as one check-in. |
| 108 | 108 | |
| 109 | 109 | The "Uncompressed Size" is the total size of all the artifacts within |
| 110 | 110 | the repository assuming they were all uncompressed and stored |
| 111 | 111 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -1,11 +1,11 @@ | |
| 1 | <title>Fossil Performance</title> |
| 2 | |
| 3 | The questions will inevitably arise: How does Fossil perform? |
| 4 | Does it use a lot of disk space or bandwidth? Is it scalable? |
| 5 | |
| 6 | In an attempt to answers these questions, this report looks at several |
| 7 | projects that use fossil for configuration management and examines how |
| 8 | well they are working. The following table is a summary of the results. |
| 9 | (Last updated on 2018-06-04.) |
| 10 | Explanation and analysis follows the table. |
| 11 | |
| @@ -100,11 +100,11 @@ | |
| 100 | is the unordered collection of artifacts. In fact, one of the key |
| 101 | characteristics of Fossil is that the entire project history can be |
| 102 | reconstructed simply by scanning the artifacts in an arbitrary order. |
| 103 | |
| 104 | The number of check-ins is the number of times that the "commit" command |
| 105 | has been run. A single check-in might change a 3 or 4 files, or it might |
| 106 | change dozens or hundreds of files. Regardless of the number of files |
| 107 | changed, it still only counts as one check-in. |
| 108 | |
| 109 | The "Uncompressed Size" is the total size of all the artifacts within |
| 110 | the repository assuming they were all uncompressed and stored |
| 111 |
| --- www/stats.wiki | |
| +++ www/stats.wiki | |
| @@ -1,11 +1,11 @@ | |
| 1 | <title>Fossil Performance</title> |
| 2 | |
| 3 | The questions will inevitably arise: How does Fossil perform? |
| 4 | Does it use a lot of disk space or bandwidth? Is it scalable? |
| 5 | |
| 6 | In an attempt to answer these questions, this report looks at several |
| 7 | projects that use fossil for configuration management and examines how |
| 8 | well they are working. The following table is a summary of the results. |
| 9 | (Last updated on 2018-06-04.) |
| 10 | Explanation and analysis follows the table. |
| 11 | |
| @@ -100,11 +100,11 @@ | |
| 100 | is the unordered collection of artifacts. In fact, one of the key |
| 101 | characteristics of Fossil is that the entire project history can be |
| 102 | reconstructed simply by scanning the artifacts in an arbitrary order. |
| 103 | |
| 104 | The number of check-ins is the number of times that the "commit" command |
| 105 | has been run. A single check-in might change 3 or 4 files, or it might |
| 106 | change dozens or hundreds of files. Regardless of the number of files |
| 107 | changed, it still only counts as one check-in. |
| 108 | |
| 109 | The "Uncompressed Size" is the total size of all the artifacts within |
| 110 | the repository assuming they were all uncompressed and stored |
| 111 |
+6
-5
| --- www/style.wiki | ||
| +++ www/style.wiki | ||
| @@ -1,8 +1,8 @@ | ||
| 1 | 1 | <title>Coding Style</title> |
| 2 | 2 | |
| 3 | -Fossil source code should following the style guidelines below. | |
| 3 | +Fossil source code should follow the style guidelines below. | |
| 4 | 4 | |
| 5 | 5 | <em> The Fossil source tree includes a few files taken from external |
| 6 | 6 | sources |
| 7 | 7 | (examples: [https://github.com/antirez/linenoise|linenoise] and |
| 8 | 8 | [http://zlib.net/|zLib]) |
| @@ -38,13 +38,14 @@ | ||
| 38 | 38 | |
| 39 | 39 | <li> -Wno-long-long: Fossil uses the 'long long' integer type, which is not strictly ANSI C-89 (defined in C99). |
| 40 | 40 | The use of 'long long' resolves many problems with 64-bit arithmetics, especially on 32-bit machines. |
| 41 | 41 | (http_ssl.c, sha3.c, shell.c, util.c) |
| 42 | 42 | |
| 43 | - <li> alloca(): By default, sqlite3.c is compiled with the -DSQLITE_USE_ALLOCA flag to use the alloca() function. | |
| 44 | - alloca() is not considered ANSI C, and normally not recommended due to portability issues, but | |
| 45 | - performance and/or memory consumption improvement may be a stronger argument in favor of its usage. | |
| 43 | + <li> alloca(): By default, sqlite3.c was compiled with the -DSQLITE_USE_ALLOCA flag to use the alloca() function. | |
| 44 | + This is no longer the case as of 20220119. alloca() is not considered ANSI C, and normally not | |
| 45 | + recommended due to portability issues, but performance and/or memory consumption | |
| 46 | + improvement may have been a stronger argument in favor of its usage. | |
| 46 | 47 | (sqlite3.c) |
| 47 | 48 | </ol> |
| 48 | 49 | |
| 49 | 50 | <li> All comments and identifiers are in English. |
| 50 | 51 | |
| @@ -75,11 +76,11 @@ | ||
| 75 | 76 | |
| 76 | 77 | <ol> |
| 77 | 78 | <li value=30> Every function has a header comment describing the purpose and use |
| 78 | 79 | of the function. |
| 79 | 80 | |
| 80 | - <li> Function header comment defines the behavior of the function in | |
| 81 | + <li> A function header comment defines the behavior of the function in | |
| 81 | 82 | sufficient detail to allow the function to be re-implemented from |
| 82 | 83 | scratch without reference to the original code. |
| 83 | 84 | |
| 84 | 85 | <li> Functions that perform dynamic memory allocation (either directly |
| 85 | 86 | or indirectly via subfunctions) say so in their header comments. |
| 86 | 87 |
| --- www/style.wiki | |
| +++ www/style.wiki | |
| @@ -1,8 +1,8 @@ | |
| 1 | <title>Coding Style</title> |
| 2 | |
| 3 | Fossil source code should following the style guidelines below. |
| 4 | |
| 5 | <em> The Fossil source tree includes a few files taken from external |
| 6 | sources |
| 7 | (examples: [https://github.com/antirez/linenoise|linenoise] and |
| 8 | [http://zlib.net/|zLib]) |
| @@ -38,13 +38,14 @@ | |
| 38 | |
| 39 | <li> -Wno-long-long: Fossil uses the 'long long' integer type, which is not strictly ANSI C-89 (defined in C99). |
| 40 | The use of 'long long' resolves many problems with 64-bit arithmetics, especially on 32-bit machines. |
| 41 | (http_ssl.c, sha3.c, shell.c, util.c) |
| 42 | |
| 43 | <li> alloca(): By default, sqlite3.c is compiled with the -DSQLITE_USE_ALLOCA flag to use the alloca() function. |
| 44 | alloca() is not considered ANSI C, and normally not recommended due to portability issues, but |
| 45 | performance and/or memory consumption improvement may be a stronger argument in favor of its usage. |
| 46 | (sqlite3.c) |
| 47 | </ol> |
| 48 | |
| 49 | <li> All comments and identifiers are in English. |
| 50 | |
| @@ -75,11 +76,11 @@ | |
| 75 | |
| 76 | <ol> |
| 77 | <li value=30> Every function has a header comment describing the purpose and use |
| 78 | of the function. |
| 79 | |
| 80 | <li> Function header comment defines the behavior of the function in |
| 81 | sufficient detail to allow the function to be re-implemented from |
| 82 | scratch without reference to the original code. |
| 83 | |
| 84 | <li> Functions that perform dynamic memory allocation (either directly |
| 85 | or indirectly via subfunctions) say so in their header comments. |
| 86 |
| --- www/style.wiki | |
| +++ www/style.wiki | |
| @@ -1,8 +1,8 @@ | |
| 1 | <title>Coding Style</title> |
| 2 | |
| 3 | Fossil source code should follow the style guidelines below. |
| 4 | |
| 5 | <em> The Fossil source tree includes a few files taken from external |
| 6 | sources |
| 7 | (examples: [https://github.com/antirez/linenoise|linenoise] and |
| 8 | [http://zlib.net/|zLib]) |
| @@ -38,13 +38,14 @@ | |
| 38 | |
| 39 | <li> -Wno-long-long: Fossil uses the 'long long' integer type, which is not strictly ANSI C-89 (defined in C99). |
| 40 | The use of 'long long' resolves many problems with 64-bit arithmetics, especially on 32-bit machines. |
| 41 | (http_ssl.c, sha3.c, shell.c, util.c) |
| 42 | |
| 43 | <li> alloca(): By default, sqlite3.c was compiled with the -DSQLITE_USE_ALLOCA flag to use the alloca() function. |
| 44 | This is no longer the case as of 20220119. alloca() is not considered ANSI C, and normally not |
| 45 | recommended due to portability issues, but performance and/or memory consumption |
| 46 | improvement may have been a stronger argument in favor of its usage. |
| 47 | (sqlite3.c) |
| 48 | </ol> |
| 49 | |
| 50 | <li> All comments and identifiers are in English. |
| 51 | |
| @@ -75,11 +76,11 @@ | |
| 76 | |
| 77 | <ol> |
| 78 | <li value=30> Every function has a header comment describing the purpose and use |
| 79 | of the function. |
| 80 | |
| 81 | <li> A function header comment defines the behavior of the function in |
| 82 | sufficient detail to allow the function to be re-implemented from |
| 83 | scratch without reference to the original code. |
| 84 | |
| 85 | <li> Functions that perform dynamic memory allocation (either directly |
| 86 | or indirectly via subfunctions) say so in their header comments. |
| 87 |
+1
-1
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -518,11 +518,11 @@ | ||
| 518 | 518 | pronounced as if it were a single word "gimme" in some dialects of |
| 519 | 519 | English (including the dialect spoken by the original author of Fossil). |
| 520 | 520 | |
| 521 | 521 | <h4>3.7.1 Unversioned Gimme Cards</h4> |
| 522 | 522 | |
| 523 | -Sync synchronizing unversioned content, the client may send "uvgimme" | |
| 523 | +When synchronizing unversioned content, the client may send "uvgimme" | |
| 524 | 524 | cards to the server. A uvgimme card requests that the server send |
| 525 | 525 | unversioned content to the client. The format of a uvgimme card is |
| 526 | 526 | as follows: |
| 527 | 527 | |
| 528 | 528 | <pre> |
| 529 | 529 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -518,11 +518,11 @@ | |
| 518 | pronounced as if it were a single word "gimme" in some dialects of |
| 519 | English (including the dialect spoken by the original author of Fossil). |
| 520 | |
| 521 | <h4>3.7.1 Unversioned Gimme Cards</h4> |
| 522 | |
| 523 | Sync synchronizing unversioned content, the client may send "uvgimme" |
| 524 | cards to the server. A uvgimme card requests that the server send |
| 525 | unversioned content to the client. The format of a uvgimme card is |
| 526 | as follows: |
| 527 | |
| 528 | <pre> |
| 529 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -518,11 +518,11 @@ | |
| 518 | pronounced as if it were a single word "gimme" in some dialects of |
| 519 | English (including the dialect spoken by the original author of Fossil). |
| 520 | |
| 521 | <h4>3.7.1 Unversioned Gimme Cards</h4> |
| 522 | |
| 523 | When synchronizing unversioned content, the client may send "uvgimme" |
| 524 | cards to the server. A uvgimme card requests that the server send |
| 525 | unversioned content to the client. The format of a uvgimme card is |
| 526 | as follows: |
| 527 | |
| 528 | <pre> |
| 529 |