Fossil SCM
eol-spacing in documentation
Commit
d65540f5a9180d861afe2093adf81de209d0cafd2c842793e7e4662c0ff450ed
Parent
abf865bb5f0ed0f…
20 files changed
+55
-55
+1
-1
+4
-4
+1
-1
+3
-3
+1
-1
+4
-4
+3
-3
+2
-2
+1
-1
+2
-2
+4
-4
+13
-13
+1
-1
+42
-42
+2
-2
+1
-1
+14
-14
+1
-1
+1
-1
~
www/caps/ref.html
~
www/checkin_names.wiki
~
www/customskin.md
~
www/delta_format.wiki
~
www/embeddeddoc.wiki
~
www/fileformat.wiki
~
www/fossil-v-git.wiki
~
www/hashpolicy.wiki
~
www/image-format-vs-repo-size.md
~
www/mdtest/test1.md
~
www/mirrorlimitations.md
~
www/mirrortogithub.md
~
www/rebaseharm.md
~
www/server/any/none.md
~
www/server/index.html
~
www/server/whyuseaserver.wiki
~
www/server/windows/iis.md
~
www/serverext.wiki
~
www/sync.wiki
~
www/tls-nginx.md
+55
-55
| --- www/caps/ref.html | ||
| +++ www/caps/ref.html | ||
| @@ -22,13 +22,13 @@ | ||
| 22 | 22 | } |
| 23 | 23 | </style> |
| 24 | 24 | |
| 25 | 25 | <p>Here we document each currently-defined user capability character in |
| 26 | 26 | more detail than the brief summary on the <a |
| 27 | -href="/setup_ucap_list">“key” page</a> in the Fossil user editor. Each | |
| 27 | +href="/setup_ucap_list">“key� page</a> in the Fossil user editor. Each | |
| 28 | 28 | row gives the capability letter used in the Fossil user editor followed |
| 29 | -by the C code’s name for that cap within the <tt>FossilUserPerms</tt> | |
| 29 | +by the C code’s name for that cap within the <tt>FossilUserPerms</tt> | |
| 30 | 30 | object, so you can use this reference both from the UI down and from the |
| 31 | 31 | C code up.</p> |
| 32 | 32 | |
| 33 | 33 | <p>The <a href="https://en.wikipedia.org/wiki/Mnemonic">mnemonics</a> |
| 34 | 34 | given here vary from obviously-correct to <i>post facto</i> |
| @@ -52,36 +52,36 @@ | ||
| 52 | 52 | Admin users have <em>all</em> of the capabilities below except for |
| 53 | 53 | <a href="#s">setup</a>, <a herf="#x">Private</a>, and <a href="#y">WrUnver</a>. |
| 54 | 54 | See <a href="admin-v-setup.md">Admin vs. Setup</a> for a more |
| 55 | 55 | nuanced discussion. Mnemonic: <b>a</b>dministrate. |
| 56 | 56 | </td> |
| 57 | - </tr> | |
| 57 | + </tr> | |
| 58 | 58 | |
| 59 | 59 | <tr id="b"> |
| 60 | 60 | <th>b</th> |
| 61 | 61 | <th>Attach</th> |
| 62 | 62 | <td> |
| 63 | 63 | Add attachments to wiki articles or tickets. Mnemonics: <b>b</b>ind, |
| 64 | 64 | <b>b</b>utton, <b>b</b>ond, or <b>b</b>olt. |
| 65 | 65 | </td> |
| 66 | - </tr> | |
| 66 | + </tr> | |
| 67 | 67 | |
| 68 | 68 | <tr id="c"> |
| 69 | 69 | <th>c</th> |
| 70 | 70 | <th>ApndTkt</th> |
| 71 | 71 | <td> |
| 72 | 72 | Append comments to existing tickets. Mnemonic: <b>c</b>omment. |
| 73 | 73 | </td> |
| 74 | - </tr> | |
| 74 | + </tr> | |
| 75 | 75 | |
| 76 | 76 | <tr id="d"> |
| 77 | 77 | <th>d</th> |
| 78 | 78 | <th>Delete</th> |
| 79 | 79 | <td> |
| 80 | 80 | Delete wiki articles or tickets. Mnemonic: <b>d</b>elete. |
| 81 | 81 | </td> |
| 82 | - </tr> | |
| 82 | + </tr> | |
| 83 | 83 | |
| 84 | 84 | <tr id="e"> |
| 85 | 85 | <th>e</th> |
| 86 | 86 | <th>RdAddr</th> |
| 87 | 87 | <td> |
| @@ -90,11 +90,11 @@ | ||
| 90 | 90 | identifying information</a> (PII) about other users such as email |
| 91 | 91 | addresses. Mnemonics: show <b>e</b>mail addresses; or |
| 92 | 92 | <b>E</b>urope, home of <a |
| 93 | 93 | href="https://en.wikipedia.org/wiki/General_Data_Protection_Regulation">GDPR</a>. |
| 94 | 94 | </td> |
| 95 | - </tr> | |
| 95 | + </tr> | |
| 96 | 96 | |
| 97 | 97 | <tr id="f"> |
| 98 | 98 | <th>f</th> |
| 99 | 99 | <th>NewWiki</th> |
| 100 | 100 | <td> |
| @@ -110,24 +110,24 @@ | ||
| 110 | 110 | <td> |
| 111 | 111 | Clone the repository. Note that this is distinct from <a |
| 112 | 112 | href="#o">check-out capability, <b>o</b></a>. Mnemonic: |
| 113 | 113 | <b>g</b>et. |
| 114 | 114 | </td> |
| 115 | - </tr> | |
| 115 | + </tr> | |
| 116 | 116 | |
| 117 | 117 | <tr id="h"> |
| 118 | 118 | <th>h</th> |
| 119 | 119 | <th>Hyperlink</th> |
| 120 | 120 | <td> |
| 121 | 121 | Get hyperlinks in generated HTML which link you to other parts of |
| 122 | 122 | the repository. This capability exists so we can deny it to the |
| 123 | - “nobody” category, to <a href="../antibot.wiki">prevent bots from | |
| 124 | - wandering around aimlessly</a> in the site’s hyperlink web, <a | |
| 123 | + “nobody� category, to <a href="../antibot.wiki">prevent bots from | |
| 124 | + wandering around aimlessly</a> in the site’s hyperlink web, <a | |
| 125 | 125 | href="../loadmgmt.md">chewing up server resources</a> to little |
| 126 | 126 | good purpose. Mnemonic: <b>h</b>yperlink. |
| 127 | 127 | </td> |
| 128 | - </tr> | |
| 128 | + </tr> | |
| 129 | 129 | |
| 130 | 130 | <tr id="i"> |
| 131 | 131 | <th>i</th> |
| 132 | 132 | <th>Write</th> |
| 133 | 133 | <td> |
| @@ -136,20 +136,20 @@ | ||
| 136 | 136 | local clone, only from syncing those changes up to the parent |
| 137 | 137 | repo, and then <a href="./basics.md#webonly">only over HTTP</a>. |
| 138 | 138 | Granting this capability also grants <b>o (Read)</b> Mnemonics: |
| 139 | 139 | <b>i</b>nput, check <b>i</b>n changes. |
| 140 | 140 | </td> |
| 141 | - </tr> | |
| 141 | + </tr> | |
| 142 | 142 | |
| 143 | 143 | <tr id="j"> |
| 144 | 144 | <th>j</th> |
| 145 | 145 | <th>RdWiki</th> |
| 146 | 146 | <td> |
| 147 | 147 | View wiki articles. Mnemonic: in<b>j</b>est page content. (All |
| 148 | 148 | right, you critics, you do better, then.) |
| 149 | 149 | </td> |
| 150 | - </tr> | |
| 150 | + </tr> | |
| 151 | 151 | |
| 152 | 152 | <tr id="k"> |
| 153 | 153 | <th>k</th> |
| 154 | 154 | <th>WrWiki</th> |
| 155 | 155 | <td> |
| @@ -156,74 +156,74 @@ | ||
| 156 | 156 | Edit wiki articles. Granting this capability also grants <a |
| 157 | 157 | href="#j"><b>RdWiki</b></a> and <a href="#m"><b>ApndWiki</b></a>, |
| 158 | 158 | but it does <em>not</em> grant <a href="#f"><b>NewWiki</b></a>! |
| 159 | 159 | Mnemonic: <b>k</b>ontribute. |
| 160 | 160 | </td> |
| 161 | - </tr> | |
| 161 | + </tr> | |
| 162 | 162 | |
| 163 | 163 | <tr id="l"> |
| 164 | 164 | <th>l</th> |
| 165 | 165 | <th>ModWiki</th> |
| 166 | 166 | <td> |
| 167 | 167 | Moderate <a href="#m">wiki article appends</a>. Appends do not get |
| 168 | - saved permanently to the receiving repo’s block chain until <a | |
| 168 | + saved permanently to the receiving repo’s block chain until <a | |
| 169 | 169 | href="#s">Setup</a> or someone with this cap approves it. |
| 170 | 170 | Mnemonic: a<b>l</b>low. |
| 171 | 171 | </td> |
| 172 | - </tr> | |
| 172 | + </tr> | |
| 173 | 173 | |
| 174 | 174 | <tr id="m"> |
| 175 | 175 | <th>m</th> |
| 176 | 176 | <th>ApndWiki</th> |
| 177 | 177 | <td> |
| 178 | 178 | Append content to existing wiki articles. Mnemonic: a<b>m</b>end |
| 179 | 179 | wiki |
| 180 | 180 | </td> |
| 181 | - </tr> | |
| 181 | + </tr> | |
| 182 | 182 | |
| 183 | 183 | <tr id="n"> |
| 184 | 184 | <th>n</th> |
| 185 | 185 | <th>NewTkt</th> |
| 186 | 186 | <td> |
| 187 | 187 | File new tickets. Mnemonic: <b>n</b>ew ticket. |
| 188 | 188 | </td> |
| 189 | - </tr> | |
| 189 | + </tr> | |
| 190 | 190 | |
| 191 | 191 | <tr id="o"> |
| 192 | 192 | <th>o</th> |
| 193 | 193 | <th>Read</th> |
| 194 | 194 | <td> |
| 195 | 195 | Read repository content from a remote Fossil instance over |
| 196 | 196 | HTTP. See <a href="index.md#read-v-clone">Reading vs. |
| 197 | 197 | Cloning</a>. Mnemonic: check <b>o</b>ut remote repo contents. |
| 198 | 198 | </td> |
| 199 | - </tr> | |
| 199 | + </tr> | |
| 200 | 200 | |
| 201 | 201 | <tr id="p"> |
| 202 | 202 | <th>p</th> |
| 203 | 203 | <th>Password</th> |
| 204 | 204 | <td> |
| 205 | - Change one’s own password. Mnemonic: <b>p</b>assword. | |
| 205 | + Change one’s own password. Mnemonic: <b>p</b>assword. | |
| 206 | 206 | </td> |
| 207 | - </tr> | |
| 207 | + </tr> | |
| 208 | 208 | |
| 209 | 209 | <tr id="q"> |
| 210 | 210 | <th>q</th> |
| 211 | 211 | <th>ModTkt</th> |
| 212 | 212 | <td> |
| 213 | 213 | Moderate tickets: delete comments appended to tickets. Mnemonic: |
| 214 | 214 | <b>q</b>uash noise commentary. |
| 215 | 215 | </td> |
| 216 | - </tr> | |
| 216 | + </tr> | |
| 217 | 217 | |
| 218 | 218 | <tr id="r"> |
| 219 | 219 | <th>r</th> |
| 220 | 220 | <th>RdTkt</th> |
| 221 | 221 | <td> |
| 222 | 222 | View existing tickets. Mnemonic: <b>r</b>ead tickets. |
| 223 | 223 | </td> |
| 224 | - </tr> | |
| 224 | + </tr> | |
| 225 | 225 | |
| 226 | 226 | <tr id="s"> |
| 227 | 227 | <th>s</th> |
| 228 | 228 | <th>Setup</th> |
| 229 | 229 | <td> |
| @@ -235,71 +235,71 @@ | ||
| 235 | 235 | <tr id="t"> |
| 236 | 236 | <th>t</th> |
| 237 | 237 | <th>TktFmt</th> |
| 238 | 238 | <td> |
| 239 | 239 | Create new ticket report formats. Note that although this allows |
| 240 | - the user to provide SQL code to be run in the server’s context, | |
| 241 | - and this capability is given to the untrusted “anonymous” user | |
| 240 | + the user to provide SQL code to be run in the server’s context, | |
| 241 | + and this capability is given to the untrusted “anonymous� user | |
| 242 | 242 | category by default, this is a safe capability to give to users |
| 243 | 243 | because it is internally restricted to read-only queries on the |
| 244 | 244 | tickets table only. (This restriction is done with a SQLite |
| 245 | 245 | authorization hook, not by any method so weak as SQL text |
| 246 | 246 | filtering.) Mnemonic: new <b>t</b>icket report. |
| 247 | 247 | </td> |
| 248 | - </tr> | |
| 248 | + </tr> | |
| 249 | 249 | |
| 250 | 250 | <tr id="u"> |
| 251 | 251 | <th>u</th> |
| 252 | 252 | <th>n/a</th> |
| 253 | 253 | <td> |
| 254 | - Inherit all capabilities of the “reader” user category; does not | |
| 254 | + Inherit all capabilities of the “reader� user category; does not | |
| 255 | 255 | have a dedicated flag internally within Fossil. Mnemonic: |
| 256 | 256 | <a href="./index.md#ucat"><b>u</b>ser</a> |
| 257 | 257 | </td> |
| 258 | - </tr> | |
| 258 | + </tr> | |
| 259 | 259 | |
| 260 | 260 | <tr id="v"> |
| 261 | 261 | <th>v</th> |
| 262 | 262 | <th>n/a</th> |
| 263 | 263 | <td> |
| 264 | - Inherit all capabilities of the “developer” user category; does | |
| 264 | + Inherit all capabilities of the “developer� user category; does | |
| 265 | 265 | not have a dedicated flag internally within Fossil. Mnemonic: |
| 266 | 266 | de<b>v</b>eloper. |
| 267 | 267 | </td> |
| 268 | - </tr> | |
| 268 | + </tr> | |
| 269 | 269 | |
| 270 | 270 | <tr id="w"> |
| 271 | 271 | <th>w</th> |
| 272 | 272 | <th>WrTkt</th> |
| 273 | 273 | <td> |
| 274 | 274 | Edit existing tickets. Granting this capability also grants <a |
| 275 | 275 | href="#r"><b>RdTkt</b></a>, <a href="#c"><b>ApndTkt</b></a>, and |
| 276 | 276 | <a href="#n"><b>NewTkt</b></a>. Mnemonic: <b>w</b>rite to ticket. |
| 277 | 277 | </td> |
| 278 | - </tr> | |
| 278 | + </tr> | |
| 279 | 279 | |
| 280 | 280 | <tr id="x"> |
| 281 | 281 | <th>x</th> |
| 282 | 282 | <th>Private</th> |
| 283 | 283 | <td> |
| 284 | 284 | Push or pull <a href="../private.wiki">private branches</a>. |
| 285 | - Mnemonic: e<b>x</b>clusivity; “x” connotes unknown material in | |
| 285 | + Mnemonic: e<b>x</b>clusivity; “x� connotes unknown material in | |
| 286 | 286 | many Western languages due to its <a |
| 287 | - href="https://en.wikipedia.org/wiki/La_Géométrie#The_text">traditional | |
| 287 | + href="https://en.wikipedia.org/wiki/La_Géométrie#The_text">traditional | |
| 288 | 288 | use in mathematics</a>. |
| 289 | 289 | </td> |
| 290 | - </tr> | |
| 290 | + </tr> | |
| 291 | 291 | |
| 292 | 292 | <tr id="y"> |
| 293 | 293 | <th>y</th> |
| 294 | 294 | <th>WrUnver</th> |
| 295 | 295 | <td> |
| 296 | 296 | Push <a href="../unvers.wiki">unversioned content</a>. Mnemonic: |
| 297 | 297 | <b>y</b>ield, <a href="https://en.wiktionary.org/wiki/yield">sense |
| 298 | - 4</a>: “hand over.” | |
| 298 | + 4</a>: “hand over.� | |
| 299 | 299 | </td> |
| 300 | - </tr> | |
| 300 | + </tr> | |
| 301 | 301 | |
| 302 | 302 | <tr id="z"> |
| 303 | 303 | <th>z</th> |
| 304 | 304 | <th>Zip</th> |
| 305 | 305 | <td> |
| @@ -310,103 +310,103 @@ | ||
| 310 | 310 | expensive capability to grant, because creating such archives can |
| 311 | 311 | put a large load on <a href="../server/">a Fossil server</a> which |
| 312 | 312 | you may then need to <a href="../loadmgmt.md">manage</a>. |
| 313 | 313 | Mnemonic: <b>z</b>ip file download. |
| 314 | 314 | </td> |
| 315 | - </tr> | |
| 315 | + </tr> | |
| 316 | 316 | |
| 317 | 317 | <tr id="2"> |
| 318 | 318 | <th>2</th> |
| 319 | 319 | <th>RdForum</th> |
| 320 | 320 | <td> |
| 321 | 321 | Read <a href="../forum.wiki">forum posts</a> by other users. |
| 322 | 322 | Mnemonic: from thee <b>2</b> me. |
| 323 | 323 | </td> |
| 324 | - </tr> | |
| 324 | + </tr> | |
| 325 | 325 | |
| 326 | 326 | <tr id="3"> |
| 327 | 327 | <th>3</th> |
| 328 | 328 | <th>WrForum</th> |
| 329 | 329 | <td> |
| 330 | 330 | Create new forum threads, reply to threads created by others, and |
| 331 | - edit one’s own posts. New posts are <a | |
| 331 | + edit one’s own posts. New posts are <a | |
| 332 | 332 | href="../forum.wiki#moderation">held for moderation</a> and do |
| 333 | 333 | not appear in repo clones or syncs. Granting this capability also |
| 334 | 334 | grants <a href="#2"><b>RdForum</b></a>. Mnemonic: post for |
| 335 | 335 | <b>3</b> audiences: me, <a href="#5">the mods</a>, and <a |
| 336 | 336 | href="https://en.wikipedia.org/wiki/The_Man">the Man</a>. |
| 337 | 337 | </td> |
| 338 | - </tr> | |
| 338 | + </tr> | |
| 339 | 339 | |
| 340 | 340 | <tr id="4"> |
| 341 | 341 | <th>4</th> |
| 342 | 342 | <th>WrTForum</th> |
| 343 | 343 | <td> |
| 344 | 344 | Extends <a href="#3"><b>WrForum</b></a>, bypassing the moderation |
| 345 | 345 | and sync restrictions. Mnemonic: post <b>4</b> immediate release. |
| 346 | 346 | </td> |
| 347 | - </tr> | |
| 347 | + </tr> | |
| 348 | 348 | |
| 349 | 349 | <tr id="5"> |
| 350 | 350 | <th>5</th> |
| 351 | 351 | <th>ModForum</th> |
| 352 | 352 | <td> |
| 353 | 353 | <a href="../forum.wiki#moderation">Moderate forum posts</a>. |
| 354 | 354 | Granting this capability also grants <a |
| 355 | 355 | href="#4"><b>WrTForum</b></a> and <a href="#2"><b>RdForum</b></a>, |
| 356 | 356 | so a user with this cap never has to moderate their own posts. |
| 357 | - Mnemonic: “May I have <b>5</b> seconds of your time, honored | |
| 358 | - Gatekeeper?” | |
| 357 | + Mnemonic: “May I have <b>5</b> seconds of your time, honored | |
| 358 | + Gatekeeper?� | |
| 359 | 359 | </td> |
| 360 | - </tr> | |
| 360 | + </tr> | |
| 361 | 361 | |
| 362 | 362 | <tr id="6"> |
| 363 | 363 | <th>6</th> |
| 364 | 364 | <th>AdminForum</th> |
| 365 | 365 | <td> |
| 366 | 366 | Users with this capability see a checkbox on unmoderated forum |
| 367 | - posts labeled “Trust user X so that future posts by user X do not | |
| 368 | - require moderation.” Checking that box and then clicking the | |
| 369 | - moderator-only “Approve” button on that post grants <a | |
| 370 | - href="#4"><b>WrTForum</b></a> capability to that post’s author. | |
| 367 | + posts labeled “Trust user X so that future posts by user X do not | |
| 368 | + require moderation.� Checking that box and then clicking the | |
| 369 | + moderator-only “Approve� button on that post grants <a | |
| 370 | + href="#4"><b>WrTForum</b></a> capability to that post’s author. | |
| 371 | 371 | There is currently no UI for a user with this cap to |
| 372 | 372 | <em>revoke</em> trust from a user once it is granted; only <a |
| 373 | 373 | href="#a"><b>Admin</b></a> and <a href="#s"><b>Setup</b></a> can |
| 374 | 374 | currently revoke granted caps. Granting this capability also |
| 375 | 375 | grants <a href="#5"><b>ModForum</b></a> and those it in turn |
| 376 | - grants. Mnemonic: “I’m <b>6</b> [sick] of hitting Approve on your | |
| 377 | - posts!” | |
| 376 | + grants. Mnemonic: “I’m <b>6</b> [sick] of hitting Approve on your | |
| 377 | + posts!� | |
| 378 | 378 | </td> |
| 379 | - </tr> | |
| 379 | + </tr> | |
| 380 | 380 | |
| 381 | 381 | <tr id="7"> |
| 382 | 382 | <th>7</th> |
| 383 | 383 | <th>EmailAlert</th> |
| 384 | 384 | <td> |
| 385 | 385 | User can sign up for <a href="../alerts.md">email alerts</a>. |
| 386 | 386 | Mnemonic: <a href="https://en.wikipedia.org/wiki/Heaven_Can_Wait">Seven can |
| 387 | - wait</a>, I’ve got email to read now. | |
| 387 | + wait</a>, I’ve got email to read now. | |
| 388 | 388 | </td> |
| 389 | - </tr> | |
| 389 | + </tr> | |
| 390 | 390 | |
| 391 | 391 | <tr id="A"> |
| 392 | 392 | <th>A</th> |
| 393 | 393 | <th>Announce</th> |
| 394 | 394 | <td> |
| 395 | 395 | Send email announcements to users <a href="#7">signed up to |
| 396 | 396 | receive them</a>. Mnemonic: <b>a</b>nnounce. |
| 397 | 397 | </td> |
| 398 | - </tr> | |
| 398 | + </tr> | |
| 399 | 399 | |
| 400 | 400 | <tr id="D"> |
| 401 | 401 | <th>D</th> |
| 402 | 402 | <th>Debug</th> |
| 403 | 403 | <td> |
| 404 | 404 | Enable debugging features. Mnemonic: <b>d</b>ebug. |
| 405 | 405 | </td> |
| 406 | - </tr> | |
| 406 | + </tr> | |
| 407 | 407 | </table> |
| 408 | 408 | |
| 409 | 409 | <hr/> |
| 410 | 410 | |
| 411 | 411 | <p id="backlink"><a href="./"><em>Back to Administering User |
| 412 | 412 | Capabilities</em></a></p> |
| 413 | 413 |
| --- www/caps/ref.html | |
| +++ www/caps/ref.html | |
| @@ -22,13 +22,13 @@ | |
| 22 | } |
| 23 | </style> |
| 24 | |
| 25 | <p>Here we document each currently-defined user capability character in |
| 26 | more detail than the brief summary on the <a |
| 27 | href="/setup_ucap_list">“key” page</a> in the Fossil user editor. Each |
| 28 | row gives the capability letter used in the Fossil user editor followed |
| 29 | by the C code’s name for that cap within the <tt>FossilUserPerms</tt> |
| 30 | object, so you can use this reference both from the UI down and from the |
| 31 | C code up.</p> |
| 32 | |
| 33 | <p>The <a href="https://en.wikipedia.org/wiki/Mnemonic">mnemonics</a> |
| 34 | given here vary from obviously-correct to <i>post facto</i> |
| @@ -52,36 +52,36 @@ | |
| 52 | Admin users have <em>all</em> of the capabilities below except for |
| 53 | <a href="#s">setup</a>, <a herf="#x">Private</a>, and <a href="#y">WrUnver</a>. |
| 54 | See <a href="admin-v-setup.md">Admin vs. Setup</a> for a more |
| 55 | nuanced discussion. Mnemonic: <b>a</b>dministrate. |
| 56 | </td> |
| 57 | </tr> |
| 58 | |
| 59 | <tr id="b"> |
| 60 | <th>b</th> |
| 61 | <th>Attach</th> |
| 62 | <td> |
| 63 | Add attachments to wiki articles or tickets. Mnemonics: <b>b</b>ind, |
| 64 | <b>b</b>utton, <b>b</b>ond, or <b>b</b>olt. |
| 65 | </td> |
| 66 | </tr> |
| 67 | |
| 68 | <tr id="c"> |
| 69 | <th>c</th> |
| 70 | <th>ApndTkt</th> |
| 71 | <td> |
| 72 | Append comments to existing tickets. Mnemonic: <b>c</b>omment. |
| 73 | </td> |
| 74 | </tr> |
| 75 | |
| 76 | <tr id="d"> |
| 77 | <th>d</th> |
| 78 | <th>Delete</th> |
| 79 | <td> |
| 80 | Delete wiki articles or tickets. Mnemonic: <b>d</b>elete. |
| 81 | </td> |
| 82 | </tr> |
| 83 | |
| 84 | <tr id="e"> |
| 85 | <th>e</th> |
| 86 | <th>RdAddr</th> |
| 87 | <td> |
| @@ -90,11 +90,11 @@ | |
| 90 | identifying information</a> (PII) about other users such as email |
| 91 | addresses. Mnemonics: show <b>e</b>mail addresses; or |
| 92 | <b>E</b>urope, home of <a |
| 93 | href="https://en.wikipedia.org/wiki/General_Data_Protection_Regulation">GDPR</a>. |
| 94 | </td> |
| 95 | </tr> |
| 96 | |
| 97 | <tr id="f"> |
| 98 | <th>f</th> |
| 99 | <th>NewWiki</th> |
| 100 | <td> |
| @@ -110,24 +110,24 @@ | |
| 110 | <td> |
| 111 | Clone the repository. Note that this is distinct from <a |
| 112 | href="#o">check-out capability, <b>o</b></a>. Mnemonic: |
| 113 | <b>g</b>et. |
| 114 | </td> |
| 115 | </tr> |
| 116 | |
| 117 | <tr id="h"> |
| 118 | <th>h</th> |
| 119 | <th>Hyperlink</th> |
| 120 | <td> |
| 121 | Get hyperlinks in generated HTML which link you to other parts of |
| 122 | the repository. This capability exists so we can deny it to the |
| 123 | “nobody” category, to <a href="../antibot.wiki">prevent bots from |
| 124 | wandering around aimlessly</a> in the site’s hyperlink web, <a |
| 125 | href="../loadmgmt.md">chewing up server resources</a> to little |
| 126 | good purpose. Mnemonic: <b>h</b>yperlink. |
| 127 | </td> |
| 128 | </tr> |
| 129 | |
| 130 | <tr id="i"> |
| 131 | <th>i</th> |
| 132 | <th>Write</th> |
| 133 | <td> |
| @@ -136,20 +136,20 @@ | |
| 136 | local clone, only from syncing those changes up to the parent |
| 137 | repo, and then <a href="./basics.md#webonly">only over HTTP</a>. |
| 138 | Granting this capability also grants <b>o (Read)</b> Mnemonics: |
| 139 | <b>i</b>nput, check <b>i</b>n changes. |
| 140 | </td> |
| 141 | </tr> |
| 142 | |
| 143 | <tr id="j"> |
| 144 | <th>j</th> |
| 145 | <th>RdWiki</th> |
| 146 | <td> |
| 147 | View wiki articles. Mnemonic: in<b>j</b>est page content. (All |
| 148 | right, you critics, you do better, then.) |
| 149 | </td> |
| 150 | </tr> |
| 151 | |
| 152 | <tr id="k"> |
| 153 | <th>k</th> |
| 154 | <th>WrWiki</th> |
| 155 | <td> |
| @@ -156,74 +156,74 @@ | |
| 156 | Edit wiki articles. Granting this capability also grants <a |
| 157 | href="#j"><b>RdWiki</b></a> and <a href="#m"><b>ApndWiki</b></a>, |
| 158 | but it does <em>not</em> grant <a href="#f"><b>NewWiki</b></a>! |
| 159 | Mnemonic: <b>k</b>ontribute. |
| 160 | </td> |
| 161 | </tr> |
| 162 | |
| 163 | <tr id="l"> |
| 164 | <th>l</th> |
| 165 | <th>ModWiki</th> |
| 166 | <td> |
| 167 | Moderate <a href="#m">wiki article appends</a>. Appends do not get |
| 168 | saved permanently to the receiving repo’s block chain until <a |
| 169 | href="#s">Setup</a> or someone with this cap approves it. |
| 170 | Mnemonic: a<b>l</b>low. |
| 171 | </td> |
| 172 | </tr> |
| 173 | |
| 174 | <tr id="m"> |
| 175 | <th>m</th> |
| 176 | <th>ApndWiki</th> |
| 177 | <td> |
| 178 | Append content to existing wiki articles. Mnemonic: a<b>m</b>end |
| 179 | wiki |
| 180 | </td> |
| 181 | </tr> |
| 182 | |
| 183 | <tr id="n"> |
| 184 | <th>n</th> |
| 185 | <th>NewTkt</th> |
| 186 | <td> |
| 187 | File new tickets. Mnemonic: <b>n</b>ew ticket. |
| 188 | </td> |
| 189 | </tr> |
| 190 | |
| 191 | <tr id="o"> |
| 192 | <th>o</th> |
| 193 | <th>Read</th> |
| 194 | <td> |
| 195 | Read repository content from a remote Fossil instance over |
| 196 | HTTP. See <a href="index.md#read-v-clone">Reading vs. |
| 197 | Cloning</a>. Mnemonic: check <b>o</b>ut remote repo contents. |
| 198 | </td> |
| 199 | </tr> |
| 200 | |
| 201 | <tr id="p"> |
| 202 | <th>p</th> |
| 203 | <th>Password</th> |
| 204 | <td> |
| 205 | Change one’s own password. Mnemonic: <b>p</b>assword. |
| 206 | </td> |
| 207 | </tr> |
| 208 | |
| 209 | <tr id="q"> |
| 210 | <th>q</th> |
| 211 | <th>ModTkt</th> |
| 212 | <td> |
| 213 | Moderate tickets: delete comments appended to tickets. Mnemonic: |
| 214 | <b>q</b>uash noise commentary. |
| 215 | </td> |
| 216 | </tr> |
| 217 | |
| 218 | <tr id="r"> |
| 219 | <th>r</th> |
| 220 | <th>RdTkt</th> |
| 221 | <td> |
| 222 | View existing tickets. Mnemonic: <b>r</b>ead tickets. |
| 223 | </td> |
| 224 | </tr> |
| 225 | |
| 226 | <tr id="s"> |
| 227 | <th>s</th> |
| 228 | <th>Setup</th> |
| 229 | <td> |
| @@ -235,71 +235,71 @@ | |
| 235 | <tr id="t"> |
| 236 | <th>t</th> |
| 237 | <th>TktFmt</th> |
| 238 | <td> |
| 239 | Create new ticket report formats. Note that although this allows |
| 240 | the user to provide SQL code to be run in the server’s context, |
| 241 | and this capability is given to the untrusted “anonymous” user |
| 242 | category by default, this is a safe capability to give to users |
| 243 | because it is internally restricted to read-only queries on the |
| 244 | tickets table only. (This restriction is done with a SQLite |
| 245 | authorization hook, not by any method so weak as SQL text |
| 246 | filtering.) Mnemonic: new <b>t</b>icket report. |
| 247 | </td> |
| 248 | </tr> |
| 249 | |
| 250 | <tr id="u"> |
| 251 | <th>u</th> |
| 252 | <th>n/a</th> |
| 253 | <td> |
| 254 | Inherit all capabilities of the “reader” user category; does not |
| 255 | have a dedicated flag internally within Fossil. Mnemonic: |
| 256 | <a href="./index.md#ucat"><b>u</b>ser</a> |
| 257 | </td> |
| 258 | </tr> |
| 259 | |
| 260 | <tr id="v"> |
| 261 | <th>v</th> |
| 262 | <th>n/a</th> |
| 263 | <td> |
| 264 | Inherit all capabilities of the “developer” user category; does |
| 265 | not have a dedicated flag internally within Fossil. Mnemonic: |
| 266 | de<b>v</b>eloper. |
| 267 | </td> |
| 268 | </tr> |
| 269 | |
| 270 | <tr id="w"> |
| 271 | <th>w</th> |
| 272 | <th>WrTkt</th> |
| 273 | <td> |
| 274 | Edit existing tickets. Granting this capability also grants <a |
| 275 | href="#r"><b>RdTkt</b></a>, <a href="#c"><b>ApndTkt</b></a>, and |
| 276 | <a href="#n"><b>NewTkt</b></a>. Mnemonic: <b>w</b>rite to ticket. |
| 277 | </td> |
| 278 | </tr> |
| 279 | |
| 280 | <tr id="x"> |
| 281 | <th>x</th> |
| 282 | <th>Private</th> |
| 283 | <td> |
| 284 | Push or pull <a href="../private.wiki">private branches</a>. |
| 285 | Mnemonic: e<b>x</b>clusivity; “x” connotes unknown material in |
| 286 | many Western languages due to its <a |
| 287 | href="https://en.wikipedia.org/wiki/La_Géométrie#The_text">traditional |
| 288 | use in mathematics</a>. |
| 289 | </td> |
| 290 | </tr> |
| 291 | |
| 292 | <tr id="y"> |
| 293 | <th>y</th> |
| 294 | <th>WrUnver</th> |
| 295 | <td> |
| 296 | Push <a href="../unvers.wiki">unversioned content</a>. Mnemonic: |
| 297 | <b>y</b>ield, <a href="https://en.wiktionary.org/wiki/yield">sense |
| 298 | 4</a>: “hand over.” |
| 299 | </td> |
| 300 | </tr> |
| 301 | |
| 302 | <tr id="z"> |
| 303 | <th>z</th> |
| 304 | <th>Zip</th> |
| 305 | <td> |
| @@ -310,103 +310,103 @@ | |
| 310 | expensive capability to grant, because creating such archives can |
| 311 | put a large load on <a href="../server/">a Fossil server</a> which |
| 312 | you may then need to <a href="../loadmgmt.md">manage</a>. |
| 313 | Mnemonic: <b>z</b>ip file download. |
| 314 | </td> |
| 315 | </tr> |
| 316 | |
| 317 | <tr id="2"> |
| 318 | <th>2</th> |
| 319 | <th>RdForum</th> |
| 320 | <td> |
| 321 | Read <a href="../forum.wiki">forum posts</a> by other users. |
| 322 | Mnemonic: from thee <b>2</b> me. |
| 323 | </td> |
| 324 | </tr> |
| 325 | |
| 326 | <tr id="3"> |
| 327 | <th>3</th> |
| 328 | <th>WrForum</th> |
| 329 | <td> |
| 330 | Create new forum threads, reply to threads created by others, and |
| 331 | edit one’s own posts. New posts are <a |
| 332 | href="../forum.wiki#moderation">held for moderation</a> and do |
| 333 | not appear in repo clones or syncs. Granting this capability also |
| 334 | grants <a href="#2"><b>RdForum</b></a>. Mnemonic: post for |
| 335 | <b>3</b> audiences: me, <a href="#5">the mods</a>, and <a |
| 336 | href="https://en.wikipedia.org/wiki/The_Man">the Man</a>. |
| 337 | </td> |
| 338 | </tr> |
| 339 | |
| 340 | <tr id="4"> |
| 341 | <th>4</th> |
| 342 | <th>WrTForum</th> |
| 343 | <td> |
| 344 | Extends <a href="#3"><b>WrForum</b></a>, bypassing the moderation |
| 345 | and sync restrictions. Mnemonic: post <b>4</b> immediate release. |
| 346 | </td> |
| 347 | </tr> |
| 348 | |
| 349 | <tr id="5"> |
| 350 | <th>5</th> |
| 351 | <th>ModForum</th> |
| 352 | <td> |
| 353 | <a href="../forum.wiki#moderation">Moderate forum posts</a>. |
| 354 | Granting this capability also grants <a |
| 355 | href="#4"><b>WrTForum</b></a> and <a href="#2"><b>RdForum</b></a>, |
| 356 | so a user with this cap never has to moderate their own posts. |
| 357 | Mnemonic: “May I have <b>5</b> seconds of your time, honored |
| 358 | Gatekeeper?” |
| 359 | </td> |
| 360 | </tr> |
| 361 | |
| 362 | <tr id="6"> |
| 363 | <th>6</th> |
| 364 | <th>AdminForum</th> |
| 365 | <td> |
| 366 | Users with this capability see a checkbox on unmoderated forum |
| 367 | posts labeled “Trust user X so that future posts by user X do not |
| 368 | require moderation.” Checking that box and then clicking the |
| 369 | moderator-only “Approve” button on that post grants <a |
| 370 | href="#4"><b>WrTForum</b></a> capability to that post’s author. |
| 371 | There is currently no UI for a user with this cap to |
| 372 | <em>revoke</em> trust from a user once it is granted; only <a |
| 373 | href="#a"><b>Admin</b></a> and <a href="#s"><b>Setup</b></a> can |
| 374 | currently revoke granted caps. Granting this capability also |
| 375 | grants <a href="#5"><b>ModForum</b></a> and those it in turn |
| 376 | grants. Mnemonic: “I’m <b>6</b> [sick] of hitting Approve on your |
| 377 | posts!” |
| 378 | </td> |
| 379 | </tr> |
| 380 | |
| 381 | <tr id="7"> |
| 382 | <th>7</th> |
| 383 | <th>EmailAlert</th> |
| 384 | <td> |
| 385 | User can sign up for <a href="../alerts.md">email alerts</a>. |
| 386 | Mnemonic: <a href="https://en.wikipedia.org/wiki/Heaven_Can_Wait">Seven can |
| 387 | wait</a>, I’ve got email to read now. |
| 388 | </td> |
| 389 | </tr> |
| 390 | |
| 391 | <tr id="A"> |
| 392 | <th>A</th> |
| 393 | <th>Announce</th> |
| 394 | <td> |
| 395 | Send email announcements to users <a href="#7">signed up to |
| 396 | receive them</a>. Mnemonic: <b>a</b>nnounce. |
| 397 | </td> |
| 398 | </tr> |
| 399 | |
| 400 | <tr id="D"> |
| 401 | <th>D</th> |
| 402 | <th>Debug</th> |
| 403 | <td> |
| 404 | Enable debugging features. Mnemonic: <b>d</b>ebug. |
| 405 | </td> |
| 406 | </tr> |
| 407 | </table> |
| 408 | |
| 409 | <hr/> |
| 410 | |
| 411 | <p id="backlink"><a href="./"><em>Back to Administering User |
| 412 | Capabilities</em></a></p> |
| 413 |
| --- www/caps/ref.html | |
| +++ www/caps/ref.html | |
| @@ -22,13 +22,13 @@ | |
| 22 | } |
| 23 | </style> |
| 24 | |
| 25 | <p>Here we document each currently-defined user capability character in |
| 26 | more detail than the brief summary on the <a |
| 27 | href="/setup_ucap_list">“key� page</a> in the Fossil user editor. Each |
| 28 | row gives the capability letter used in the Fossil user editor followed |
| 29 | by the C code’s name for that cap within the <tt>FossilUserPerms</tt> |
| 30 | object, so you can use this reference both from the UI down and from the |
| 31 | C code up.</p> |
| 32 | |
| 33 | <p>The <a href="https://en.wikipedia.org/wiki/Mnemonic">mnemonics</a> |
| 34 | given here vary from obviously-correct to <i>post facto</i> |
| @@ -52,36 +52,36 @@ | |
| 52 | Admin users have <em>all</em> of the capabilities below except for |
| 53 | <a href="#s">setup</a>, <a herf="#x">Private</a>, and <a href="#y">WrUnver</a>. |
| 54 | See <a href="admin-v-setup.md">Admin vs. Setup</a> for a more |
| 55 | nuanced discussion. Mnemonic: <b>a</b>dministrate. |
| 56 | </td> |
| 57 | </tr> |
| 58 | |
| 59 | <tr id="b"> |
| 60 | <th>b</th> |
| 61 | <th>Attach</th> |
| 62 | <td> |
| 63 | Add attachments to wiki articles or tickets. Mnemonics: <b>b</b>ind, |
| 64 | <b>b</b>utton, <b>b</b>ond, or <b>b</b>olt. |
| 65 | </td> |
| 66 | </tr> |
| 67 | |
| 68 | <tr id="c"> |
| 69 | <th>c</th> |
| 70 | <th>ApndTkt</th> |
| 71 | <td> |
| 72 | Append comments to existing tickets. Mnemonic: <b>c</b>omment. |
| 73 | </td> |
| 74 | </tr> |
| 75 | |
| 76 | <tr id="d"> |
| 77 | <th>d</th> |
| 78 | <th>Delete</th> |
| 79 | <td> |
| 80 | Delete wiki articles or tickets. Mnemonic: <b>d</b>elete. |
| 81 | </td> |
| 82 | </tr> |
| 83 | |
| 84 | <tr id="e"> |
| 85 | <th>e</th> |
| 86 | <th>RdAddr</th> |
| 87 | <td> |
| @@ -90,11 +90,11 @@ | |
| 90 | identifying information</a> (PII) about other users such as email |
| 91 | addresses. Mnemonics: show <b>e</b>mail addresses; or |
| 92 | <b>E</b>urope, home of <a |
| 93 | href="https://en.wikipedia.org/wiki/General_Data_Protection_Regulation">GDPR</a>. |
| 94 | </td> |
| 95 | </tr> |
| 96 | |
| 97 | <tr id="f"> |
| 98 | <th>f</th> |
| 99 | <th>NewWiki</th> |
| 100 | <td> |
| @@ -110,24 +110,24 @@ | |
| 110 | <td> |
| 111 | Clone the repository. Note that this is distinct from <a |
| 112 | href="#o">check-out capability, <b>o</b></a>. Mnemonic: |
| 113 | <b>g</b>et. |
| 114 | </td> |
| 115 | </tr> |
| 116 | |
| 117 | <tr id="h"> |
| 118 | <th>h</th> |
| 119 | <th>Hyperlink</th> |
| 120 | <td> |
| 121 | Get hyperlinks in generated HTML which link you to other parts of |
| 122 | the repository. This capability exists so we can deny it to the |
| 123 | “nobody� category, to <a href="../antibot.wiki">prevent bots from |
| 124 | wandering around aimlessly</a> in the site’s hyperlink web, <a |
| 125 | href="../loadmgmt.md">chewing up server resources</a> to little |
| 126 | good purpose. Mnemonic: <b>h</b>yperlink. |
| 127 | </td> |
| 128 | </tr> |
| 129 | |
| 130 | <tr id="i"> |
| 131 | <th>i</th> |
| 132 | <th>Write</th> |
| 133 | <td> |
| @@ -136,20 +136,20 @@ | |
| 136 | local clone, only from syncing those changes up to the parent |
| 137 | repo, and then <a href="./basics.md#webonly">only over HTTP</a>. |
| 138 | Granting this capability also grants <b>o (Read)</b> Mnemonics: |
| 139 | <b>i</b>nput, check <b>i</b>n changes. |
| 140 | </td> |
| 141 | </tr> |
| 142 | |
| 143 | <tr id="j"> |
| 144 | <th>j</th> |
| 145 | <th>RdWiki</th> |
| 146 | <td> |
| 147 | View wiki articles. Mnemonic: in<b>j</b>est page content. (All |
| 148 | right, you critics, you do better, then.) |
| 149 | </td> |
| 150 | </tr> |
| 151 | |
| 152 | <tr id="k"> |
| 153 | <th>k</th> |
| 154 | <th>WrWiki</th> |
| 155 | <td> |
| @@ -156,74 +156,74 @@ | |
| 156 | Edit wiki articles. Granting this capability also grants <a |
| 157 | href="#j"><b>RdWiki</b></a> and <a href="#m"><b>ApndWiki</b></a>, |
| 158 | but it does <em>not</em> grant <a href="#f"><b>NewWiki</b></a>! |
| 159 | Mnemonic: <b>k</b>ontribute. |
| 160 | </td> |
| 161 | </tr> |
| 162 | |
| 163 | <tr id="l"> |
| 164 | <th>l</th> |
| 165 | <th>ModWiki</th> |
| 166 | <td> |
| 167 | Moderate <a href="#m">wiki article appends</a>. Appends do not get |
| 168 | saved permanently to the receiving repo’s block chain until <a |
| 169 | href="#s">Setup</a> or someone with this cap approves it. |
| 170 | Mnemonic: a<b>l</b>low. |
| 171 | </td> |
| 172 | </tr> |
| 173 | |
| 174 | <tr id="m"> |
| 175 | <th>m</th> |
| 176 | <th>ApndWiki</th> |
| 177 | <td> |
| 178 | Append content to existing wiki articles. Mnemonic: a<b>m</b>end |
| 179 | wiki |
| 180 | </td> |
| 181 | </tr> |
| 182 | |
| 183 | <tr id="n"> |
| 184 | <th>n</th> |
| 185 | <th>NewTkt</th> |
| 186 | <td> |
| 187 | File new tickets. Mnemonic: <b>n</b>ew ticket. |
| 188 | </td> |
| 189 | </tr> |
| 190 | |
| 191 | <tr id="o"> |
| 192 | <th>o</th> |
| 193 | <th>Read</th> |
| 194 | <td> |
| 195 | Read repository content from a remote Fossil instance over |
| 196 | HTTP. See <a href="index.md#read-v-clone">Reading vs. |
| 197 | Cloning</a>. Mnemonic: check <b>o</b>ut remote repo contents. |
| 198 | </td> |
| 199 | </tr> |
| 200 | |
| 201 | <tr id="p"> |
| 202 | <th>p</th> |
| 203 | <th>Password</th> |
| 204 | <td> |
| 205 | Change one’s own password. Mnemonic: <b>p</b>assword. |
| 206 | </td> |
| 207 | </tr> |
| 208 | |
| 209 | <tr id="q"> |
| 210 | <th>q</th> |
| 211 | <th>ModTkt</th> |
| 212 | <td> |
| 213 | Moderate tickets: delete comments appended to tickets. Mnemonic: |
| 214 | <b>q</b>uash noise commentary. |
| 215 | </td> |
| 216 | </tr> |
| 217 | |
| 218 | <tr id="r"> |
| 219 | <th>r</th> |
| 220 | <th>RdTkt</th> |
| 221 | <td> |
| 222 | View existing tickets. Mnemonic: <b>r</b>ead tickets. |
| 223 | </td> |
| 224 | </tr> |
| 225 | |
| 226 | <tr id="s"> |
| 227 | <th>s</th> |
| 228 | <th>Setup</th> |
| 229 | <td> |
| @@ -235,71 +235,71 @@ | |
| 235 | <tr id="t"> |
| 236 | <th>t</th> |
| 237 | <th>TktFmt</th> |
| 238 | <td> |
| 239 | Create new ticket report formats. Note that although this allows |
| 240 | the user to provide SQL code to be run in the server’s context, |
| 241 | and this capability is given to the untrusted “anonymous� user |
| 242 | category by default, this is a safe capability to give to users |
| 243 | because it is internally restricted to read-only queries on the |
| 244 | tickets table only. (This restriction is done with a SQLite |
| 245 | authorization hook, not by any method so weak as SQL text |
| 246 | filtering.) Mnemonic: new <b>t</b>icket report. |
| 247 | </td> |
| 248 | </tr> |
| 249 | |
| 250 | <tr id="u"> |
| 251 | <th>u</th> |
| 252 | <th>n/a</th> |
| 253 | <td> |
| 254 | Inherit all capabilities of the “reader� user category; does not |
| 255 | have a dedicated flag internally within Fossil. Mnemonic: |
| 256 | <a href="./index.md#ucat"><b>u</b>ser</a> |
| 257 | </td> |
| 258 | </tr> |
| 259 | |
| 260 | <tr id="v"> |
| 261 | <th>v</th> |
| 262 | <th>n/a</th> |
| 263 | <td> |
| 264 | Inherit all capabilities of the “developer� user category; does |
| 265 | not have a dedicated flag internally within Fossil. Mnemonic: |
| 266 | de<b>v</b>eloper. |
| 267 | </td> |
| 268 | </tr> |
| 269 | |
| 270 | <tr id="w"> |
| 271 | <th>w</th> |
| 272 | <th>WrTkt</th> |
| 273 | <td> |
| 274 | Edit existing tickets. Granting this capability also grants <a |
| 275 | href="#r"><b>RdTkt</b></a>, <a href="#c"><b>ApndTkt</b></a>, and |
| 276 | <a href="#n"><b>NewTkt</b></a>. Mnemonic: <b>w</b>rite to ticket. |
| 277 | </td> |
| 278 | </tr> |
| 279 | |
| 280 | <tr id="x"> |
| 281 | <th>x</th> |
| 282 | <th>Private</th> |
| 283 | <td> |
| 284 | Push or pull <a href="../private.wiki">private branches</a>. |
| 285 | Mnemonic: e<b>x</b>clusivity; “x� connotes unknown material in |
| 286 | many Western languages due to its <a |
| 287 | href="https://en.wikipedia.org/wiki/La_Géométrie#The_text">traditional |
| 288 | use in mathematics</a>. |
| 289 | </td> |
| 290 | </tr> |
| 291 | |
| 292 | <tr id="y"> |
| 293 | <th>y</th> |
| 294 | <th>WrUnver</th> |
| 295 | <td> |
| 296 | Push <a href="../unvers.wiki">unversioned content</a>. Mnemonic: |
| 297 | <b>y</b>ield, <a href="https://en.wiktionary.org/wiki/yield">sense |
| 298 | 4</a>: “hand over.� |
| 299 | </td> |
| 300 | </tr> |
| 301 | |
| 302 | <tr id="z"> |
| 303 | <th>z</th> |
| 304 | <th>Zip</th> |
| 305 | <td> |
| @@ -310,103 +310,103 @@ | |
| 310 | expensive capability to grant, because creating such archives can |
| 311 | put a large load on <a href="../server/">a Fossil server</a> which |
| 312 | you may then need to <a href="../loadmgmt.md">manage</a>. |
| 313 | Mnemonic: <b>z</b>ip file download. |
| 314 | </td> |
| 315 | </tr> |
| 316 | |
| 317 | <tr id="2"> |
| 318 | <th>2</th> |
| 319 | <th>RdForum</th> |
| 320 | <td> |
| 321 | Read <a href="../forum.wiki">forum posts</a> by other users. |
| 322 | Mnemonic: from thee <b>2</b> me. |
| 323 | </td> |
| 324 | </tr> |
| 325 | |
| 326 | <tr id="3"> |
| 327 | <th>3</th> |
| 328 | <th>WrForum</th> |
| 329 | <td> |
| 330 | Create new forum threads, reply to threads created by others, and |
| 331 | edit one’s own posts. New posts are <a |
| 332 | href="../forum.wiki#moderation">held for moderation</a> and do |
| 333 | not appear in repo clones or syncs. Granting this capability also |
| 334 | grants <a href="#2"><b>RdForum</b></a>. Mnemonic: post for |
| 335 | <b>3</b> audiences: me, <a href="#5">the mods</a>, and <a |
| 336 | href="https://en.wikipedia.org/wiki/The_Man">the Man</a>. |
| 337 | </td> |
| 338 | </tr> |
| 339 | |
| 340 | <tr id="4"> |
| 341 | <th>4</th> |
| 342 | <th>WrTForum</th> |
| 343 | <td> |
| 344 | Extends <a href="#3"><b>WrForum</b></a>, bypassing the moderation |
| 345 | and sync restrictions. Mnemonic: post <b>4</b> immediate release. |
| 346 | </td> |
| 347 | </tr> |
| 348 | |
| 349 | <tr id="5"> |
| 350 | <th>5</th> |
| 351 | <th>ModForum</th> |
| 352 | <td> |
| 353 | <a href="../forum.wiki#moderation">Moderate forum posts</a>. |
| 354 | Granting this capability also grants <a |
| 355 | href="#4"><b>WrTForum</b></a> and <a href="#2"><b>RdForum</b></a>, |
| 356 | so a user with this cap never has to moderate their own posts. |
| 357 | Mnemonic: “May I have <b>5</b> seconds of your time, honored |
| 358 | Gatekeeper?� |
| 359 | </td> |
| 360 | </tr> |
| 361 | |
| 362 | <tr id="6"> |
| 363 | <th>6</th> |
| 364 | <th>AdminForum</th> |
| 365 | <td> |
| 366 | Users with this capability see a checkbox on unmoderated forum |
| 367 | posts labeled “Trust user X so that future posts by user X do not |
| 368 | require moderation.� Checking that box and then clicking the |
| 369 | moderator-only “Approve� button on that post grants <a |
| 370 | href="#4"><b>WrTForum</b></a> capability to that post’s author. |
| 371 | There is currently no UI for a user with this cap to |
| 372 | <em>revoke</em> trust from a user once it is granted; only <a |
| 373 | href="#a"><b>Admin</b></a> and <a href="#s"><b>Setup</b></a> can |
| 374 | currently revoke granted caps. Granting this capability also |
| 375 | grants <a href="#5"><b>ModForum</b></a> and those it in turn |
| 376 | grants. Mnemonic: “I’m <b>6</b> [sick] of hitting Approve on your |
| 377 | posts!� |
| 378 | </td> |
| 379 | </tr> |
| 380 | |
| 381 | <tr id="7"> |
| 382 | <th>7</th> |
| 383 | <th>EmailAlert</th> |
| 384 | <td> |
| 385 | User can sign up for <a href="../alerts.md">email alerts</a>. |
| 386 | Mnemonic: <a href="https://en.wikipedia.org/wiki/Heaven_Can_Wait">Seven can |
| 387 | wait</a>, I’ve got email to read now. |
| 388 | </td> |
| 389 | </tr> |
| 390 | |
| 391 | <tr id="A"> |
| 392 | <th>A</th> |
| 393 | <th>Announce</th> |
| 394 | <td> |
| 395 | Send email announcements to users <a href="#7">signed up to |
| 396 | receive them</a>. Mnemonic: <b>a</b>nnounce. |
| 397 | </td> |
| 398 | </tr> |
| 399 | |
| 400 | <tr id="D"> |
| 401 | <th>D</th> |
| 402 | <th>Debug</th> |
| 403 | <td> |
| 404 | Enable debugging features. Mnemonic: <b>d</b>ebug. |
| 405 | </td> |
| 406 | </tr> |
| 407 | </table> |
| 408 | |
| 409 | <hr/> |
| 410 | |
| 411 | <p id="backlink"><a href="./"><em>Back to Administering User |
| 412 | Capabilities</em></a></p> |
| 413 |
+1
-1
| --- www/checkin_names.wiki | ||
| +++ www/checkin_names.wiki | ||
| @@ -156,11 +156,11 @@ | ||
| 156 | 156 | the space between the day and the year can optionally be |
| 157 | 157 | replaced by an uppercase <b>T</b> and the entire timestamp can |
| 158 | 158 | optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth |
| 159 | 159 | form with fractional seconds, any number of digits may follow the |
| 160 | 160 | decimal point, though due to precision limits only the first three |
| 161 | -digits will be significant. The final three pure-digit forms | |
| 161 | +digits will be significant. The final three pure-digit forms | |
| 162 | 162 | without punctuation are only valid if the number they encode is |
| 163 | 163 | not also the prefix of an artifact hash. |
| 164 | 164 | |
| 165 | 165 | In its default configuration, Fossil interprets and displays all dates |
| 166 | 166 | in Universal Coordinated Time (UTC). This tends to work the best for |
| 167 | 167 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -156,11 +156,11 @@ | |
| 156 | the space between the day and the year can optionally be |
| 157 | replaced by an uppercase <b>T</b> and the entire timestamp can |
| 158 | optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth |
| 159 | form with fractional seconds, any number of digits may follow the |
| 160 | decimal point, though due to precision limits only the first three |
| 161 | digits will be significant. The final three pure-digit forms |
| 162 | without punctuation are only valid if the number they encode is |
| 163 | not also the prefix of an artifact hash. |
| 164 | |
| 165 | In its default configuration, Fossil interprets and displays all dates |
| 166 | in Universal Coordinated Time (UTC). This tends to work the best for |
| 167 |
| --- www/checkin_names.wiki | |
| +++ www/checkin_names.wiki | |
| @@ -156,11 +156,11 @@ | |
| 156 | the space between the day and the year can optionally be |
| 157 | replaced by an uppercase <b>T</b> and the entire timestamp can |
| 158 | optionally be followed by "<b>z</b>" or "<b>Z</b>". In the fourth |
| 159 | form with fractional seconds, any number of digits may follow the |
| 160 | decimal point, though due to precision limits only the first three |
| 161 | digits will be significant. The final three pure-digit forms |
| 162 | without punctuation are only valid if the number they encode is |
| 163 | not also the prefix of an artifact hash. |
| 164 | |
| 165 | In its default configuration, Fossil interprets and displays all dates |
| 166 | in Universal Coordinated Time (UTC). This tends to work the best for |
| 167 |
+4
-4
| --- www/customskin.md | ||
| +++ www/customskin.md | ||
| @@ -11,11 +11,11 @@ | ||
| 11 | 11 | suite your tastes, perhaps one of the other built-in skins will work better. |
| 12 | 12 | If nothing else, the built-in skins can serve as examples or baselines that |
| 13 | 13 | you can use to develop your own custom skin. |
| 14 | 14 | |
| 15 | 15 | The sources to these built-ins can |
| 16 | -be found in the Fossil source tree under the skins/ folder. The | |
| 16 | +be found in the Fossil source tree under the skins/ folder. The | |
| 17 | 17 | [skins/](/dir?ci=trunk&name=skins) |
| 18 | 18 | folder contains a separate subfolder for each built-in skin, with each |
| 19 | 19 | subfolders holding at least these five files: |
| 20 | 20 | |
| 21 | 21 | * css.txt |
| @@ -125,11 +125,11 @@ | ||
| 125 | 125 | </body> |
| 126 | 126 | </html> |
| 127 | 127 | |
| 128 | 128 | ## <a name="override"></a>Overriding the HTML Header and Footer |
| 129 | 129 | |
| 130 | -Notice that the `<html>`, `<head>`, and opening `<body>` | |
| 130 | +Notice that the `<html>`, `<head>`, and opening `<body>` | |
| 131 | 131 | elements at the beginning of the document, |
| 132 | 132 | and the closing `</body>` and `</html>` elements at the end are automatically |
| 133 | 133 | generated by Fossil. This is recommended. |
| 134 | 134 | |
| 135 | 135 | However, for maximum design flexibility, Fossil allows those elements to be |
| @@ -186,12 +186,12 @@ | ||
| 186 | 186 | <p>The footer.txt and header.txt files contain the Content Footer |
| 187 | 187 | and Content Header respectively. Of these, the Content Header is |
| 188 | 188 | the most important, as it contains the markup used to generate |
| 189 | 189 | the banner and menu bar for each page. |
| 190 | 190 | |
| 191 | -<p>Both the footer.txt and header.txt file are | |
| 192 | -[processed using TH1](#headfoot) prior to being output as | |
| 191 | +<p>Both the footer.txt and header.txt file are | |
| 192 | +[processed using TH1](#headfoot) prior to being output as | |
| 193 | 193 | part of the overall web page.</dd> |
| 194 | 194 | |
| 195 | 195 | <dt><b>js.txt</b></dt><dd> |
| 196 | 196 | |
| 197 | 197 | <p>The js.txt file is intended to be javascript. The complete |
| 198 | 198 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -11,11 +11,11 @@ | |
| 11 | suite your tastes, perhaps one of the other built-in skins will work better. |
| 12 | If nothing else, the built-in skins can serve as examples or baselines that |
| 13 | you can use to develop your own custom skin. |
| 14 | |
| 15 | The sources to these built-ins can |
| 16 | be found in the Fossil source tree under the skins/ folder. The |
| 17 | [skins/](/dir?ci=trunk&name=skins) |
| 18 | folder contains a separate subfolder for each built-in skin, with each |
| 19 | subfolders holding at least these five files: |
| 20 | |
| 21 | * css.txt |
| @@ -125,11 +125,11 @@ | |
| 125 | </body> |
| 126 | </html> |
| 127 | |
| 128 | ## <a name="override"></a>Overriding the HTML Header and Footer |
| 129 | |
| 130 | Notice that the `<html>`, `<head>`, and opening `<body>` |
| 131 | elements at the beginning of the document, |
| 132 | and the closing `</body>` and `</html>` elements at the end are automatically |
| 133 | generated by Fossil. This is recommended. |
| 134 | |
| 135 | However, for maximum design flexibility, Fossil allows those elements to be |
| @@ -186,12 +186,12 @@ | |
| 186 | <p>The footer.txt and header.txt files contain the Content Footer |
| 187 | and Content Header respectively. Of these, the Content Header is |
| 188 | the most important, as it contains the markup used to generate |
| 189 | the banner and menu bar for each page. |
| 190 | |
| 191 | <p>Both the footer.txt and header.txt file are |
| 192 | [processed using TH1](#headfoot) prior to being output as |
| 193 | part of the overall web page.</dd> |
| 194 | |
| 195 | <dt><b>js.txt</b></dt><dd> |
| 196 | |
| 197 | <p>The js.txt file is intended to be javascript. The complete |
| 198 |
| --- www/customskin.md | |
| +++ www/customskin.md | |
| @@ -11,11 +11,11 @@ | |
| 11 | suite your tastes, perhaps one of the other built-in skins will work better. |
| 12 | If nothing else, the built-in skins can serve as examples or baselines that |
| 13 | you can use to develop your own custom skin. |
| 14 | |
| 15 | The sources to these built-ins can |
| 16 | be found in the Fossil source tree under the skins/ folder. The |
| 17 | [skins/](/dir?ci=trunk&name=skins) |
| 18 | folder contains a separate subfolder for each built-in skin, with each |
| 19 | subfolders holding at least these five files: |
| 20 | |
| 21 | * css.txt |
| @@ -125,11 +125,11 @@ | |
| 125 | </body> |
| 126 | </html> |
| 127 | |
| 128 | ## <a name="override"></a>Overriding the HTML Header and Footer |
| 129 | |
| 130 | Notice that the `<html>`, `<head>`, and opening `<body>` |
| 131 | elements at the beginning of the document, |
| 132 | and the closing `</body>` and `</html>` elements at the end are automatically |
| 133 | generated by Fossil. This is recommended. |
| 134 | |
| 135 | However, for maximum design flexibility, Fossil allows those elements to be |
| @@ -186,12 +186,12 @@ | |
| 186 | <p>The footer.txt and header.txt files contain the Content Footer |
| 187 | and Content Header respectively. Of these, the Content Header is |
| 188 | the most important, as it contains the markup used to generate |
| 189 | the banner and menu bar for each page. |
| 190 | |
| 191 | <p>Both the footer.txt and header.txt file are |
| 192 | [processed using TH1](#headfoot) prior to being output as |
| 193 | part of the overall web page.</dd> |
| 194 | |
| 195 | <dt><b>js.txt</b></dt><dd> |
| 196 | |
| 197 | <p>The js.txt file is intended to be javascript. The complete |
| 198 |
+1
-1
| --- www/delta_format.wiki | ||
| +++ www/delta_format.wiki | ||
| @@ -11,11 +11,11 @@ | ||
| 11 | 11 | The intended audience is developers working on either |
| 12 | 12 | <a href="index.wiki">Fossil</a> itself, or on tools compatible with |
| 13 | 13 | Fossil. Understanding of this document is <em>not</em> required for |
| 14 | 14 | ordinary users of Fossil. This document is an implementation detail.</p> |
| 15 | 15 | |
| 16 | -<p>This document only describes the delta file format. A | |
| 16 | +<p>This document only describes the delta file format. A | |
| 17 | 17 | [./delta_encoder_algorithm.wiki|separate document] describes one possible |
| 18 | 18 | algorithm for generating deltas in this format.</p> |
| 19 | 19 | |
| 20 | 20 | <h2>1.1 Sample Software And Analysis Tools</h2> |
| 21 | 21 | |
| 22 | 22 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -11,11 +11,11 @@ | |
| 11 | The intended audience is developers working on either |
| 12 | <a href="index.wiki">Fossil</a> itself, or on tools compatible with |
| 13 | Fossil. Understanding of this document is <em>not</em> required for |
| 14 | ordinary users of Fossil. This document is an implementation detail.</p> |
| 15 | |
| 16 | <p>This document only describes the delta file format. A |
| 17 | [./delta_encoder_algorithm.wiki|separate document] describes one possible |
| 18 | algorithm for generating deltas in this format.</p> |
| 19 | |
| 20 | <h2>1.1 Sample Software And Analysis Tools</h2> |
| 21 | |
| 22 |
| --- www/delta_format.wiki | |
| +++ www/delta_format.wiki | |
| @@ -11,11 +11,11 @@ | |
| 11 | The intended audience is developers working on either |
| 12 | <a href="index.wiki">Fossil</a> itself, or on tools compatible with |
| 13 | Fossil. Understanding of this document is <em>not</em> required for |
| 14 | ordinary users of Fossil. This document is an implementation detail.</p> |
| 15 | |
| 16 | <p>This document only describes the delta file format. A |
| 17 | [./delta_encoder_algorithm.wiki|separate document] describes one possible |
| 18 | algorithm for generating deltas in this format.</p> |
| 19 | |
| 20 | <h2>1.1 Sample Software And Analysis Tools</h2> |
| 21 | |
| 22 |
+3
-3
| --- www/embeddeddoc.wiki | ||
| +++ www/embeddeddoc.wiki | ||
| @@ -50,11 +50,11 @@ | ||
| 50 | 50 | for more possibilities and examples. The <i><version></i> can |
| 51 | 51 | also be the special identifier "<b>ckout</b>". |
| 52 | 52 | The "<b>ckout</b>" keywords means to |
| 53 | 53 | pull the documentation file from the local source tree on disk, not |
| 54 | 54 | from the any check-in. The "<b>ckout</b>" keyword |
| 55 | -only works when you start your server using the | |
| 55 | +only works when you start your server using the | |
| 56 | 56 | "[/help?cmd=server|fossil server]" or "[/help?cmd=ui|fossil ui]" |
| 57 | 57 | commands. The "/doc/ckout" URL is intended to show a preview of |
| 58 | 58 | the documentation you are currently but have not yet you checked in. |
| 59 | 59 | |
| 60 | 60 | Finally, the <i><filename></i> element of the URL is the |
| @@ -112,11 +112,11 @@ | ||
| 112 | 112 | Fossil can do a few types of substitution of server-side information |
| 113 | 113 | into the embedded document. |
| 114 | 114 | |
| 115 | 115 | <h2>2.1 "$ROOT" In HTML and Markdown Hyperlinks</h2> |
| 116 | 116 | |
| 117 | -Hyperlinks in Markdown and HTML embedded documents can reference | |
| 117 | +Hyperlinks in Markdown and HTML embedded documents can reference | |
| 118 | 118 | the root of the Fossil repository using the special text "$ROOT" |
| 119 | 119 | at the beginning of a URL. For example, a Markdown hyperlink to |
| 120 | 120 | the Markdown formatting rules might be |
| 121 | 121 | written in the embedded document like this: |
| 122 | 122 | |
| @@ -164,11 +164,11 @@ | ||
| 164 | 164 | <tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have |
| 165 | 165 | configured it with the <tt>--with-th1-docs</tt> option, which is |
| 166 | 166 | disabled by default. |
| 167 | 167 | |
| 168 | 168 | Since TH1 is a full scripting language, this feature essential grants |
| 169 | -the ability to execute code on the server to any with check-in | |
| 169 | +the ability to execute code on the server to any with check-in | |
| 170 | 170 | privilege for the project. |
| 171 | 171 | This is a security risk that needs to be carefully managed. |
| 172 | 172 | The feature is off by default. |
| 173 | 173 | Administrators should understand and carefully assess the risks |
| 174 | 174 | before enabling the use of TH1 within embedded documentation. |
| 175 | 175 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -50,11 +50,11 @@ | |
| 50 | for more possibilities and examples. The <i><version></i> can |
| 51 | also be the special identifier "<b>ckout</b>". |
| 52 | The "<b>ckout</b>" keywords means to |
| 53 | pull the documentation file from the local source tree on disk, not |
| 54 | from the any check-in. The "<b>ckout</b>" keyword |
| 55 | only works when you start your server using the |
| 56 | "[/help?cmd=server|fossil server]" or "[/help?cmd=ui|fossil ui]" |
| 57 | commands. The "/doc/ckout" URL is intended to show a preview of |
| 58 | the documentation you are currently but have not yet you checked in. |
| 59 | |
| 60 | Finally, the <i><filename></i> element of the URL is the |
| @@ -112,11 +112,11 @@ | |
| 112 | Fossil can do a few types of substitution of server-side information |
| 113 | into the embedded document. |
| 114 | |
| 115 | <h2>2.1 "$ROOT" In HTML and Markdown Hyperlinks</h2> |
| 116 | |
| 117 | Hyperlinks in Markdown and HTML embedded documents can reference |
| 118 | the root of the Fossil repository using the special text "$ROOT" |
| 119 | at the beginning of a URL. For example, a Markdown hyperlink to |
| 120 | the Markdown formatting rules might be |
| 121 | written in the embedded document like this: |
| 122 | |
| @@ -164,11 +164,11 @@ | |
| 164 | <tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have |
| 165 | configured it with the <tt>--with-th1-docs</tt> option, which is |
| 166 | disabled by default. |
| 167 | |
| 168 | Since TH1 is a full scripting language, this feature essential grants |
| 169 | the ability to execute code on the server to any with check-in |
| 170 | privilege for the project. |
| 171 | This is a security risk that needs to be carefully managed. |
| 172 | The feature is off by default. |
| 173 | Administrators should understand and carefully assess the risks |
| 174 | before enabling the use of TH1 within embedded documentation. |
| 175 |
| --- www/embeddeddoc.wiki | |
| +++ www/embeddeddoc.wiki | |
| @@ -50,11 +50,11 @@ | |
| 50 | for more possibilities and examples. The <i><version></i> can |
| 51 | also be the special identifier "<b>ckout</b>". |
| 52 | The "<b>ckout</b>" keywords means to |
| 53 | pull the documentation file from the local source tree on disk, not |
| 54 | from the any check-in. The "<b>ckout</b>" keyword |
| 55 | only works when you start your server using the |
| 56 | "[/help?cmd=server|fossil server]" or "[/help?cmd=ui|fossil ui]" |
| 57 | commands. The "/doc/ckout" URL is intended to show a preview of |
| 58 | the documentation you are currently but have not yet you checked in. |
| 59 | |
| 60 | Finally, the <i><filename></i> element of the URL is the |
| @@ -112,11 +112,11 @@ | |
| 112 | Fossil can do a few types of substitution of server-side information |
| 113 | into the embedded document. |
| 114 | |
| 115 | <h2>2.1 "$ROOT" In HTML and Markdown Hyperlinks</h2> |
| 116 | |
| 117 | Hyperlinks in Markdown and HTML embedded documents can reference |
| 118 | the root of the Fossil repository using the special text "$ROOT" |
| 119 | at the beginning of a URL. For example, a Markdown hyperlink to |
| 120 | the Markdown formatting rules might be |
| 121 | written in the embedded document like this: |
| 122 | |
| @@ -164,11 +164,11 @@ | |
| 164 | <tt>{</tt> curly braces <tt>}</tt> into the output HTML if you have |
| 165 | configured it with the <tt>--with-th1-docs</tt> option, which is |
| 166 | disabled by default. |
| 167 | |
| 168 | Since TH1 is a full scripting language, this feature essential grants |
| 169 | the ability to execute code on the server to any with check-in |
| 170 | privilege for the project. |
| 171 | This is a security risk that needs to be carefully managed. |
| 172 | The feature is off by default. |
| 173 | Administrators should understand and carefully assess the risks |
| 174 | before enabling the use of TH1 within embedded documentation. |
| 175 |
+1
-1
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -371,11 +371,11 @@ | ||
| 371 | 371 | extra newline. |
| 372 | 372 | |
| 373 | 373 | The <b>C</b> card on a wiki page is optional. The argument is a comment |
| 374 | 374 | that explains why the changes was made. The ability to have a <b>C</b> |
| 375 | 375 | card on a wiki page artifact was added on 2019-12-02 at the suggestion |
| 376 | -of user George Krivov and is not currently used or generated by the | |
| 376 | +of user George Krivov and is not currently used or generated by the | |
| 377 | 377 | implementation. Older versions of Fossil will reject a wiki-page |
| 378 | 378 | artifact that includes a <b>C</b> card. |
| 379 | 379 | |
| 380 | 380 | An example wiki artifact can be seen |
| 381 | 381 | [/artifact?name=7b2f5fd0e0&txt=1 | here]. |
| 382 | 382 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -371,11 +371,11 @@ | |
| 371 | extra newline. |
| 372 | |
| 373 | The <b>C</b> card on a wiki page is optional. The argument is a comment |
| 374 | that explains why the changes was made. The ability to have a <b>C</b> |
| 375 | card on a wiki page artifact was added on 2019-12-02 at the suggestion |
| 376 | of user George Krivov and is not currently used or generated by the |
| 377 | implementation. Older versions of Fossil will reject a wiki-page |
| 378 | artifact that includes a <b>C</b> card. |
| 379 | |
| 380 | An example wiki artifact can be seen |
| 381 | [/artifact?name=7b2f5fd0e0&txt=1 | here]. |
| 382 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -371,11 +371,11 @@ | |
| 371 | extra newline. |
| 372 | |
| 373 | The <b>C</b> card on a wiki page is optional. The argument is a comment |
| 374 | that explains why the changes was made. The ability to have a <b>C</b> |
| 375 | card on a wiki page artifact was added on 2019-12-02 at the suggestion |
| 376 | of user George Krivov and is not currently used or generated by the |
| 377 | implementation. Older versions of Fossil will reject a wiki-page |
| 378 | artifact that includes a <b>C</b> card. |
| 379 | |
| 380 | An example wiki artifact can be seen |
| 381 | [/artifact?name=7b2f5fd0e0&txt=1 | here]. |
| 382 |
+4
-4
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -101,11 +101,11 @@ | ||
| 101 | 101 | <h3 id="features">2.1 Featureful</h3> |
| 102 | 102 | |
| 103 | 103 | Git provides file versioning services only, whereas Fossil adds |
| 104 | 104 | an integrated [./wikitheory.wiki | wiki], |
| 105 | 105 | [./bugtheory.wiki | ticketing & bug tracking], |
| 106 | -[./embeddeddoc.wiki | embedded documentation], | |
| 106 | +[./embeddeddoc.wiki | embedded documentation], | |
| 107 | 107 | [./event.wiki | technical notes], and a [./forum.wiki | web forum], |
| 108 | 108 | all within a single nicely-designed [./customskin.md|skinnable] web |
| 109 | 109 | [/help?cmd=ui|UI], |
| 110 | 110 | protected by [./caps/ | a fine-grained role-based |
| 111 | 111 | access control system]. |
| @@ -619,11 +619,11 @@ | ||
| 619 | 619 | such as Linux. Linus Torvalds does not want to see every check-in |
| 620 | 620 | by every contributor to Linux, as such extreme visibility does not scale |
| 621 | 621 | well. But Fossil was written for the cathedral-style SQLite project |
| 622 | 622 | with just a handful of active committers. Seeing all |
| 623 | 623 | changes on all branches all at once helps keep the whole team |
| 624 | -up-to-date with what everybody else is doing, resulting in a more | |
| 624 | +up-to-date with what everybody else is doing, resulting in a more | |
| 625 | 625 | tightly focused and cohesive implementation. |
| 626 | 626 | |
| 627 | 627 | |
| 628 | 628 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 629 | 629 | |
| @@ -778,12 +778,12 @@ | ||
| 778 | 778 | |
| 779 | 779 | Incidentally, this is a good example of Git's messy command design. |
| 780 | 780 | These three commands: |
| 781 | 781 | |
| 782 | 782 | <pre> |
| 783 | - $ git merge HASH | |
| 784 | - $ git cherry-pick HASH | |
| 783 | + $ git merge HASH | |
| 784 | + $ git cherry-pick HASH | |
| 785 | 785 | $ git revert HASH |
| 786 | 786 | </pre> |
| 787 | 787 | |
| 788 | 788 | ...are all the same command in Fossil: |
| 789 | 789 | |
| 790 | 790 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -101,11 +101,11 @@ | |
| 101 | <h3 id="features">2.1 Featureful</h3> |
| 102 | |
| 103 | Git provides file versioning services only, whereas Fossil adds |
| 104 | an integrated [./wikitheory.wiki | wiki], |
| 105 | [./bugtheory.wiki | ticketing & bug tracking], |
| 106 | [./embeddeddoc.wiki | embedded documentation], |
| 107 | [./event.wiki | technical notes], and a [./forum.wiki | web forum], |
| 108 | all within a single nicely-designed [./customskin.md|skinnable] web |
| 109 | [/help?cmd=ui|UI], |
| 110 | protected by [./caps/ | a fine-grained role-based |
| 111 | access control system]. |
| @@ -619,11 +619,11 @@ | |
| 619 | such as Linux. Linus Torvalds does not want to see every check-in |
| 620 | by every contributor to Linux, as such extreme visibility does not scale |
| 621 | well. But Fossil was written for the cathedral-style SQLite project |
| 622 | with just a handful of active committers. Seeing all |
| 623 | changes on all branches all at once helps keep the whole team |
| 624 | up-to-date with what everybody else is doing, resulting in a more |
| 625 | tightly focused and cohesive implementation. |
| 626 | |
| 627 | |
| 628 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 629 | |
| @@ -778,12 +778,12 @@ | |
| 778 | |
| 779 | Incidentally, this is a good example of Git's messy command design. |
| 780 | These three commands: |
| 781 | |
| 782 | <pre> |
| 783 | $ git merge HASH |
| 784 | $ git cherry-pick HASH |
| 785 | $ git revert HASH |
| 786 | </pre> |
| 787 | |
| 788 | ...are all the same command in Fossil: |
| 789 | |
| 790 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -101,11 +101,11 @@ | |
| 101 | <h3 id="features">2.1 Featureful</h3> |
| 102 | |
| 103 | Git provides file versioning services only, whereas Fossil adds |
| 104 | an integrated [./wikitheory.wiki | wiki], |
| 105 | [./bugtheory.wiki | ticketing & bug tracking], |
| 106 | [./embeddeddoc.wiki | embedded documentation], |
| 107 | [./event.wiki | technical notes], and a [./forum.wiki | web forum], |
| 108 | all within a single nicely-designed [./customskin.md|skinnable] web |
| 109 | [/help?cmd=ui|UI], |
| 110 | protected by [./caps/ | a fine-grained role-based |
| 111 | access control system]. |
| @@ -619,11 +619,11 @@ | |
| 619 | such as Linux. Linus Torvalds does not want to see every check-in |
| 620 | by every contributor to Linux, as such extreme visibility does not scale |
| 621 | well. But Fossil was written for the cathedral-style SQLite project |
| 622 | with just a handful of active committers. Seeing all |
| 623 | changes on all branches all at once helps keep the whole team |
| 624 | up-to-date with what everybody else is doing, resulting in a more |
| 625 | tightly focused and cohesive implementation. |
| 626 | |
| 627 | |
| 628 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 629 | |
| @@ -778,12 +778,12 @@ | |
| 778 | |
| 779 | Incidentally, this is a good example of Git's messy command design. |
| 780 | These three commands: |
| 781 | |
| 782 | <pre> |
| 783 | $ git merge HASH |
| 784 | $ git cherry-pick HASH |
| 785 | $ git revert HASH |
| 786 | </pre> |
| 787 | |
| 788 | ...are all the same command in Fossil: |
| 789 | |
| 790 |
+3
-3
| --- www/hashpolicy.wiki | ||
| +++ www/hashpolicy.wiki | ||
| @@ -191,9 +191,9 @@ | ||
| 191 | 191 | upgrade to the latest version of Fossil, all of your new artifacts will |
| 192 | 192 | use a SHA3 hash. Legacy SHA1 artifacts continue to use their original |
| 193 | 193 | names, but new artifacts will use SHA3 names. You might not even notice |
| 194 | 194 | this automatic change over to stronger hashes. |
| 195 | 195 | |
| 196 | -We decided to make the change to pure SHA3 since the last known distributor | |
| 197 | -of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019 | |
| 198 | -by Debian 10, which included Fossil 2.8. All other known sources of | |
| 196 | +We decided to make the change to pure SHA3 since the last known distributor | |
| 197 | +of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019 | |
| 198 | +by Debian 10, which included Fossil 2.8. All other known sources of | |
| 199 | 199 | Fossil 1.x binaries upgraded well before that point. |
| 200 | 200 |
| --- www/hashpolicy.wiki | |
| +++ www/hashpolicy.wiki | |
| @@ -191,9 +191,9 @@ | |
| 191 | upgrade to the latest version of Fossil, all of your new artifacts will |
| 192 | use a SHA3 hash. Legacy SHA1 artifacts continue to use their original |
| 193 | names, but new artifacts will use SHA3 names. You might not even notice |
| 194 | this automatic change over to stronger hashes. |
| 195 | |
| 196 | We decided to make the change to pure SHA3 since the last known distributor |
| 197 | of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019 |
| 198 | by Debian 10, which included Fossil 2.8. All other known sources of |
| 199 | Fossil 1.x binaries upgraded well before that point. |
| 200 |
| --- www/hashpolicy.wiki | |
| +++ www/hashpolicy.wiki | |
| @@ -191,9 +191,9 @@ | |
| 191 | upgrade to the latest version of Fossil, all of your new artifacts will |
| 192 | use a SHA3 hash. Legacy SHA1 artifacts continue to use their original |
| 193 | names, but new artifacts will use SHA3 names. You might not even notice |
| 194 | this automatic change over to stronger hashes. |
| 195 | |
| 196 | We decided to make the change to pure SHA3 since the last known distributor |
| 197 | of Fossil 1.x binaries — Debian 9 — was finally replaced in June 2019 |
| 198 | by Debian 10, which included Fossil 2.8. All other known sources of |
| 199 | Fossil 1.x binaries upgraded well before that point. |
| 200 |
+2
-2
| --- www/image-format-vs-repo-size.md | ||
| +++ www/image-format-vs-repo-size.md | ||
| @@ -11,12 +11,12 @@ | ||
| 11 | 11 | Storing pre-compressed data files in a Fossil repository defeats both of |
| 12 | 12 | these space-saving measures: |
| 13 | 13 | |
| 14 | 14 | 1. Binary data compression algorithms — whether lossless as with zlib |
| 15 | 15 | or lossy as with JPEG — turn the file data into [pseudorandom |
| 16 | - noise][prn].² | |
| 17 | - | |
| 16 | + noise][prn].² | |
| 17 | + | |
| 18 | 18 | Typical data compression algorithms are not [hash functions][hf], |
| 19 | 19 | where the goal is that a change to each bit in the input has a |
| 20 | 20 | statistically even chance of changing every bit in the output, but |
| 21 | 21 | because they do approach that pathological condition, pre-compressed |
| 22 | 22 | data tends to defeat Fossil’s delta compression algorithm, there |
| 23 | 23 |
| --- www/image-format-vs-repo-size.md | |
| +++ www/image-format-vs-repo-size.md | |
| @@ -11,12 +11,12 @@ | |
| 11 | Storing pre-compressed data files in a Fossil repository defeats both of |
| 12 | these space-saving measures: |
| 13 | |
| 14 | 1. Binary data compression algorithms — whether lossless as with zlib |
| 15 | or lossy as with JPEG — turn the file data into [pseudorandom |
| 16 | noise][prn].² |
| 17 | |
| 18 | Typical data compression algorithms are not [hash functions][hf], |
| 19 | where the goal is that a change to each bit in the input has a |
| 20 | statistically even chance of changing every bit in the output, but |
| 21 | because they do approach that pathological condition, pre-compressed |
| 22 | data tends to defeat Fossil’s delta compression algorithm, there |
| 23 |
| --- www/image-format-vs-repo-size.md | |
| +++ www/image-format-vs-repo-size.md | |
| @@ -11,12 +11,12 @@ | |
| 11 | Storing pre-compressed data files in a Fossil repository defeats both of |
| 12 | these space-saving measures: |
| 13 | |
| 14 | 1. Binary data compression algorithms — whether lossless as with zlib |
| 15 | or lossy as with JPEG — turn the file data into [pseudorandom |
| 16 | noise][prn].² |
| 17 | |
| 18 | Typical data compression algorithms are not [hash functions][hf], |
| 19 | where the goal is that a change to each bit in the input has a |
| 20 | statistically even chance of changing every bit in the output, but |
| 21 | because they do approach that pathological condition, pre-compressed |
| 22 | data tends to defeat Fossil’s delta compression algorithm, there |
| 23 |
+1
-1
| --- www/mdtest/test1.md | ||
| +++ www/mdtest/test1.md | ||
| @@ -14,11 +14,11 @@ | ||
| 14 | 14 | * Windows CGI: [](../server/windows/cgi.md) |
| 15 | 15 | |
| 16 | 16 | ## The Magic $ROOT Path Prefix |
| 17 | 17 | |
| 18 | 18 | In text of the form `href="$ROOT/..."` in the HTML that markdown |
| 19 | -generates, the $ROOT is replaced by the complete URI for the root | |
| 19 | +generates, the $ROOT is replaced by the complete URI for the root | |
| 20 | 20 | of the document tree. |
| 21 | 21 | Note that the $ROOT translation only occurs within the `<a href="...">` |
| 22 | 22 | element, not within the text of the hyperlink. So you should see the |
| 23 | 23 | $ROOT text on this page, but if you mouse-over the hyperlink the $ROOT |
| 24 | 24 | value should have been expanded to the actual document root. |
| 25 | 25 |
| --- www/mdtest/test1.md | |
| +++ www/mdtest/test1.md | |
| @@ -14,11 +14,11 @@ | |
| 14 | * Windows CGI: [](../server/windows/cgi.md) |
| 15 | |
| 16 | ## The Magic $ROOT Path Prefix |
| 17 | |
| 18 | In text of the form `href="$ROOT/..."` in the HTML that markdown |
| 19 | generates, the $ROOT is replaced by the complete URI for the root |
| 20 | of the document tree. |
| 21 | Note that the $ROOT translation only occurs within the `<a href="...">` |
| 22 | element, not within the text of the hyperlink. So you should see the |
| 23 | $ROOT text on this page, but if you mouse-over the hyperlink the $ROOT |
| 24 | value should have been expanded to the actual document root. |
| 25 |
| --- www/mdtest/test1.md | |
| +++ www/mdtest/test1.md | |
| @@ -14,11 +14,11 @@ | |
| 14 | * Windows CGI: [](../server/windows/cgi.md) |
| 15 | |
| 16 | ## The Magic $ROOT Path Prefix |
| 17 | |
| 18 | In text of the form `href="$ROOT/..."` in the HTML that markdown |
| 19 | generates, the $ROOT is replaced by the complete URI for the root |
| 20 | of the document tree. |
| 21 | Note that the $ROOT translation only occurs within the `<a href="...">` |
| 22 | element, not within the text of the hyperlink. So you should see the |
| 23 | $ROOT text on this page, but if you mouse-over the hyperlink the $ROOT |
| 24 | value should have been expanded to the actual document root. |
| 25 |
+2
-2
| --- www/mirrorlimitations.md | ||
| +++ www/mirrorlimitations.md | ||
| @@ -30,11 +30,11 @@ | ||
| 30 | 30 | Git has only limited support for named branches. Git identifies the head |
| 31 | 31 | check-in of each branch. Depending on the check-in graph topology, this |
| 32 | 32 | is sufficient to infer the branch for many historical check-ins as well. |
| 33 | 33 | However, complex histories with lots of cross-merging |
| 34 | 34 | can lead to ambiguities. Fossil keeps |
| 35 | -track of historical branch names unambiguously. | |
| 35 | +track of historical branch names unambiguously. | |
| 36 | 36 | But the extra details about branch names that Fossil keeps |
| 37 | 37 | at hand cannot be exported to Git. |
| 38 | 38 | |
| 39 | 39 | ## (4) Non-unique Tags |
| 40 | 40 | |
| @@ -44,11 +44,11 @@ | ||
| 44 | 44 | it is common in Fossil to tag every release check-in with the "release" |
| 45 | 45 | tag, so that all historical releases can be found all at once. |
| 46 | 46 | ([example](/timeline?t=release)) |
| 47 | 47 | |
| 48 | 48 | Git does not allow this. The "release" tag must refer to just one |
| 49 | -check-in. The work-around is that the non-unique tag in the Git export is | |
| 49 | +check-in. The work-around is that the non-unique tag in the Git export is | |
| 50 | 50 | made to refer to only the most recent check-in with that tag. |
| 51 | 51 | |
| 52 | 52 | ## (5) Amendments To Check-ins |
| 53 | 53 | |
| 54 | 54 | Check-ins are immutable in both Fossil and Git. |
| 55 | 55 |
| --- www/mirrorlimitations.md | |
| +++ www/mirrorlimitations.md | |
| @@ -30,11 +30,11 @@ | |
| 30 | Git has only limited support for named branches. Git identifies the head |
| 31 | check-in of each branch. Depending on the check-in graph topology, this |
| 32 | is sufficient to infer the branch for many historical check-ins as well. |
| 33 | However, complex histories with lots of cross-merging |
| 34 | can lead to ambiguities. Fossil keeps |
| 35 | track of historical branch names unambiguously. |
| 36 | But the extra details about branch names that Fossil keeps |
| 37 | at hand cannot be exported to Git. |
| 38 | |
| 39 | ## (4) Non-unique Tags |
| 40 | |
| @@ -44,11 +44,11 @@ | |
| 44 | it is common in Fossil to tag every release check-in with the "release" |
| 45 | tag, so that all historical releases can be found all at once. |
| 46 | ([example](/timeline?t=release)) |
| 47 | |
| 48 | Git does not allow this. The "release" tag must refer to just one |
| 49 | check-in. The work-around is that the non-unique tag in the Git export is |
| 50 | made to refer to only the most recent check-in with that tag. |
| 51 | |
| 52 | ## (5) Amendments To Check-ins |
| 53 | |
| 54 | Check-ins are immutable in both Fossil and Git. |
| 55 |
| --- www/mirrorlimitations.md | |
| +++ www/mirrorlimitations.md | |
| @@ -30,11 +30,11 @@ | |
| 30 | Git has only limited support for named branches. Git identifies the head |
| 31 | check-in of each branch. Depending on the check-in graph topology, this |
| 32 | is sufficient to infer the branch for many historical check-ins as well. |
| 33 | However, complex histories with lots of cross-merging |
| 34 | can lead to ambiguities. Fossil keeps |
| 35 | track of historical branch names unambiguously. |
| 36 | But the extra details about branch names that Fossil keeps |
| 37 | at hand cannot be exported to Git. |
| 38 | |
| 39 | ## (4) Non-unique Tags |
| 40 | |
| @@ -44,11 +44,11 @@ | |
| 44 | it is common in Fossil to tag every release check-in with the "release" |
| 45 | tag, so that all historical releases can be found all at once. |
| 46 | ([example](/timeline?t=release)) |
| 47 | |
| 48 | Git does not allow this. The "release" tag must refer to just one |
| 49 | check-in. The work-around is that the non-unique tag in the Git export is |
| 50 | made to refer to only the most recent check-in with that tag. |
| 51 | |
| 52 | ## (5) Amendments To Check-ins |
| 53 | |
| 54 | Check-ins are immutable in both Fossil and Git. |
| 55 |
+4
-4
| --- www/mirrortogithub.md | ||
| +++ www/mirrortogithub.md | ||
| @@ -34,15 +34,15 @@ | ||
| 34 | 34 | directory if necessary. This directory will become a Git |
| 35 | 35 | repository that holds a translation of your Fossil repository. |
| 36 | 36 | |
| 37 | 37 | <p> The <code>--autopush</code> option tells Fossil that you want to |
| 38 | 38 | push the Git translation up to GitHub every time it is updated. |
| 39 | - | |
| 39 | + | |
| 40 | 40 | <p> The URL parameter is the same as the one GitHub gave you, but with |
| 41 | 41 | your GitHub <font color="orange">username</font> and <font |
| 42 | 42 | color="red">password</font> added. |
| 43 | - | |
| 43 | + | |
| 44 | 44 | <p> If your GitHub account uses two-factor authentication (2FA), you |
| 45 | 45 | will have to <a href="https://github.com/settings/tokens">generate |
| 46 | 46 | a personal access token</a> and use that in place of your actual |
| 47 | 47 | password in the URL. This token should have “repo” scope enabled, |
| 48 | 48 | only. |
| @@ -109,11 +109,11 @@ | ||
| 109 | 109 | |
| 110 | 110 | * In Git, all tags must be unique. If your Fossil repository has the |
| 111 | 111 | same tag on two or more check-ins, the tag will only be preserved on |
| 112 | 112 | the chronologically newest check-in. |
| 113 | 113 | |
| 114 | - * There is a | |
| 114 | + * There is a | |
| 115 | 115 | [long list of restrictions](https://git-scm.com/docs/git-check-ref-format) |
| 116 | 116 | on tag and branch names in Git. If any of your Fossil tag or branch names |
| 117 | 117 | violate these rules, then the names are translated prior to being exported |
| 118 | 118 | to Git. The translation usually involves converting the offending characters |
| 119 | 119 | into underscores. |
| @@ -133,11 +133,11 @@ | ||
| 133 | 133 | <https://github.com/sqlite/sqlite> |
| 134 | 134 | |
| 135 | 135 | The Fossil source repositories for these mirrors are at |
| 136 | 136 | <https://www2.fossil-scm.org/fossil> and <https://www2.sqlite.org/src>, |
| 137 | 137 | respectively. Both repositories are hosted on the same VM at |
| 138 | -[Linode](https://www.linode.com). On that machine, there is a | |
| 138 | +[Linode](https://www.linode.com). On that machine, there is a | |
| 139 | 139 | [cron job](https://linux.die.net/man/8/cron) |
| 140 | 140 | that runs at 17 minutes after the hour, every hour that does: |
| 141 | 141 | |
| 142 | 142 | > |
| 143 | 143 | /usr/bin/fossil sync -u -R /home/www/fossil/fossil.fossil |
| 144 | 144 |
| --- www/mirrortogithub.md | |
| +++ www/mirrortogithub.md | |
| @@ -34,15 +34,15 @@ | |
| 34 | directory if necessary. This directory will become a Git |
| 35 | repository that holds a translation of your Fossil repository. |
| 36 | |
| 37 | <p> The <code>--autopush</code> option tells Fossil that you want to |
| 38 | push the Git translation up to GitHub every time it is updated. |
| 39 | |
| 40 | <p> The URL parameter is the same as the one GitHub gave you, but with |
| 41 | your GitHub <font color="orange">username</font> and <font |
| 42 | color="red">password</font> added. |
| 43 | |
| 44 | <p> If your GitHub account uses two-factor authentication (2FA), you |
| 45 | will have to <a href="https://github.com/settings/tokens">generate |
| 46 | a personal access token</a> and use that in place of your actual |
| 47 | password in the URL. This token should have “repo” scope enabled, |
| 48 | only. |
| @@ -109,11 +109,11 @@ | |
| 109 | |
| 110 | * In Git, all tags must be unique. If your Fossil repository has the |
| 111 | same tag on two or more check-ins, the tag will only be preserved on |
| 112 | the chronologically newest check-in. |
| 113 | |
| 114 | * There is a |
| 115 | [long list of restrictions](https://git-scm.com/docs/git-check-ref-format) |
| 116 | on tag and branch names in Git. If any of your Fossil tag or branch names |
| 117 | violate these rules, then the names are translated prior to being exported |
| 118 | to Git. The translation usually involves converting the offending characters |
| 119 | into underscores. |
| @@ -133,11 +133,11 @@ | |
| 133 | <https://github.com/sqlite/sqlite> |
| 134 | |
| 135 | The Fossil source repositories for these mirrors are at |
| 136 | <https://www2.fossil-scm.org/fossil> and <https://www2.sqlite.org/src>, |
| 137 | respectively. Both repositories are hosted on the same VM at |
| 138 | [Linode](https://www.linode.com). On that machine, there is a |
| 139 | [cron job](https://linux.die.net/man/8/cron) |
| 140 | that runs at 17 minutes after the hour, every hour that does: |
| 141 | |
| 142 | > |
| 143 | /usr/bin/fossil sync -u -R /home/www/fossil/fossil.fossil |
| 144 |
| --- www/mirrortogithub.md | |
| +++ www/mirrortogithub.md | |
| @@ -34,15 +34,15 @@ | |
| 34 | directory if necessary. This directory will become a Git |
| 35 | repository that holds a translation of your Fossil repository. |
| 36 | |
| 37 | <p> The <code>--autopush</code> option tells Fossil that you want to |
| 38 | push the Git translation up to GitHub every time it is updated. |
| 39 | |
| 40 | <p> The URL parameter is the same as the one GitHub gave you, but with |
| 41 | your GitHub <font color="orange">username</font> and <font |
| 42 | color="red">password</font> added. |
| 43 | |
| 44 | <p> If your GitHub account uses two-factor authentication (2FA), you |
| 45 | will have to <a href="https://github.com/settings/tokens">generate |
| 46 | a personal access token</a> and use that in place of your actual |
| 47 | password in the URL. This token should have “repo” scope enabled, |
| 48 | only. |
| @@ -109,11 +109,11 @@ | |
| 109 | |
| 110 | * In Git, all tags must be unique. If your Fossil repository has the |
| 111 | same tag on two or more check-ins, the tag will only be preserved on |
| 112 | the chronologically newest check-in. |
| 113 | |
| 114 | * There is a |
| 115 | [long list of restrictions](https://git-scm.com/docs/git-check-ref-format) |
| 116 | on tag and branch names in Git. If any of your Fossil tag or branch names |
| 117 | violate these rules, then the names are translated prior to being exported |
| 118 | to Git. The translation usually involves converting the offending characters |
| 119 | into underscores. |
| @@ -133,11 +133,11 @@ | |
| 133 | <https://github.com/sqlite/sqlite> |
| 134 | |
| 135 | The Fossil source repositories for these mirrors are at |
| 136 | <https://www2.fossil-scm.org/fossil> and <https://www2.sqlite.org/src>, |
| 137 | respectively. Both repositories are hosted on the same VM at |
| 138 | [Linode](https://www.linode.com). On that machine, there is a |
| 139 | [cron job](https://linux.die.net/man/8/cron) |
| 140 | that runs at 17 minutes after the hour, every hour that does: |
| 141 | |
| 142 | > |
| 143 | /usr/bin/fossil sync -u -R /home/www/fossil/fossil.fossil |
| 144 |
+13
-13
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -1,9 +1,9 @@ | ||
| 1 | 1 | # Rebase Considered Harmful |
| 2 | 2 | |
| 3 | 3 | Fossil deliberately omits a "rebase" command because the original |
| 4 | -designer of Fossil (and [original author][vhist] of this article) considers rebase to be | |
| 4 | +designer of Fossil (and [original author][vhist] of this article) considers rebase to be | |
| 5 | 5 | an anti-pattern to be avoided. This article attempts to |
| 6 | 6 | explain that point of view. |
| 7 | 7 | |
| 8 | 8 | [vhist]: /finfo?name=www/rebaseharm.md&ubg |
| 9 | 9 | |
| @@ -10,11 +10,11 @@ | ||
| 10 | 10 | ## 1.0 Rebasing is dangerous |
| 11 | 11 | |
| 12 | 12 | Most people, even strident advocates of rebase, agree that rebase can |
| 13 | 13 | cause problems when misused. The Git rebase documentation talks about the |
| 14 | 14 | [golden rule of rebasing][golden]: never rebase on a public |
| 15 | -branch. Horror stories of misused rebase abound, and the rebase | |
| 15 | +branch. Horror stories of misused rebase abound, and the rebase | |
| 16 | 16 | documentation devotes considerable space toward explaining how to |
| 17 | 17 | recover from rebase errors and/or misuse. |
| 18 | 18 | |
| 19 | 19 | ## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities |
| 20 | 20 | |
| @@ -27,11 +27,11 @@ | ||
| 27 | 27 | ### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted |
| 28 | 28 | |
| 29 | 29 | A rebase is really nothing more than a merge (or a series of merges) |
| 30 | 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | 31 | To help illustrate this fact, |
| 32 | -consider the first rebase example from the | |
| 32 | +consider the first rebase example from the | |
| 33 | 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | 34 | |
| 35 | 35 |  |
| 36 | 36 | |
| 37 | 37 | And the rebase looks like this: |
| @@ -44,12 +44,12 @@ | ||
| 44 | 44 | |
| 45 | 45 | Thus, a rebase is just a merge that forgets where it came from. |
| 46 | 46 | |
| 47 | 47 | The Git documentation acknowledges this fact (in so many words) and |
| 48 | 48 | justifies it by saying "rebasing makes for a cleaner history." I read |
| 49 | -that sentence as a tacit admission that the Git history display | |
| 50 | -capabilities are weak and need active assistance from the user to | |
| 49 | +that sentence as a tacit admission that the Git history display | |
| 50 | +capabilities are weak and need active assistance from the user to | |
| 51 | 51 | keep things manageable. |
| 52 | 52 | Surely a better approach is to record |
| 53 | 53 | the complete ancestry of every check-in but then fix the tool to show |
| 54 | 54 | a "clean" history in those instances where a simplified display is |
| 55 | 55 | desirable and edifying, but retain the option to show the real, |
| @@ -58,18 +58,18 @@ | ||
| 58 | 58 | |
| 59 | 59 | So, another way of thinking about rebase is that it is a kind of |
| 60 | 60 | merge that intentionally forgets some details in order to |
| 61 | 61 | not overwhelm the weak history display mechanisms available in Git. |
| 62 | 62 | Wouldn't it be better, less error-prone, and easier on users |
| 63 | -to enhance the history display mechanisms in Git so that rebasing | |
| 63 | +to enhance the history display mechanisms in Git so that rebasing | |
| 64 | 64 | for a clean, linear history became unnecessary? |
| 65 | 65 | |
| 66 | 66 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs |
| 67 | 67 | |
| 68 | 68 | Another argument, often cited, is that rebasing a feature branch |
| 69 | 69 | allows one to see just the changes in the feature branch without |
| 70 | -the concurrent changes in the main line of development. | |
| 70 | +the concurrent changes in the main line of development. | |
| 71 | 71 | Consider a hypothetical case: |
| 72 | 72 | |
| 73 | 73 |  |
| 74 | 74 | |
| 75 | 75 | In the above, a feature branch consisting of check-ins C3 and C5 is |
| @@ -88,11 +88,11 @@ | ||
| 88 | 88 | history is the following merge: |
| 89 | 89 | |
| 90 | 90 |  |
| 91 | 91 | |
| 92 | 92 | Check-ins C5\' and C7 check-ins hold identical code. The only |
| 93 | -difference is in their history. | |
| 93 | +difference is in their history. | |
| 94 | 94 | |
| 95 | 95 | The argument from rebase advocates |
| 96 | 96 | is that with merge it is difficult to see only the changes associated |
| 97 | 97 | with the feature branch without the commingled mainline changes. |
| 98 | 98 | In other words, diff(C2,C7) shows changes from both the feature |
| @@ -112,11 +112,11 @@ | ||
| 112 | 112 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 113 | 113 | diff is not determined by whether you select C7 or C5\' as the target |
| 114 | 114 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 115 | 115 | |
| 116 | 116 | So, to help with the problem of viewing changes associated with a feature |
| 117 | -branch, perhaps what is needed is not rebase but rather better tools to | |
| 117 | +branch, perhaps what is needed is not rebase but rather better tools to | |
| 118 | 118 | help users identify an appropriate baseline for their diffs. |
| 119 | 119 | |
| 120 | 120 | ## <a name="siloing"></a>3.0 Rebase encourages siloed development |
| 121 | 121 | |
| 122 | 122 | The [golden rule of rebasing][golden] is that you should never do it |
| @@ -199,14 +199,14 @@ | ||
| 199 | 199 | that when you view a repository as record of what actually happened, |
| 200 | 200 | doing a rebase is "blasphemous" and "you're _lying_ about what |
| 201 | 201 | actually happened", but then goes on to justify rebase as follows: |
| 202 | 202 | |
| 203 | 203 | > |
| 204 | -_"The opposing point of view is that the commit history is the **story of | |
| 205 | -how your project was made.** You wouldn't publish the first draft of a | |
| 204 | +_"The opposing point of view is that the commit history is the **story of | |
| 205 | +how your project was made.** You wouldn't publish the first draft of a | |
| 206 | 206 | book, and the manual for how to maintain your software deserves careful |
| 207 | -editing. This is the camp that uses tools like rebase and filter-branch | |
| 207 | +editing. This is the camp that uses tools like rebase and filter-branch | |
| 208 | 208 | to tell the story in the way that's best for future readers."_ |
| 209 | 209 | |
| 210 | 210 | This counter-argument assumes you must |
| 211 | 211 | change history in order to enhance readability, which is not true. |
| 212 | 212 | |
| @@ -243,11 +243,11 @@ | ||
| 243 | 243 | Unfortunately, Git does not currently provide the ability to add |
| 244 | 244 | corrections or clarifications or supplimental notes to historical check-ins. |
| 245 | 245 | Hence, once again, |
| 246 | 246 | rebase can be seen as an attempt to work around limitations |
| 247 | 247 | of Git. Git could be enhanced to support editorial changes |
| 248 | -to check-ins. | |
| 248 | +to check-ins. | |
| 249 | 249 | Wouldn't it be better to fix the version control tool |
| 250 | 250 | rather than requiring users to fabricate a fictitious project history? |
| 251 | 251 | |
| 252 | 252 | ## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information |
| 253 | 253 | |
| 254 | 254 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -1,9 +1,9 @@ | |
| 1 | # Rebase Considered Harmful |
| 2 | |
| 3 | Fossil deliberately omits a "rebase" command because the original |
| 4 | designer of Fossil (and [original author][vhist] of this article) considers rebase to be |
| 5 | an anti-pattern to be avoided. This article attempts to |
| 6 | explain that point of view. |
| 7 | |
| 8 | [vhist]: /finfo?name=www/rebaseharm.md&ubg |
| 9 | |
| @@ -10,11 +10,11 @@ | |
| 10 | ## 1.0 Rebasing is dangerous |
| 11 | |
| 12 | Most people, even strident advocates of rebase, agree that rebase can |
| 13 | cause problems when misused. The Git rebase documentation talks about the |
| 14 | [golden rule of rebasing][golden]: never rebase on a public |
| 15 | branch. Horror stories of misused rebase abound, and the rebase |
| 16 | documentation devotes considerable space toward explaining how to |
| 17 | recover from rebase errors and/or misuse. |
| 18 | |
| 19 | ## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities |
| 20 | |
| @@ -27,11 +27,11 @@ | |
| 27 | ### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted |
| 28 | |
| 29 | A rebase is really nothing more than a merge (or a series of merges) |
| 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | To help illustrate this fact, |
| 32 | consider the first rebase example from the |
| 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | |
| 35 |  |
| 36 | |
| 37 | And the rebase looks like this: |
| @@ -44,12 +44,12 @@ | |
| 44 | |
| 45 | Thus, a rebase is just a merge that forgets where it came from. |
| 46 | |
| 47 | The Git documentation acknowledges this fact (in so many words) and |
| 48 | justifies it by saying "rebasing makes for a cleaner history." I read |
| 49 | that sentence as a tacit admission that the Git history display |
| 50 | capabilities are weak and need active assistance from the user to |
| 51 | keep things manageable. |
| 52 | Surely a better approach is to record |
| 53 | the complete ancestry of every check-in but then fix the tool to show |
| 54 | a "clean" history in those instances where a simplified display is |
| 55 | desirable and edifying, but retain the option to show the real, |
| @@ -58,18 +58,18 @@ | |
| 58 | |
| 59 | So, another way of thinking about rebase is that it is a kind of |
| 60 | merge that intentionally forgets some details in order to |
| 61 | not overwhelm the weak history display mechanisms available in Git. |
| 62 | Wouldn't it be better, less error-prone, and easier on users |
| 63 | to enhance the history display mechanisms in Git so that rebasing |
| 64 | for a clean, linear history became unnecessary? |
| 65 | |
| 66 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs |
| 67 | |
| 68 | Another argument, often cited, is that rebasing a feature branch |
| 69 | allows one to see just the changes in the feature branch without |
| 70 | the concurrent changes in the main line of development. |
| 71 | Consider a hypothetical case: |
| 72 | |
| 73 |  |
| 74 | |
| 75 | In the above, a feature branch consisting of check-ins C3 and C5 is |
| @@ -88,11 +88,11 @@ | |
| 88 | history is the following merge: |
| 89 | |
| 90 |  |
| 91 | |
| 92 | Check-ins C5\' and C7 check-ins hold identical code. The only |
| 93 | difference is in their history. |
| 94 | |
| 95 | The argument from rebase advocates |
| 96 | is that with merge it is difficult to see only the changes associated |
| 97 | with the feature branch without the commingled mainline changes. |
| 98 | In other words, diff(C2,C7) shows changes from both the feature |
| @@ -112,11 +112,11 @@ | |
| 112 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 113 | diff is not determined by whether you select C7 or C5\' as the target |
| 114 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 115 | |
| 116 | So, to help with the problem of viewing changes associated with a feature |
| 117 | branch, perhaps what is needed is not rebase but rather better tools to |
| 118 | help users identify an appropriate baseline for their diffs. |
| 119 | |
| 120 | ## <a name="siloing"></a>3.0 Rebase encourages siloed development |
| 121 | |
| 122 | The [golden rule of rebasing][golden] is that you should never do it |
| @@ -199,14 +199,14 @@ | |
| 199 | that when you view a repository as record of what actually happened, |
| 200 | doing a rebase is "blasphemous" and "you're _lying_ about what |
| 201 | actually happened", but then goes on to justify rebase as follows: |
| 202 | |
| 203 | > |
| 204 | _"The opposing point of view is that the commit history is the **story of |
| 205 | how your project was made.** You wouldn't publish the first draft of a |
| 206 | book, and the manual for how to maintain your software deserves careful |
| 207 | editing. This is the camp that uses tools like rebase and filter-branch |
| 208 | to tell the story in the way that's best for future readers."_ |
| 209 | |
| 210 | This counter-argument assumes you must |
| 211 | change history in order to enhance readability, which is not true. |
| 212 | |
| @@ -243,11 +243,11 @@ | |
| 243 | Unfortunately, Git does not currently provide the ability to add |
| 244 | corrections or clarifications or supplimental notes to historical check-ins. |
| 245 | Hence, once again, |
| 246 | rebase can be seen as an attempt to work around limitations |
| 247 | of Git. Git could be enhanced to support editorial changes |
| 248 | to check-ins. |
| 249 | Wouldn't it be better to fix the version control tool |
| 250 | rather than requiring users to fabricate a fictitious project history? |
| 251 | |
| 252 | ## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information |
| 253 | |
| 254 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -1,9 +1,9 @@ | |
| 1 | # Rebase Considered Harmful |
| 2 | |
| 3 | Fossil deliberately omits a "rebase" command because the original |
| 4 | designer of Fossil (and [original author][vhist] of this article) considers rebase to be |
| 5 | an anti-pattern to be avoided. This article attempts to |
| 6 | explain that point of view. |
| 7 | |
| 8 | [vhist]: /finfo?name=www/rebaseharm.md&ubg |
| 9 | |
| @@ -10,11 +10,11 @@ | |
| 10 | ## 1.0 Rebasing is dangerous |
| 11 | |
| 12 | Most people, even strident advocates of rebase, agree that rebase can |
| 13 | cause problems when misused. The Git rebase documentation talks about the |
| 14 | [golden rule of rebasing][golden]: never rebase on a public |
| 15 | branch. Horror stories of misused rebase abound, and the rebase |
| 16 | documentation devotes considerable space toward explaining how to |
| 17 | recover from rebase errors and/or misuse. |
| 18 | |
| 19 | ## <a name="cap-loss"></a>2.0 Rebase provides no new capabilities |
| 20 | |
| @@ -27,11 +27,11 @@ | |
| 27 | ### <a name="orphaning"></a>2.1 A rebase is just a merge with historical references omitted |
| 28 | |
| 29 | A rebase is really nothing more than a merge (or a series of merges) |
| 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | To help illustrate this fact, |
| 32 | consider the first rebase example from the |
| 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | |
| 35 |  |
| 36 | |
| 37 | And the rebase looks like this: |
| @@ -44,12 +44,12 @@ | |
| 44 | |
| 45 | Thus, a rebase is just a merge that forgets where it came from. |
| 46 | |
| 47 | The Git documentation acknowledges this fact (in so many words) and |
| 48 | justifies it by saying "rebasing makes for a cleaner history." I read |
| 49 | that sentence as a tacit admission that the Git history display |
| 50 | capabilities are weak and need active assistance from the user to |
| 51 | keep things manageable. |
| 52 | Surely a better approach is to record |
| 53 | the complete ancestry of every check-in but then fix the tool to show |
| 54 | a "clean" history in those instances where a simplified display is |
| 55 | desirable and edifying, but retain the option to show the real, |
| @@ -58,18 +58,18 @@ | |
| 58 | |
| 59 | So, another way of thinking about rebase is that it is a kind of |
| 60 | merge that intentionally forgets some details in order to |
| 61 | not overwhelm the weak history display mechanisms available in Git. |
| 62 | Wouldn't it be better, less error-prone, and easier on users |
| 63 | to enhance the history display mechanisms in Git so that rebasing |
| 64 | for a clean, linear history became unnecessary? |
| 65 | |
| 66 | ### <a name="clean-diffs"></a>2.2 Rebase does not actually provide better feature-branch diffs |
| 67 | |
| 68 | Another argument, often cited, is that rebasing a feature branch |
| 69 | allows one to see just the changes in the feature branch without |
| 70 | the concurrent changes in the main line of development. |
| 71 | Consider a hypothetical case: |
| 72 | |
| 73 |  |
| 74 | |
| 75 | In the above, a feature branch consisting of check-ins C3 and C5 is |
| @@ -88,11 +88,11 @@ | |
| 88 | history is the following merge: |
| 89 | |
| 90 |  |
| 91 | |
| 92 | Check-ins C5\' and C7 check-ins hold identical code. The only |
| 93 | difference is in their history. |
| 94 | |
| 95 | The argument from rebase advocates |
| 96 | is that with merge it is difficult to see only the changes associated |
| 97 | with the feature branch without the commingled mainline changes. |
| 98 | In other words, diff(C2,C7) shows changes from both the feature |
| @@ -112,11 +112,11 @@ | |
| 112 | Remember: C7 and C5\' are bit-for-bit identical, so the output of the |
| 113 | diff is not determined by whether you select C7 or C5\' as the target |
| 114 | of the diff, but rather by your choice of the diff source, C2 or C6. |
| 115 | |
| 116 | So, to help with the problem of viewing changes associated with a feature |
| 117 | branch, perhaps what is needed is not rebase but rather better tools to |
| 118 | help users identify an appropriate baseline for their diffs. |
| 119 | |
| 120 | ## <a name="siloing"></a>3.0 Rebase encourages siloed development |
| 121 | |
| 122 | The [golden rule of rebasing][golden] is that you should never do it |
| @@ -199,14 +199,14 @@ | |
| 199 | that when you view a repository as record of what actually happened, |
| 200 | doing a rebase is "blasphemous" and "you're _lying_ about what |
| 201 | actually happened", but then goes on to justify rebase as follows: |
| 202 | |
| 203 | > |
| 204 | _"The opposing point of view is that the commit history is the **story of |
| 205 | how your project was made.** You wouldn't publish the first draft of a |
| 206 | book, and the manual for how to maintain your software deserves careful |
| 207 | editing. This is the camp that uses tools like rebase and filter-branch |
| 208 | to tell the story in the way that's best for future readers."_ |
| 209 | |
| 210 | This counter-argument assumes you must |
| 211 | change history in order to enhance readability, which is not true. |
| 212 | |
| @@ -243,11 +243,11 @@ | |
| 243 | Unfortunately, Git does not currently provide the ability to add |
| 244 | corrections or clarifications or supplimental notes to historical check-ins. |
| 245 | Hence, once again, |
| 246 | rebase can be seen as an attempt to work around limitations |
| 247 | of Git. Git could be enhanced to support editorial changes |
| 248 | to check-ins. |
| 249 | Wouldn't it be better to fix the version control tool |
| 250 | rather than requiring users to fabricate a fictitious project history? |
| 251 | |
| 252 | ## <a name="collapsing"></a>7.0 Collapsing check-ins throws away valuable information |
| 253 | |
| 254 |
+1
-1
| --- www/server/any/none.md | ||
| +++ www/server/any/none.md | ||
| @@ -21,11 +21,11 @@ | ||
| 21 | 21 | * “`ui`” always binds the server to the loopback IP address (127.0.0.1) |
| 22 | 22 | so that it cannot serve to other machines. |
| 23 | 23 | |
| 24 | 24 | * Anyone who visits this URL is treated as the all-powerful Setup |
| 25 | 25 | user, which is why the first difference exists. |
| 26 | - | |
| 26 | + | |
| 27 | 27 | * “`ui`” launches a local web browser pointed at this URL. |
| 28 | 28 | |
| 29 | 29 | You can omit the _REPOSITORY_ argument if you run one of the above |
| 30 | 30 | commands from within a Fossil checkout directory to serve that |
| 31 | 31 | repository: |
| 32 | 32 |
| --- www/server/any/none.md | |
| +++ www/server/any/none.md | |
| @@ -21,11 +21,11 @@ | |
| 21 | * “`ui`” always binds the server to the loopback IP address (127.0.0.1) |
| 22 | so that it cannot serve to other machines. |
| 23 | |
| 24 | * Anyone who visits this URL is treated as the all-powerful Setup |
| 25 | user, which is why the first difference exists. |
| 26 | |
| 27 | * “`ui`” launches a local web browser pointed at this URL. |
| 28 | |
| 29 | You can omit the _REPOSITORY_ argument if you run one of the above |
| 30 | commands from within a Fossil checkout directory to serve that |
| 31 | repository: |
| 32 |
| --- www/server/any/none.md | |
| +++ www/server/any/none.md | |
| @@ -21,11 +21,11 @@ | |
| 21 | * “`ui`” always binds the server to the loopback IP address (127.0.0.1) |
| 22 | so that it cannot serve to other machines. |
| 23 | |
| 24 | * Anyone who visits this URL is treated as the all-powerful Setup |
| 25 | user, which is why the first difference exists. |
| 26 | |
| 27 | * “`ui`” launches a local web browser pointed at this URL. |
| 28 | |
| 29 | You can omit the _REPOSITORY_ argument if you run one of the above |
| 30 | commands from within a Fossil checkout directory to serve that |
| 31 | repository: |
| 32 |
+42
-42
| --- www/server/index.html | ||
| +++ www/server/index.html | ||
| @@ -59,12 +59,12 @@ | ||
| 59 | 59 | |
| 60 | 60 | <p>Fossil does not require a central server, but <a |
| 61 | 61 | href="whyuseaserver.wiki">a server can be useful</a>.</p> |
| 62 | 62 | |
| 63 | 63 | <p>A Fossil server does not require much memory, CPU, or disk space |
| 64 | -and can run comfortably on a generic $5/month virtual host | |
| 65 | -or on a small device like a Raspberry Pi, or it can co-exist | |
| 64 | +and can run comfortably on a generic $5/month virtual host | |
| 65 | +or on a small device like a Raspberry Pi, or it can co-exist | |
| 66 | 66 | on a host running other services without getting in the way. |
| 67 | 67 | |
| 68 | 68 | <p>This article is a quick-reference guide for setting up your own |
| 69 | 69 | Fossil server, with links to more detailed instructions specific to |
| 70 | 70 | particular systems, should you want extra help.</p> |
| @@ -81,15 +81,15 @@ | ||
| 81 | 81 | href="$ROOT/help?cmd=new">new repository</a> and gives it the <a |
| 82 | 82 | href="../caps/admin-v-setup.md#apsu">all-powerful Setup capability</a>. |
| 83 | 83 | The 10-digit random password generated for that user is fairly strong |
| 84 | 84 | against remote attack, even without explicit password guess rate |
| 85 | 85 | limiting, but because that user has so much power, you may want to |
| 86 | - give it a much stronger password under Admin → Users.</a></li> | |
| 86 | + give it a much stronger password under Admin → Users.</a></li> | |
| 87 | 87 | |
| 88 | - <li><p>Run the Admin → Security-Audit tool to verify that other | |
| 88 | + <li><p>Run the Admin → Security-Audit tool to verify that other | |
| 89 | 89 | security-related permissions and settings are as you want them. |
| 90 | - Consider clicking the “Take it private” link on that page to lock down | |
| 90 | + Consider clicking the “Take it private� link on that page to lock down | |
| 91 | 91 | the security on that site to a level appropriate to a private |
| 92 | 92 | repository, even if you will eventually want some public service. It's |
| 93 | 93 | better to start from a secure position and open up service |
| 94 | 94 | feature-by-feature as necessary than it is to start from a fully open |
| 95 | 95 | position and lock down features one by one to achieve a secure |
| @@ -152,11 +152,11 @@ | ||
| 152 | 152 | each incoming HTTP request. The "<tt>fossil http</tt>" command reads |
| 153 | 153 | the HTTP request off of standard input, computes an appropriate |
| 154 | 154 | reply, and writes the reply on standard output. There is a separate |
| 155 | 155 | invocation of the "<tt>fossil http</tt>" command for each HTTP request. |
| 156 | 156 | The socket listener daemon takes care of relaying content to and from |
| 157 | -the client, and (in the case of <a href="any/stunnel.md">stunnel</a>) | |
| 157 | +the client, and (in the case of <a href="any/stunnel.md">stunnel</a>) | |
| 158 | 158 | handling TLS decryption and encryption. |
| 159 | 159 | |
| 160 | 160 | <h3>Stand-alone HTTP Server</h3> |
| 161 | 161 | |
| 162 | 162 | <p>This is the <a href="any/none.md">easiest method</a>. |
| @@ -191,11 +191,11 @@ | ||
| 191 | 191 | |
| 192 | 192 | <div id="tutpick" class="show"></div> |
| 193 | 193 | |
| 194 | 194 | <table style="margin-left: 6em;"> |
| 195 | 195 | <tr> |
| 196 | - <th class="host">⇩ OS / Method ⇨</th> | |
| 196 | + <th class="host">⇩ OS / Method ⇨</th> | |
| 197 | 197 | <th class="fep">direct</th> |
| 198 | 198 | <th class="fep">inetd</th> |
| 199 | 199 | <th class="fep">stunnel</th> |
| 200 | 200 | <th class="fep">CGI</th> |
| 201 | 201 | <th class="fep">SCGI</th> |
| @@ -204,54 +204,54 @@ | ||
| 204 | 204 | <th class="fep">service</th> |
| 205 | 205 | </tr> |
| 206 | 206 | |
| 207 | 207 | <tr> |
| 208 | 208 | <th class="host">Any</th> |
| 209 | - <td class="doc"><a href="any/none.md">✅</a></td> | |
| 210 | - <td class="doc"><a href="any/inetd.md">✅</a></td> | |
| 211 | - <td class="doc"><a href="any/stunnel.md">✅</a></td> | |
| 212 | - <td class="doc"><a href="any/cgi.md">✅</a></td> | |
| 213 | - <td class="doc"><a href="any/scgi.md">✅</a></td> | |
| 214 | - <td class="doc"><a href="any/althttpd.md">✅</a></td> | |
| 215 | - <td class="doc">❌</td> | |
| 216 | - <td class="doc">❌</td> | |
| 209 | + <td class="doc"><a href="any/none.md">✅</a></td> | |
| 210 | + <td class="doc"><a href="any/inetd.md">✅</a></td> | |
| 211 | + <td class="doc"><a href="any/stunnel.md">✅</a></td> | |
| 212 | + <td class="doc"><a href="any/cgi.md">✅</a></td> | |
| 213 | + <td class="doc"><a href="any/scgi.md">✅</a></td> | |
| 214 | + <td class="doc"><a href="any/althttpd.md">✅</a></td> | |
| 215 | + <td class="doc">�</td> | |
| 216 | + <td class="doc">�</td> | |
| 217 | 217 | </tr> |
| 218 | 218 | |
| 219 | 219 | <tr> |
| 220 | 220 | <th class="host">Debian/Ubuntu</th> |
| 221 | - <td class="doc"><a href="any/none.md">✅</a></td> | |
| 222 | - <td class="doc"><a href="any/inetd.md">✅</a></td> | |
| 223 | - <td class="doc"><a href="any/stunnel.md">✅</a></td> | |
| 224 | - <td class="doc"><a href="any/cgi.md">✅</a></td> | |
| 225 | - <td class="doc"><a href="any/scgi.md">✅</a></td> | |
| 226 | - <td class="doc"><a href="any/althttpd.md">✅</a></td> | |
| 227 | - <td class="doc"><a href="debian/nginx.md">✅</a></td> | |
| 228 | - <td class="doc"><a href="debian/service.md">✅</a></td> | |
| 221 | + <td class="doc"><a href="any/none.md">✅</a></td> | |
| 222 | + <td class="doc"><a href="any/inetd.md">✅</a></td> | |
| 223 | + <td class="doc"><a href="any/stunnel.md">✅</a></td> | |
| 224 | + <td class="doc"><a href="any/cgi.md">✅</a></td> | |
| 225 | + <td class="doc"><a href="any/scgi.md">✅</a></td> | |
| 226 | + <td class="doc"><a href="any/althttpd.md">✅</a></td> | |
| 227 | + <td class="doc"><a href="debian/nginx.md">✅</a></td> | |
| 228 | + <td class="doc"><a href="debian/service.md">✅</a></td> | |
| 229 | 229 | </tr> |
| 230 | 230 | |
| 231 | 231 | <tr> |
| 232 | 232 | <th class="host">macOS</th> |
| 233 | - <td class="doc"><a href="any/none.md">✅</a></td> | |
| 234 | - <td class="doc">❌</td> | |
| 235 | - <td class="doc"><a href="any/stunnel.md">✅</a></td> | |
| 236 | - <td class="doc"><a href="any/cgi.md">✅</a></td> | |
| 237 | - <td class="doc"><a href="any/scgi.md">✅</a></td> | |
| 238 | - <td class="doc"><a href="any/althttpd.md">✅</a></td> | |
| 239 | - <td class="doc">❌</td> | |
| 240 | - <td class="doc"><a href="macos/service.md">✅</a></td> | |
| 233 | + <td class="doc"><a href="any/none.md">✅</a></td> | |
| 234 | + <td class="doc">�</td> | |
| 235 | + <td class="doc"><a href="any/stunnel.md">✅</a></td> | |
| 236 | + <td class="doc"><a href="any/cgi.md">✅</a></td> | |
| 237 | + <td class="doc"><a href="any/scgi.md">✅</a></td> | |
| 238 | + <td class="doc"><a href="any/althttpd.md">✅</a></td> | |
| 239 | + <td class="doc">�</td> | |
| 240 | + <td class="doc"><a href="macos/service.md">✅</a></td> | |
| 241 | 241 | </tr> |
| 242 | 242 | |
| 243 | 243 | <tr> |
| 244 | 244 | <th class="host">Windows</th> |
| 245 | - <td class="doc"><a href="windows/none.md">✅</a></td> | |
| 246 | - <td class="doc">❌</td> | |
| 247 | - <td class="doc"><a href="windows/stunnel.md">✅</a></td> | |
| 248 | - <td class="doc"><a href="windows/cgi.md">✅</a></td> | |
| 249 | - <td class="doc">❌</td> | |
| 250 | - <td class="doc">❌</td> | |
| 251 | - <td class="doc"><a href="windows/iis.md">✅</a></td> | |
| 252 | - <td class="doc"><a href="windows/service.md">✅</a></td> | |
| 245 | + <td class="doc"><a href="windows/none.md">✅</a></td> | |
| 246 | + <td class="doc">�</td> | |
| 247 | + <td class="doc"><a href="windows/stunnel.md">✅</a></td> | |
| 248 | + <td class="doc"><a href="windows/cgi.md">✅</a></td> | |
| 249 | + <td class="doc">�</td> | |
| 250 | + <td class="doc">�</td> | |
| 251 | + <td class="doc"><a href="windows/iis.md">✅</a></td> | |
| 252 | + <td class="doc"><a href="windows/service.md">✅</a></td> | |
| 253 | 253 | </tr> |
| 254 | 254 | </table> |
| 255 | 255 | |
| 256 | 256 | <p>Where there is a check mark in the "<b>Any</b>" row, the method for that is |
| 257 | 257 | generic enough that it works across OSes that Fossil is known to work |
| @@ -263,11 +263,11 @@ | ||
| 263 | 263 | href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> for |
| 264 | 264 | Fossil's built-in HTTP server: <a href="debian/nginx.md">nginx</a>, <a |
| 265 | 265 | href="windows/iis.md">IIS</a>, Apache, etc.</p> |
| 266 | 266 | |
| 267 | 267 | <p>We welcome <a href="../contribute.wiki">contributions</a> to fill gaps |
| 268 | -(<font size="-2">❌</font>) in the table above.</p> | |
| 268 | +(<font size="-2">�</font>) in the table above.</p> | |
| 269 | 269 | </noscript> |
| 270 | 270 | |
| 271 | 271 | |
| 272 | 272 | <h2 id="postsetup">Post-Activation Configuration</h2> |
| 273 | 273 | |
| @@ -290,11 +290,11 @@ | ||
| 290 | 290 | <li><p>Modify the repository's look and feel by <a |
| 291 | 291 | href="../customskin.md">customizing the skin</a>.</p></li> |
| 292 | 292 | |
| 293 | 293 | <li><p>If the repository includes <a |
| 294 | 294 | href="../embeddeddoc.wiki">embedded documentation</a>, consider |
| 295 | - activating the search feature (Admin → Search) so that visitors can do | |
| 295 | + activating the search feature (Admin → Search) so that visitors can do | |
| 296 | 296 | full-text search on your documentation.</p></li> |
| 297 | 297 | |
| 298 | 298 | <li><p>Now that others can be making changes to the repository, |
| 299 | 299 | consider monitoring them via <a href="../alerts.md">email alerts</a> |
| 300 | 300 | or the <a href="$ROOT/help?cmd=/timeline.rss">timeline RSS |
| @@ -301,11 +301,11 @@ | ||
| 301 | 301 | feed</a>.</p></li> |
| 302 | 302 | |
| 303 | 303 | <li><p>Turn on the various logging features.</p></li> |
| 304 | 304 | </ol> |
| 305 | 305 | |
| 306 | -<p>Reload the Admin → Security-Audit page occasionally during this | |
| 306 | +<p>Reload the Admin → Security-Audit page occasionally during this | |
| 307 | 307 | process to double check that you have not mistakenly configured the |
| 308 | 308 | server in a way that might expose information that you want to keep |
| 309 | 309 | private.</p> |
| 310 | 310 | |
| 311 | 311 | |
| 312 | 312 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -59,12 +59,12 @@ | |
| 59 | |
| 60 | <p>Fossil does not require a central server, but <a |
| 61 | href="whyuseaserver.wiki">a server can be useful</a>.</p> |
| 62 | |
| 63 | <p>A Fossil server does not require much memory, CPU, or disk space |
| 64 | and can run comfortably on a generic $5/month virtual host |
| 65 | or on a small device like a Raspberry Pi, or it can co-exist |
| 66 | on a host running other services without getting in the way. |
| 67 | |
| 68 | <p>This article is a quick-reference guide for setting up your own |
| 69 | Fossil server, with links to more detailed instructions specific to |
| 70 | particular systems, should you want extra help.</p> |
| @@ -81,15 +81,15 @@ | |
| 81 | href="$ROOT/help?cmd=new">new repository</a> and gives it the <a |
| 82 | href="../caps/admin-v-setup.md#apsu">all-powerful Setup capability</a>. |
| 83 | The 10-digit random password generated for that user is fairly strong |
| 84 | against remote attack, even without explicit password guess rate |
| 85 | limiting, but because that user has so much power, you may want to |
| 86 | give it a much stronger password under Admin → Users.</a></li> |
| 87 | |
| 88 | <li><p>Run the Admin → Security-Audit tool to verify that other |
| 89 | security-related permissions and settings are as you want them. |
| 90 | Consider clicking the “Take it private” link on that page to lock down |
| 91 | the security on that site to a level appropriate to a private |
| 92 | repository, even if you will eventually want some public service. It's |
| 93 | better to start from a secure position and open up service |
| 94 | feature-by-feature as necessary than it is to start from a fully open |
| 95 | position and lock down features one by one to achieve a secure |
| @@ -152,11 +152,11 @@ | |
| 152 | each incoming HTTP request. The "<tt>fossil http</tt>" command reads |
| 153 | the HTTP request off of standard input, computes an appropriate |
| 154 | reply, and writes the reply on standard output. There is a separate |
| 155 | invocation of the "<tt>fossil http</tt>" command for each HTTP request. |
| 156 | The socket listener daemon takes care of relaying content to and from |
| 157 | the client, and (in the case of <a href="any/stunnel.md">stunnel</a>) |
| 158 | handling TLS decryption and encryption. |
| 159 | |
| 160 | <h3>Stand-alone HTTP Server</h3> |
| 161 | |
| 162 | <p>This is the <a href="any/none.md">easiest method</a>. |
| @@ -191,11 +191,11 @@ | |
| 191 | |
| 192 | <div id="tutpick" class="show"></div> |
| 193 | |
| 194 | <table style="margin-left: 6em;"> |
| 195 | <tr> |
| 196 | <th class="host">⇩ OS / Method ⇨</th> |
| 197 | <th class="fep">direct</th> |
| 198 | <th class="fep">inetd</th> |
| 199 | <th class="fep">stunnel</th> |
| 200 | <th class="fep">CGI</th> |
| 201 | <th class="fep">SCGI</th> |
| @@ -204,54 +204,54 @@ | |
| 204 | <th class="fep">service</th> |
| 205 | </tr> |
| 206 | |
| 207 | <tr> |
| 208 | <th class="host">Any</th> |
| 209 | <td class="doc"><a href="any/none.md">✅</a></td> |
| 210 | <td class="doc"><a href="any/inetd.md">✅</a></td> |
| 211 | <td class="doc"><a href="any/stunnel.md">✅</a></td> |
| 212 | <td class="doc"><a href="any/cgi.md">✅</a></td> |
| 213 | <td class="doc"><a href="any/scgi.md">✅</a></td> |
| 214 | <td class="doc"><a href="any/althttpd.md">✅</a></td> |
| 215 | <td class="doc">❌</td> |
| 216 | <td class="doc">❌</td> |
| 217 | </tr> |
| 218 | |
| 219 | <tr> |
| 220 | <th class="host">Debian/Ubuntu</th> |
| 221 | <td class="doc"><a href="any/none.md">✅</a></td> |
| 222 | <td class="doc"><a href="any/inetd.md">✅</a></td> |
| 223 | <td class="doc"><a href="any/stunnel.md">✅</a></td> |
| 224 | <td class="doc"><a href="any/cgi.md">✅</a></td> |
| 225 | <td class="doc"><a href="any/scgi.md">✅</a></td> |
| 226 | <td class="doc"><a href="any/althttpd.md">✅</a></td> |
| 227 | <td class="doc"><a href="debian/nginx.md">✅</a></td> |
| 228 | <td class="doc"><a href="debian/service.md">✅</a></td> |
| 229 | </tr> |
| 230 | |
| 231 | <tr> |
| 232 | <th class="host">macOS</th> |
| 233 | <td class="doc"><a href="any/none.md">✅</a></td> |
| 234 | <td class="doc">❌</td> |
| 235 | <td class="doc"><a href="any/stunnel.md">✅</a></td> |
| 236 | <td class="doc"><a href="any/cgi.md">✅</a></td> |
| 237 | <td class="doc"><a href="any/scgi.md">✅</a></td> |
| 238 | <td class="doc"><a href="any/althttpd.md">✅</a></td> |
| 239 | <td class="doc">❌</td> |
| 240 | <td class="doc"><a href="macos/service.md">✅</a></td> |
| 241 | </tr> |
| 242 | |
| 243 | <tr> |
| 244 | <th class="host">Windows</th> |
| 245 | <td class="doc"><a href="windows/none.md">✅</a></td> |
| 246 | <td class="doc">❌</td> |
| 247 | <td class="doc"><a href="windows/stunnel.md">✅</a></td> |
| 248 | <td class="doc"><a href="windows/cgi.md">✅</a></td> |
| 249 | <td class="doc">❌</td> |
| 250 | <td class="doc">❌</td> |
| 251 | <td class="doc"><a href="windows/iis.md">✅</a></td> |
| 252 | <td class="doc"><a href="windows/service.md">✅</a></td> |
| 253 | </tr> |
| 254 | </table> |
| 255 | |
| 256 | <p>Where there is a check mark in the "<b>Any</b>" row, the method for that is |
| 257 | generic enough that it works across OSes that Fossil is known to work |
| @@ -263,11 +263,11 @@ | |
| 263 | href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> for |
| 264 | Fossil's built-in HTTP server: <a href="debian/nginx.md">nginx</a>, <a |
| 265 | href="windows/iis.md">IIS</a>, Apache, etc.</p> |
| 266 | |
| 267 | <p>We welcome <a href="../contribute.wiki">contributions</a> to fill gaps |
| 268 | (<font size="-2">❌</font>) in the table above.</p> |
| 269 | </noscript> |
| 270 | |
| 271 | |
| 272 | <h2 id="postsetup">Post-Activation Configuration</h2> |
| 273 | |
| @@ -290,11 +290,11 @@ | |
| 290 | <li><p>Modify the repository's look and feel by <a |
| 291 | href="../customskin.md">customizing the skin</a>.</p></li> |
| 292 | |
| 293 | <li><p>If the repository includes <a |
| 294 | href="../embeddeddoc.wiki">embedded documentation</a>, consider |
| 295 | activating the search feature (Admin → Search) so that visitors can do |
| 296 | full-text search on your documentation.</p></li> |
| 297 | |
| 298 | <li><p>Now that others can be making changes to the repository, |
| 299 | consider monitoring them via <a href="../alerts.md">email alerts</a> |
| 300 | or the <a href="$ROOT/help?cmd=/timeline.rss">timeline RSS |
| @@ -301,11 +301,11 @@ | |
| 301 | feed</a>.</p></li> |
| 302 | |
| 303 | <li><p>Turn on the various logging features.</p></li> |
| 304 | </ol> |
| 305 | |
| 306 | <p>Reload the Admin → Security-Audit page occasionally during this |
| 307 | process to double check that you have not mistakenly configured the |
| 308 | server in a way that might expose information that you want to keep |
| 309 | private.</p> |
| 310 | |
| 311 | |
| 312 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -59,12 +59,12 @@ | |
| 59 | |
| 60 | <p>Fossil does not require a central server, but <a |
| 61 | href="whyuseaserver.wiki">a server can be useful</a>.</p> |
| 62 | |
| 63 | <p>A Fossil server does not require much memory, CPU, or disk space |
| 64 | and can run comfortably on a generic $5/month virtual host |
| 65 | or on a small device like a Raspberry Pi, or it can co-exist |
| 66 | on a host running other services without getting in the way. |
| 67 | |
| 68 | <p>This article is a quick-reference guide for setting up your own |
| 69 | Fossil server, with links to more detailed instructions specific to |
| 70 | particular systems, should you want extra help.</p> |
| @@ -81,15 +81,15 @@ | |
| 81 | href="$ROOT/help?cmd=new">new repository</a> and gives it the <a |
| 82 | href="../caps/admin-v-setup.md#apsu">all-powerful Setup capability</a>. |
| 83 | The 10-digit random password generated for that user is fairly strong |
| 84 | against remote attack, even without explicit password guess rate |
| 85 | limiting, but because that user has so much power, you may want to |
| 86 | give it a much stronger password under Admin → Users.</a></li> |
| 87 | |
| 88 | <li><p>Run the Admin → Security-Audit tool to verify that other |
| 89 | security-related permissions and settings are as you want them. |
| 90 | Consider clicking the “Take it private� link on that page to lock down |
| 91 | the security on that site to a level appropriate to a private |
| 92 | repository, even if you will eventually want some public service. It's |
| 93 | better to start from a secure position and open up service |
| 94 | feature-by-feature as necessary than it is to start from a fully open |
| 95 | position and lock down features one by one to achieve a secure |
| @@ -152,11 +152,11 @@ | |
| 152 | each incoming HTTP request. The "<tt>fossil http</tt>" command reads |
| 153 | the HTTP request off of standard input, computes an appropriate |
| 154 | reply, and writes the reply on standard output. There is a separate |
| 155 | invocation of the "<tt>fossil http</tt>" command for each HTTP request. |
| 156 | The socket listener daemon takes care of relaying content to and from |
| 157 | the client, and (in the case of <a href="any/stunnel.md">stunnel</a>) |
| 158 | handling TLS decryption and encryption. |
| 159 | |
| 160 | <h3>Stand-alone HTTP Server</h3> |
| 161 | |
| 162 | <p>This is the <a href="any/none.md">easiest method</a>. |
| @@ -191,11 +191,11 @@ | |
| 191 | |
| 192 | <div id="tutpick" class="show"></div> |
| 193 | |
| 194 | <table style="margin-left: 6em;"> |
| 195 | <tr> |
| 196 | <th class="host">⇩ OS / Method ⇨</th> |
| 197 | <th class="fep">direct</th> |
| 198 | <th class="fep">inetd</th> |
| 199 | <th class="fep">stunnel</th> |
| 200 | <th class="fep">CGI</th> |
| 201 | <th class="fep">SCGI</th> |
| @@ -204,54 +204,54 @@ | |
| 204 | <th class="fep">service</th> |
| 205 | </tr> |
| 206 | |
| 207 | <tr> |
| 208 | <th class="host">Any</th> |
| 209 | <td class="doc"><a href="any/none.md">✅</a></td> |
| 210 | <td class="doc"><a href="any/inetd.md">✅</a></td> |
| 211 | <td class="doc"><a href="any/stunnel.md">✅</a></td> |
| 212 | <td class="doc"><a href="any/cgi.md">✅</a></td> |
| 213 | <td class="doc"><a href="any/scgi.md">✅</a></td> |
| 214 | <td class="doc"><a href="any/althttpd.md">✅</a></td> |
| 215 | <td class="doc">�</td> |
| 216 | <td class="doc">�</td> |
| 217 | </tr> |
| 218 | |
| 219 | <tr> |
| 220 | <th class="host">Debian/Ubuntu</th> |
| 221 | <td class="doc"><a href="any/none.md">✅</a></td> |
| 222 | <td class="doc"><a href="any/inetd.md">✅</a></td> |
| 223 | <td class="doc"><a href="any/stunnel.md">✅</a></td> |
| 224 | <td class="doc"><a href="any/cgi.md">✅</a></td> |
| 225 | <td class="doc"><a href="any/scgi.md">✅</a></td> |
| 226 | <td class="doc"><a href="any/althttpd.md">✅</a></td> |
| 227 | <td class="doc"><a href="debian/nginx.md">✅</a></td> |
| 228 | <td class="doc"><a href="debian/service.md">✅</a></td> |
| 229 | </tr> |
| 230 | |
| 231 | <tr> |
| 232 | <th class="host">macOS</th> |
| 233 | <td class="doc"><a href="any/none.md">✅</a></td> |
| 234 | <td class="doc">�</td> |
| 235 | <td class="doc"><a href="any/stunnel.md">✅</a></td> |
| 236 | <td class="doc"><a href="any/cgi.md">✅</a></td> |
| 237 | <td class="doc"><a href="any/scgi.md">✅</a></td> |
| 238 | <td class="doc"><a href="any/althttpd.md">✅</a></td> |
| 239 | <td class="doc">�</td> |
| 240 | <td class="doc"><a href="macos/service.md">✅</a></td> |
| 241 | </tr> |
| 242 | |
| 243 | <tr> |
| 244 | <th class="host">Windows</th> |
| 245 | <td class="doc"><a href="windows/none.md">✅</a></td> |
| 246 | <td class="doc">�</td> |
| 247 | <td class="doc"><a href="windows/stunnel.md">✅</a></td> |
| 248 | <td class="doc"><a href="windows/cgi.md">✅</a></td> |
| 249 | <td class="doc">�</td> |
| 250 | <td class="doc">�</td> |
| 251 | <td class="doc"><a href="windows/iis.md">✅</a></td> |
| 252 | <td class="doc"><a href="windows/service.md">✅</a></td> |
| 253 | </tr> |
| 254 | </table> |
| 255 | |
| 256 | <p>Where there is a check mark in the "<b>Any</b>" row, the method for that is |
| 257 | generic enough that it works across OSes that Fossil is known to work |
| @@ -263,11 +263,11 @@ | |
| 263 | href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> for |
| 264 | Fossil's built-in HTTP server: <a href="debian/nginx.md">nginx</a>, <a |
| 265 | href="windows/iis.md">IIS</a>, Apache, etc.</p> |
| 266 | |
| 267 | <p>We welcome <a href="../contribute.wiki">contributions</a> to fill gaps |
| 268 | (<font size="-2">�</font>) in the table above.</p> |
| 269 | </noscript> |
| 270 | |
| 271 | |
| 272 | <h2 id="postsetup">Post-Activation Configuration</h2> |
| 273 | |
| @@ -290,11 +290,11 @@ | |
| 290 | <li><p>Modify the repository's look and feel by <a |
| 291 | href="../customskin.md">customizing the skin</a>.</p></li> |
| 292 | |
| 293 | <li><p>If the repository includes <a |
| 294 | href="../embeddeddoc.wiki">embedded documentation</a>, consider |
| 295 | activating the search feature (Admin → Search) so that visitors can do |
| 296 | full-text search on your documentation.</p></li> |
| 297 | |
| 298 | <li><p>Now that others can be making changes to the repository, |
| 299 | consider monitoring them via <a href="../alerts.md">email alerts</a> |
| 300 | or the <a href="$ROOT/help?cmd=/timeline.rss">timeline RSS |
| @@ -301,11 +301,11 @@ | |
| 301 | feed</a>.</p></li> |
| 302 | |
| 303 | <li><p>Turn on the various logging features.</p></li> |
| 304 | </ol> |
| 305 | |
| 306 | <p>Reload the Admin → Security-Audit page occasionally during this |
| 307 | process to double check that you have not mistakenly configured the |
| 308 | server in a way that might expose information that you want to keep |
| 309 | private.</p> |
| 310 | |
| 311 | |
| 312 |
+2
-2
| --- www/server/whyuseaserver.wiki | ||
| +++ www/server/whyuseaserver.wiki | ||
| @@ -2,11 +2,11 @@ | ||
| 2 | 2 | |
| 3 | 3 | <h2>No Server Required</h2> |
| 4 | 4 | |
| 5 | 5 | Fossil does not require a central server. |
| 6 | 6 | Data sharing and synchronization can be entirely peer-to-peer. |
| 7 | -Fossil uses | |
| 7 | +Fossil uses | |
| 8 | 8 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|conflict-free replicated data types] |
| 9 | 9 | to ensure that (in the limit) all participating peers see the same content. |
| 10 | 10 | |
| 11 | 11 | <h2>But, A Server Can Be Useful</h2> |
| 12 | 12 | |
| @@ -13,11 +13,11 @@ | ||
| 13 | 13 | Fossil does not require a server, but a server can be very useful. |
| 14 | 14 | Here are a few reasons to set up a Fossil server for your project: |
| 15 | 15 | |
| 16 | 16 | 1. <b>A server works as a complete project website.</b><p> |
| 17 | 17 | Fossil does more than just version control. It also supports |
| 18 | - [../tickets.wiki|trouble-tickets], | |
| 18 | + [../tickets.wiki|trouble-tickets], | |
| 19 | 19 | [../wikitheory.wiki|wiki], and a [../forum.wiki|forum]. |
| 20 | 20 | The [../embeddeddoc.wiki|embedded documentation] |
| 21 | 21 | feature provides a great mechanism for providing project documentation. |
| 22 | 22 | The [../unvers.wiki|unversioned files] feature is a convenient way |
| 23 | 23 | to host builds and downloads on the project website. |
| 24 | 24 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -2,11 +2,11 @@ | |
| 2 | |
| 3 | <h2>No Server Required</h2> |
| 4 | |
| 5 | Fossil does not require a central server. |
| 6 | Data sharing and synchronization can be entirely peer-to-peer. |
| 7 | Fossil uses |
| 8 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|conflict-free replicated data types] |
| 9 | to ensure that (in the limit) all participating peers see the same content. |
| 10 | |
| 11 | <h2>But, A Server Can Be Useful</h2> |
| 12 | |
| @@ -13,11 +13,11 @@ | |
| 13 | Fossil does not require a server, but a server can be very useful. |
| 14 | Here are a few reasons to set up a Fossil server for your project: |
| 15 | |
| 16 | 1. <b>A server works as a complete project website.</b><p> |
| 17 | Fossil does more than just version control. It also supports |
| 18 | [../tickets.wiki|trouble-tickets], |
| 19 | [../wikitheory.wiki|wiki], and a [../forum.wiki|forum]. |
| 20 | The [../embeddeddoc.wiki|embedded documentation] |
| 21 | feature provides a great mechanism for providing project documentation. |
| 22 | The [../unvers.wiki|unversioned files] feature is a convenient way |
| 23 | to host builds and downloads on the project website. |
| 24 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -2,11 +2,11 @@ | |
| 2 | |
| 3 | <h2>No Server Required</h2> |
| 4 | |
| 5 | Fossil does not require a central server. |
| 6 | Data sharing and synchronization can be entirely peer-to-peer. |
| 7 | Fossil uses |
| 8 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|conflict-free replicated data types] |
| 9 | to ensure that (in the limit) all participating peers see the same content. |
| 10 | |
| 11 | <h2>But, A Server Can Be Useful</h2> |
| 12 | |
| @@ -13,11 +13,11 @@ | |
| 13 | Fossil does not require a server, but a server can be very useful. |
| 14 | Here are a few reasons to set up a Fossil server for your project: |
| 15 | |
| 16 | 1. <b>A server works as a complete project website.</b><p> |
| 17 | Fossil does more than just version control. It also supports |
| 18 | [../tickets.wiki|trouble-tickets], |
| 19 | [../wikitheory.wiki|wiki], and a [../forum.wiki|forum]. |
| 20 | The [../embeddeddoc.wiki|embedded documentation] |
| 21 | feature provides a great mechanism for providing project documentation. |
| 22 | The [../unvers.wiki|unversioned files] feature is a convenient way |
| 23 | to host builds and downloads on the project website. |
| 24 |
+1
-1
| --- www/server/windows/iis.md | ||
| +++ www/server/windows/iis.md | ||
| @@ -59,11 +59,11 @@ | ||
| 59 | 59 | 2. Tell it you want to “Add roles and features” |
| 60 | 60 | 3. Select “Role-based or feature-based installation” |
| 61 | 61 | 4. Select your local server |
| 62 | 62 | 5. In the Server Roles section, enable “Web Server (IIS)” |
| 63 | 63 | |
| 64 | -### Windows | |
| 64 | +### Windows | |
| 65 | 65 | |
| 66 | 66 | 1. Open Control Panel |
| 67 | 67 | 2. Go to “Programs” |
| 68 | 68 | 3. Select “Turn Windows features on or off” in the left-side pane |
| 69 | 69 | 4. In the “Windows Features” dialog, enable “Internet Information |
| 70 | 70 |
| --- www/server/windows/iis.md | |
| +++ www/server/windows/iis.md | |
| @@ -59,11 +59,11 @@ | |
| 59 | 2. Tell it you want to “Add roles and features” |
| 60 | 3. Select “Role-based or feature-based installation” |
| 61 | 4. Select your local server |
| 62 | 5. In the Server Roles section, enable “Web Server (IIS)” |
| 63 | |
| 64 | ### Windows |
| 65 | |
| 66 | 1. Open Control Panel |
| 67 | 2. Go to “Programs” |
| 68 | 3. Select “Turn Windows features on or off” in the left-side pane |
| 69 | 4. In the “Windows Features” dialog, enable “Internet Information |
| 70 |
| --- www/server/windows/iis.md | |
| +++ www/server/windows/iis.md | |
| @@ -59,11 +59,11 @@ | |
| 59 | 2. Tell it you want to “Add roles and features” |
| 60 | 3. Select “Role-based or feature-based installation” |
| 61 | 4. Select your local server |
| 62 | 5. In the Server Roles section, enable “Web Server (IIS)” |
| 63 | |
| 64 | ### Windows |
| 65 | |
| 66 | 1. Open Control Panel |
| 67 | 2. Go to “Programs” |
| 68 | 3. Select “Turn Windows features on or off” in the left-side pane |
| 69 | 4. In the “Windows Features” dialog, enable “Internet Information |
| 70 |
+14
-14
| --- www/serverext.wiki | ||
| +++ www/serverext.wiki | ||
| @@ -7,18 +7,18 @@ | ||
| 7 | 7 | extensions to that server. These extensions work like |
| 8 | 8 | any other CGI program, except that they also have access to the Fossil |
| 9 | 9 | login information and can (optionally) leverage the "skins" of Fossil |
| 10 | 10 | so that they appear to be more tightly integrated into the project. |
| 11 | 11 | |
| 12 | -An example of where this is useful is the | |
| 12 | +An example of where this is useful is the | |
| 13 | 13 | [https://sqlite.org/src/ext/checklist|checklist application] on |
| 14 | 14 | the [https://sqlite.org/|SQLite] project. The checklist |
| 15 | 15 | helps the SQLite developers track which release tests have passed, |
| 16 | 16 | or failed, or are still to be done. The checklist program began as a |
| 17 | 17 | stand-alone CGI which kept its own private user database and implemented |
| 18 | 18 | its own permissions and login system and provided its own CSS. By |
| 19 | -converting checklist into a Fossil extension, the same login that works | |
| 19 | +converting checklist into a Fossil extension, the same login that works | |
| 20 | 20 | for the [https://sqlite.org/src|main SQLite source repository] also works |
| 21 | 21 | for the checklist. Permission to change elements of the checklist |
| 22 | 22 | is tied on permission to check-in to the main source repository. And |
| 23 | 23 | the standard Fossil header menu and footer appear on each page of |
| 24 | 24 | the checklist. |
| @@ -26,22 +26,22 @@ | ||
| 26 | 26 | <h2>2.0 How It Works</h2> |
| 27 | 27 | |
| 28 | 28 | CGI Extensions are disabled by default. |
| 29 | 29 | An administrator activates the CGI extension mechanism by specifying |
| 30 | 30 | an "Extension Root Directory" or "extroot" as part of the server setup. |
| 31 | -If the Fossil server is itself run as | |
| 32 | -[./server/any/cgi.md|CGI], then add a line to the | |
| 31 | +If the Fossil server is itself run as | |
| 32 | +[./server/any/cgi.md|CGI], then add a line to the | |
| 33 | 33 | [./cgi.wiki#extroot|CGI script file] that says: |
| 34 | 34 | |
| 35 | 35 | <blockquote><pre> |
| 36 | 36 | extroot: <i>DIRECTORY</i> |
| 37 | 37 | </pre></blockquote> |
| 38 | 38 | |
| 39 | -Or, if the Fossil server is being run using the | |
| 40 | -"[./server/any/none.md|fossil server]" or | |
| 41 | -"[./server/any/none.md|fossil ui]" or | |
| 42 | -"[./server/any/inetd.md|fossil http]" commands, then add an extra | |
| 39 | +Or, if the Fossil server is being run using the | |
| 40 | +"[./server/any/none.md|fossil server]" o | |
| 41 | +"[./server/any/none.md|fossil ui]" or | |
| 42 | +"[./server/any/inetd.md|fossil http]" commands, then add an extra | |
| 43 | 43 | "--extroot <i>DIRECTORY</i>" option to that command. |
| 44 | 44 | |
| 45 | 45 | The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI. |
| 46 | 46 | Files in the DOCUMENT_ROOT are accessed via URLs like this: |
| 47 | 47 | |
| @@ -160,11 +160,11 @@ | ||
| 160 | 160 | can be found at links like these: |
| 161 | 161 | |
| 162 | 162 | * [https://fossil-scm.org/home/test_env] |
| 163 | 163 | * [https://sqlite.org/src/ext/checklist/top/env] |
| 164 | 164 | |
| 165 | -In addition to the standard CGI environment variables listed above, | |
| 165 | +In addition to the standard CGI environment variables listed above, | |
| 166 | 166 | Fossil adds the following: |
| 167 | 167 | |
| 168 | 168 | * FOSSIL_CAPABILITIES |
| 169 | 169 | * FOSSIL_NONCE |
| 170 | 170 | * FOSSIL_REPOSITORY |
| @@ -171,11 +171,11 @@ | ||
| 171 | 171 | * FOSSIL_URI |
| 172 | 172 | * FOSSIL_USER |
| 173 | 173 | |
| 174 | 174 | The FOSSIL_USER string is the name of the logged-in user. This variable |
| 175 | 175 | is missing or is an empty string if the user is not logged in. The |
| 176 | -FOSSIL_CAPABILITIES string is a list of | |
| 176 | +FOSSIL_CAPABILITIES string is a list of | |
| 177 | 177 | [./caps/ref.html|Fossil capabilities] that |
| 178 | 178 | indicate what permissions the user has on the Fossil repository. |
| 179 | 179 | The FOSSIL_REPOSITORY environment variable gives the filename of the |
| 180 | 180 | Fossil repository that is running. The FOSSIL_URI variable shows the |
| 181 | 181 | prefix of the REQUEST_URI that is the Fossil CGI script, or is an |
| @@ -192,11 +192,11 @@ | ||
| 192 | 192 | this happens. |
| 193 | 193 | |
| 194 | 194 | If the CGI output is one of the forms for which Fossil inserts its own |
| 195 | 195 | header and footer, then the inserted header will include a |
| 196 | 196 | Content Security Policy (CSP) restriction on the use of javascript within |
| 197 | -the webpage. Any <script>...</script> elements within the | |
| 197 | +the webpage. Any <script>...</script> elements within the | |
| 198 | 198 | CGI output must include a nonce or else they will be suppressed by the |
| 199 | 199 | web browser. The FOSSIL_NONCE variable contains the value of that nonce. |
| 200 | 200 | So, in other words, to get javascript to work, it must be enclosed in: |
| 201 | 201 | |
| 202 | 202 | <blockquote><verbatim> |
| @@ -233,11 +233,11 @@ | ||
| 233 | 233 | Those that Fossil does not understand are simply relayed back to up the |
| 234 | 234 | line to the requester. |
| 235 | 235 | |
| 236 | 236 | Fossil takes special action with some content types. If the Content-Type |
| 237 | 237 | is "text/x-fossil-wiki" or "text/x-markdown" then Fossil |
| 238 | -converts the content from [/wiki_rules|Fossil-Wiki] or | |
| 238 | +converts the content from [/wiki_rules|Fossil-Wiki] or | |
| 239 | 239 | [/md_rules|Markdown] into HTML, adding its |
| 240 | 240 | own header and footer text according to the repository skin. Content |
| 241 | 241 | of type "text/html" is normally passed straight through |
| 242 | 242 | unchanged. However, if the text/html content is of the form: |
| 243 | 243 | |
| @@ -246,11 +246,11 @@ | ||
| 246 | 246 | ... HTML content there ... |
| 247 | 247 | </div> |
| 248 | 248 | </verbatim></blockquote> |
| 249 | 249 | |
| 250 | 250 | In other words, if the outer-most markup of the HTML is a <div> |
| 251 | -element with a single class of "fossil-doc", | |
| 251 | +element with a single class of "fossil-doc", | |
| 252 | 252 | then Fossil will adds its own header and footer to the HTML. The |
| 253 | 253 | page title contained in the added header will be extracted from the |
| 254 | 254 | "data-title" attribute. |
| 255 | 255 | |
| 256 | 256 | Except for the three cases noted above, Fossil makes no changes or |
| @@ -291,13 +291,13 @@ | ||
| 291 | 291 | have been adjusted accordingly and that all resources needed by the |
| 292 | 292 | CGI program are available within the chroot jail. |
| 293 | 293 | |
| 294 | 294 | If anything goes wrong while trying to process an /ext page, Fossil |
| 295 | 295 | returns a 404 Not Found error with no details. However, if the requester |
| 296 | -is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability | |
| 296 | +is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability | |
| 297 | 297 | then additional diagnostic information may be included in the output. |
| 298 | 298 | |
| 299 | 299 | If the /ext page has a "fossil-ext-debug=1" query parameter and if |
| 300 | 300 | the requester is logged in as a user with Debug privilege, then the |
| 301 | 301 | CGI output is returned verbatim, as text/plain and with the original |
| 302 | 302 | header intact. This is useful for diagnosing problems with the |
| 303 | 303 | CGI script. |
| 304 | 304 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -7,18 +7,18 @@ | |
| 7 | extensions to that server. These extensions work like |
| 8 | any other CGI program, except that they also have access to the Fossil |
| 9 | login information and can (optionally) leverage the "skins" of Fossil |
| 10 | so that they appear to be more tightly integrated into the project. |
| 11 | |
| 12 | An example of where this is useful is the |
| 13 | [https://sqlite.org/src/ext/checklist|checklist application] on |
| 14 | the [https://sqlite.org/|SQLite] project. The checklist |
| 15 | helps the SQLite developers track which release tests have passed, |
| 16 | or failed, or are still to be done. The checklist program began as a |
| 17 | stand-alone CGI which kept its own private user database and implemented |
| 18 | its own permissions and login system and provided its own CSS. By |
| 19 | converting checklist into a Fossil extension, the same login that works |
| 20 | for the [https://sqlite.org/src|main SQLite source repository] also works |
| 21 | for the checklist. Permission to change elements of the checklist |
| 22 | is tied on permission to check-in to the main source repository. And |
| 23 | the standard Fossil header menu and footer appear on each page of |
| 24 | the checklist. |
| @@ -26,22 +26,22 @@ | |
| 26 | <h2>2.0 How It Works</h2> |
| 27 | |
| 28 | CGI Extensions are disabled by default. |
| 29 | An administrator activates the CGI extension mechanism by specifying |
| 30 | an "Extension Root Directory" or "extroot" as part of the server setup. |
| 31 | If the Fossil server is itself run as |
| 32 | [./server/any/cgi.md|CGI], then add a line to the |
| 33 | [./cgi.wiki#extroot|CGI script file] that says: |
| 34 | |
| 35 | <blockquote><pre> |
| 36 | extroot: <i>DIRECTORY</i> |
| 37 | </pre></blockquote> |
| 38 | |
| 39 | Or, if the Fossil server is being run using the |
| 40 | "[./server/any/none.md|fossil server]" or |
| 41 | "[./server/any/none.md|fossil ui]" or |
| 42 | "[./server/any/inetd.md|fossil http]" commands, then add an extra |
| 43 | "--extroot <i>DIRECTORY</i>" option to that command. |
| 44 | |
| 45 | The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI. |
| 46 | Files in the DOCUMENT_ROOT are accessed via URLs like this: |
| 47 | |
| @@ -160,11 +160,11 @@ | |
| 160 | can be found at links like these: |
| 161 | |
| 162 | * [https://fossil-scm.org/home/test_env] |
| 163 | * [https://sqlite.org/src/ext/checklist/top/env] |
| 164 | |
| 165 | In addition to the standard CGI environment variables listed above, |
| 166 | Fossil adds the following: |
| 167 | |
| 168 | * FOSSIL_CAPABILITIES |
| 169 | * FOSSIL_NONCE |
| 170 | * FOSSIL_REPOSITORY |
| @@ -171,11 +171,11 @@ | |
| 171 | * FOSSIL_URI |
| 172 | * FOSSIL_USER |
| 173 | |
| 174 | The FOSSIL_USER string is the name of the logged-in user. This variable |
| 175 | is missing or is an empty string if the user is not logged in. The |
| 176 | FOSSIL_CAPABILITIES string is a list of |
| 177 | [./caps/ref.html|Fossil capabilities] that |
| 178 | indicate what permissions the user has on the Fossil repository. |
| 179 | The FOSSIL_REPOSITORY environment variable gives the filename of the |
| 180 | Fossil repository that is running. The FOSSIL_URI variable shows the |
| 181 | prefix of the REQUEST_URI that is the Fossil CGI script, or is an |
| @@ -192,11 +192,11 @@ | |
| 192 | this happens. |
| 193 | |
| 194 | If the CGI output is one of the forms for which Fossil inserts its own |
| 195 | header and footer, then the inserted header will include a |
| 196 | Content Security Policy (CSP) restriction on the use of javascript within |
| 197 | the webpage. Any <script>...</script> elements within the |
| 198 | CGI output must include a nonce or else they will be suppressed by the |
| 199 | web browser. The FOSSIL_NONCE variable contains the value of that nonce. |
| 200 | So, in other words, to get javascript to work, it must be enclosed in: |
| 201 | |
| 202 | <blockquote><verbatim> |
| @@ -233,11 +233,11 @@ | |
| 233 | Those that Fossil does not understand are simply relayed back to up the |
| 234 | line to the requester. |
| 235 | |
| 236 | Fossil takes special action with some content types. If the Content-Type |
| 237 | is "text/x-fossil-wiki" or "text/x-markdown" then Fossil |
| 238 | converts the content from [/wiki_rules|Fossil-Wiki] or |
| 239 | [/md_rules|Markdown] into HTML, adding its |
| 240 | own header and footer text according to the repository skin. Content |
| 241 | of type "text/html" is normally passed straight through |
| 242 | unchanged. However, if the text/html content is of the form: |
| 243 | |
| @@ -246,11 +246,11 @@ | |
| 246 | ... HTML content there ... |
| 247 | </div> |
| 248 | </verbatim></blockquote> |
| 249 | |
| 250 | In other words, if the outer-most markup of the HTML is a <div> |
| 251 | element with a single class of "fossil-doc", |
| 252 | then Fossil will adds its own header and footer to the HTML. The |
| 253 | page title contained in the added header will be extracted from the |
| 254 | "data-title" attribute. |
| 255 | |
| 256 | Except for the three cases noted above, Fossil makes no changes or |
| @@ -291,13 +291,13 @@ | |
| 291 | have been adjusted accordingly and that all resources needed by the |
| 292 | CGI program are available within the chroot jail. |
| 293 | |
| 294 | If anything goes wrong while trying to process an /ext page, Fossil |
| 295 | returns a 404 Not Found error with no details. However, if the requester |
| 296 | is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability |
| 297 | then additional diagnostic information may be included in the output. |
| 298 | |
| 299 | If the /ext page has a "fossil-ext-debug=1" query parameter and if |
| 300 | the requester is logged in as a user with Debug privilege, then the |
| 301 | CGI output is returned verbatim, as text/plain and with the original |
| 302 | header intact. This is useful for diagnosing problems with the |
| 303 | CGI script. |
| 304 |
| --- www/serverext.wiki | |
| +++ www/serverext.wiki | |
| @@ -7,18 +7,18 @@ | |
| 7 | extensions to that server. These extensions work like |
| 8 | any other CGI program, except that they also have access to the Fossil |
| 9 | login information and can (optionally) leverage the "skins" of Fossil |
| 10 | so that they appear to be more tightly integrated into the project. |
| 11 | |
| 12 | An example of where this is useful is the |
| 13 | [https://sqlite.org/src/ext/checklist|checklist application] on |
| 14 | the [https://sqlite.org/|SQLite] project. The checklist |
| 15 | helps the SQLite developers track which release tests have passed, |
| 16 | or failed, or are still to be done. The checklist program began as a |
| 17 | stand-alone CGI which kept its own private user database and implemented |
| 18 | its own permissions and login system and provided its own CSS. By |
| 19 | converting checklist into a Fossil extension, the same login that works |
| 20 | for the [https://sqlite.org/src|main SQLite source repository] also works |
| 21 | for the checklist. Permission to change elements of the checklist |
| 22 | is tied on permission to check-in to the main source repository. And |
| 23 | the standard Fossil header menu and footer appear on each page of |
| 24 | the checklist. |
| @@ -26,22 +26,22 @@ | |
| 26 | <h2>2.0 How It Works</h2> |
| 27 | |
| 28 | CGI Extensions are disabled by default. |
| 29 | An administrator activates the CGI extension mechanism by specifying |
| 30 | an "Extension Root Directory" or "extroot" as part of the server setup. |
| 31 | If the Fossil server is itself run as |
| 32 | [./server/any/cgi.md|CGI], then add a line to the |
| 33 | [./cgi.wiki#extroot|CGI script file] that says: |
| 34 | |
| 35 | <blockquote><pre> |
| 36 | extroot: <i>DIRECTORY</i> |
| 37 | </pre></blockquote> |
| 38 | |
| 39 | Or, if the Fossil server is being run using the |
| 40 | "[./server/any/none.md|fossil server]" o |
| 41 | "[./server/any/none.md|fossil ui]" or |
| 42 | "[./server/any/inetd.md|fossil http]" commands, then add an extra |
| 43 | "--extroot <i>DIRECTORY</i>" option to that command. |
| 44 | |
| 45 | The <i>DIRECTORY</i> is the DOCUMENT_ROOT for the CGI. |
| 46 | Files in the DOCUMENT_ROOT are accessed via URLs like this: |
| 47 | |
| @@ -160,11 +160,11 @@ | |
| 160 | can be found at links like these: |
| 161 | |
| 162 | * [https://fossil-scm.org/home/test_env] |
| 163 | * [https://sqlite.org/src/ext/checklist/top/env] |
| 164 | |
| 165 | In addition to the standard CGI environment variables listed above, |
| 166 | Fossil adds the following: |
| 167 | |
| 168 | * FOSSIL_CAPABILITIES |
| 169 | * FOSSIL_NONCE |
| 170 | * FOSSIL_REPOSITORY |
| @@ -171,11 +171,11 @@ | |
| 171 | * FOSSIL_URI |
| 172 | * FOSSIL_USER |
| 173 | |
| 174 | The FOSSIL_USER string is the name of the logged-in user. This variable |
| 175 | is missing or is an empty string if the user is not logged in. The |
| 176 | FOSSIL_CAPABILITIES string is a list of |
| 177 | [./caps/ref.html|Fossil capabilities] that |
| 178 | indicate what permissions the user has on the Fossil repository. |
| 179 | The FOSSIL_REPOSITORY environment variable gives the filename of the |
| 180 | Fossil repository that is running. The FOSSIL_URI variable shows the |
| 181 | prefix of the REQUEST_URI that is the Fossil CGI script, or is an |
| @@ -192,11 +192,11 @@ | |
| 192 | this happens. |
| 193 | |
| 194 | If the CGI output is one of the forms for which Fossil inserts its own |
| 195 | header and footer, then the inserted header will include a |
| 196 | Content Security Policy (CSP) restriction on the use of javascript within |
| 197 | the webpage. Any <script>...</script> elements within the |
| 198 | CGI output must include a nonce or else they will be suppressed by the |
| 199 | web browser. The FOSSIL_NONCE variable contains the value of that nonce. |
| 200 | So, in other words, to get javascript to work, it must be enclosed in: |
| 201 | |
| 202 | <blockquote><verbatim> |
| @@ -233,11 +233,11 @@ | |
| 233 | Those that Fossil does not understand are simply relayed back to up the |
| 234 | line to the requester. |
| 235 | |
| 236 | Fossil takes special action with some content types. If the Content-Type |
| 237 | is "text/x-fossil-wiki" or "text/x-markdown" then Fossil |
| 238 | converts the content from [/wiki_rules|Fossil-Wiki] or |
| 239 | [/md_rules|Markdown] into HTML, adding its |
| 240 | own header and footer text according to the repository skin. Content |
| 241 | of type "text/html" is normally passed straight through |
| 242 | unchanged. However, if the text/html content is of the form: |
| 243 | |
| @@ -246,11 +246,11 @@ | |
| 246 | ... HTML content there ... |
| 247 | </div> |
| 248 | </verbatim></blockquote> |
| 249 | |
| 250 | In other words, if the outer-most markup of the HTML is a <div> |
| 251 | element with a single class of "fossil-doc", |
| 252 | then Fossil will adds its own header and footer to the HTML. The |
| 253 | page title contained in the added header will be extracted from the |
| 254 | "data-title" attribute. |
| 255 | |
| 256 | Except for the three cases noted above, Fossil makes no changes or |
| @@ -291,13 +291,13 @@ | |
| 291 | have been adjusted accordingly and that all resources needed by the |
| 292 | CGI program are available within the chroot jail. |
| 293 | |
| 294 | If anything goes wrong while trying to process an /ext page, Fossil |
| 295 | returns a 404 Not Found error with no details. However, if the requester |
| 296 | is logged in as a user that has <b>[./caps/ref.html#D | Debug]</b> capability |
| 297 | then additional diagnostic information may be included in the output. |
| 298 | |
| 299 | If the /ext page has a "fossil-ext-debug=1" query parameter and if |
| 300 | the requester is logged in as a user with Debug privilege, then the |
| 301 | CGI output is returned verbatim, as text/plain and with the original |
| 302 | header intact. This is useful for diagnosing problems with the |
| 303 | CGI script. |
| 304 |
+1
-1
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -34,11 +34,11 @@ | ||
| 34 | 34 | |
| 35 | 35 | <a name="crdt"></a> |
| 36 | 36 | <h3>1.1 Conflict-Free Replicated Datatypes</h3> |
| 37 | 37 | |
| 38 | 38 | <p>The "bag of artifacts" data model used by Fossil |
| 39 | -Fossil is apparently an implementation of a particular | |
| 39 | +Fossil is apparently an implementation of a particular | |
| 40 | 40 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|Conflict-Free Replicated |
| 41 | 41 | Datatype (CRDT)] |
| 42 | 42 | called a "G-Set" or "Grow-only Set". |
| 43 | 43 | The academic literature on CRDTs only began to appear in about 2011, and |
| 44 | 44 | Fossil predates that research by at least 4 years. But it is nice to know |
| 45 | 45 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -34,11 +34,11 @@ | |
| 34 | |
| 35 | <a name="crdt"></a> |
| 36 | <h3>1.1 Conflict-Free Replicated Datatypes</h3> |
| 37 | |
| 38 | <p>The "bag of artifacts" data model used by Fossil |
| 39 | Fossil is apparently an implementation of a particular |
| 40 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|Conflict-Free Replicated |
| 41 | Datatype (CRDT)] |
| 42 | called a "G-Set" or "Grow-only Set". |
| 43 | The academic literature on CRDTs only began to appear in about 2011, and |
| 44 | Fossil predates that research by at least 4 years. But it is nice to know |
| 45 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -34,11 +34,11 @@ | |
| 34 | |
| 35 | <a name="crdt"></a> |
| 36 | <h3>1.1 Conflict-Free Replicated Datatypes</h3> |
| 37 | |
| 38 | <p>The "bag of artifacts" data model used by Fossil |
| 39 | Fossil is apparently an implementation of a particular |
| 40 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|Conflict-Free Replicated |
| 41 | Datatype (CRDT)] |
| 42 | called a "G-Set" or "Grow-only Set". |
| 43 | The academic literature on CRDTs only began to appear in about 2011, and |
| 44 | Fossil predates that research by at least 4 years. But it is nice to know |
| 45 |
+1
-1
| --- www/tls-nginx.md | ||
| +++ www/tls-nginx.md | ||
| @@ -375,11 +375,11 @@ | ||
| 375 | 375 | causes Fossil to remember the new URL automatically the first time it’s |
| 376 | 376 | redirected to it. All you need to do to switch your syncs to HTTPS is: |
| 377 | 377 | |
| 378 | 378 | $ cd ~/path/to/checkout |
| 379 | 379 | $ fossil sync |
| 380 | - | |
| 380 | + | |
| 381 | 381 | |
| 382 | 382 | ## Step 7: Renewing Automatically |
| 383 | 383 | |
| 384 | 384 | Now that the configuration is solid, you can renew the LE cert with the |
| 385 | 385 | `certbot` command from above without the `--dry-run` flag plus a restart |
| 386 | 386 |
| --- www/tls-nginx.md | |
| +++ www/tls-nginx.md | |
| @@ -375,11 +375,11 @@ | |
| 375 | causes Fossil to remember the new URL automatically the first time it’s |
| 376 | redirected to it. All you need to do to switch your syncs to HTTPS is: |
| 377 | |
| 378 | $ cd ~/path/to/checkout |
| 379 | $ fossil sync |
| 380 | |
| 381 | |
| 382 | ## Step 7: Renewing Automatically |
| 383 | |
| 384 | Now that the configuration is solid, you can renew the LE cert with the |
| 385 | `certbot` command from above without the `--dry-run` flag plus a restart |
| 386 |
| --- www/tls-nginx.md | |
| +++ www/tls-nginx.md | |
| @@ -375,11 +375,11 @@ | |
| 375 | causes Fossil to remember the new URL automatically the first time it’s |
| 376 | redirected to it. All you need to do to switch your syncs to HTTPS is: |
| 377 | |
| 378 | $ cd ~/path/to/checkout |
| 379 | $ fossil sync |
| 380 | |
| 381 | |
| 382 | ## Step 7: Renewing Automatically |
| 383 | |
| 384 | Now that the configuration is solid, you can renew the LE cert with the |
| 385 | `certbot` command from above without the `--dry-run` flag plus a restart |
| 386 |