Fossil SCM
Added three new block-element classes to the skin to replace use of "blockquote" with semantic alternatives: * "indent" for cases where the only purpose was to indent things * "blockquote" where you want an actual block quote in a wiki doc and thus can't use a "blockquote" element due to the historical misuse of this tag, preventing us from doing the same for it as we do for MD * "sidebar" when the reason you wanted an indented paragraph was to create a sidebar; this is styled much like a blockquote in MD (or the new "blockquote" class in wiki docs) but floats to the right. Using all three of these in the remaining www/ docs that still used explicit "blockquote" tags. (If you're wondering why the prior commit claims to have dealt with all of these tags when this commit belies that, it's because this work was done en masse, then split up into two related commits to keep the commit messages more on-point. It was easier to commit these two chunks of work in this order. It would have required a complicated dance with the stash to commit them in the more logical order.)
Commit
56c7c2cb1393301f5a26e5e3019176039227dedf6a8a8669760bc4aff9f8fb3b
Parent
54977e1413a6d59…
8 files changed
+25
-2
+27
-28
+20
-20
+3
-3
+21
-21
+17
-21
+6
-6
+8
-12
+25
-2
| --- skins/default/css.txt | ||
| +++ skins/default/css.txt | ||
| @@ -185,19 +185,33 @@ | ||
| 185 | 185 | * differently, and /doc on *.html files works yet a third way. These |
| 186 | 186 | * rules are carefully written to capture these docs and no other use of |
| 187 | 187 | * MD/wiki/HTML. Adjust with care! |
| 188 | 188 | */ |
| 189 | 189 | |
| 190 | -.markdown blockquote { | |
| 190 | +.markdown blockquote, .sidebar, p.blockquote { | |
| 191 | 191 | /* Style it as a proper blockquote for MD only. Unlike the indent |
| 192 | 192 | * rule, this applies everywhere, including the forum, tickets… */ |
| 193 | 193 | background-color: rgba(65, 131, 196, 0.1); |
| 194 | 194 | border-left: 3px solid #4183c4; |
| 195 | 195 | padding: 0.1em 1em; |
| 196 | 196 | } |
| 197 | +.sidebar { | |
| 198 | + float: right; | |
| 199 | + font-size: 0.9em; | |
| 200 | + max-width: 33%; | |
| 201 | +} | |
| 202 | +div.sidebar { | |
| 203 | + margin-left: 1em; /* don't run wraparound text right up to our border */ | |
| 204 | + padding: 1em; /* no p wrapper inside to get extra padding from */ | |
| 205 | +} | |
| 206 | +div.sidebar:not(.no-label):before { | |
| 207 | + content: "Sidebar: "; | |
| 208 | + font-weight: bold; | |
| 209 | +} | |
| 197 | 210 | |
| 198 | 211 | .doc > .content dd, .content dt, |
| 212 | +.doc > .content div, | |
| 199 | 213 | .doc > .content li, |
| 200 | 214 | .doc > .content p, |
| 201 | 215 | .doc > .content table |
| 202 | 216 | { |
| 203 | 217 | line-height: 1.4em; |
| @@ -403,11 +417,11 @@ | ||
| 403 | 417 | * |
| 404 | 418 | * .artifact, .dir, .doc { |
| 405 | 419 | * > .content, // wiki docs have no inner container |
| 406 | 420 | * > .content > .fossil-doc, // container for HTML embedded docs |
| 407 | 421 | * > .content > markdown { // ditto for MD outside forum, tickets… |
| 408 | - * > p, > ol, > ul, > table { | |
| 422 | + * > div, > p, > ol, > ul, > table { | |
| 409 | 423 | * margin-left: 50pt; margin-right: 50pt; |
| 410 | 424 | * } |
| 411 | 425 | * } |
| 412 | 426 | * } |
| 413 | 427 | * |
| @@ -489,10 +503,11 @@ | ||
| 489 | 503 | div.pikchr-wrapper.center:not(.source) { |
| 490 | 504 | margin-left: 0; |
| 491 | 505 | } |
| 492 | 506 | |
| 493 | 507 | /* Special treatment for backward compatibility. */ |
| 508 | + .indent, /* clean alternative to misusing <blockquote> */ | |
| 494 | 509 | .artifact > .content > blockquote:not(.file-content), |
| 495 | 510 | .dir > .content > blockquote, |
| 496 | 511 | .doc > .content > blockquote { |
| 497 | 512 | /* We must apply extra indent relative to "p" since Fossil's wiki |
| 498 | 513 | * generator misuses the blockquote tag against HTML and MD norms |
| @@ -506,6 +521,14 @@ | ||
| 506 | 521 | /* Fossil MD didn't inherit that bug; its HTML generator emits |
| 507 | 522 | * blockquote tags only for _block quotes_! A moderate indent |
| 508 | 523 | * suffices due to the visual styling applied above. */ |
| 509 | 524 | margin-left: 60pt; |
| 510 | 525 | } |
| 526 | + | |
| 527 | + /* Alternative to BLOCK.indent when wrapped in something that is | |
| 528 | + * itself indented. The value is the delta between p and blockquote | |
| 529 | + * above, expressed as padding instead of margin so it adds to the | |
| 530 | + * outer margin instead of forcing the browser into picking one. */ | |
| 531 | + .local-indent { | |
| 532 | + padding-left: 30pt; | |
| 533 | + } | |
| 511 | 534 | } |
| 512 | 535 |
| --- skins/default/css.txt | |
| +++ skins/default/css.txt | |
| @@ -185,19 +185,33 @@ | |
| 185 | * differently, and /doc on *.html files works yet a third way. These |
| 186 | * rules are carefully written to capture these docs and no other use of |
| 187 | * MD/wiki/HTML. Adjust with care! |
| 188 | */ |
| 189 | |
| 190 | .markdown blockquote { |
| 191 | /* Style it as a proper blockquote for MD only. Unlike the indent |
| 192 | * rule, this applies everywhere, including the forum, tickets… */ |
| 193 | background-color: rgba(65, 131, 196, 0.1); |
| 194 | border-left: 3px solid #4183c4; |
| 195 | padding: 0.1em 1em; |
| 196 | } |
| 197 | |
| 198 | .doc > .content dd, .content dt, |
| 199 | .doc > .content li, |
| 200 | .doc > .content p, |
| 201 | .doc > .content table |
| 202 | { |
| 203 | line-height: 1.4em; |
| @@ -403,11 +417,11 @@ | |
| 403 | * |
| 404 | * .artifact, .dir, .doc { |
| 405 | * > .content, // wiki docs have no inner container |
| 406 | * > .content > .fossil-doc, // container for HTML embedded docs |
| 407 | * > .content > markdown { // ditto for MD outside forum, tickets… |
| 408 | * > p, > ol, > ul, > table { |
| 409 | * margin-left: 50pt; margin-right: 50pt; |
| 410 | * } |
| 411 | * } |
| 412 | * } |
| 413 | * |
| @@ -489,10 +503,11 @@ | |
| 489 | div.pikchr-wrapper.center:not(.source) { |
| 490 | margin-left: 0; |
| 491 | } |
| 492 | |
| 493 | /* Special treatment for backward compatibility. */ |
| 494 | .artifact > .content > blockquote:not(.file-content), |
| 495 | .dir > .content > blockquote, |
| 496 | .doc > .content > blockquote { |
| 497 | /* We must apply extra indent relative to "p" since Fossil's wiki |
| 498 | * generator misuses the blockquote tag against HTML and MD norms |
| @@ -506,6 +521,14 @@ | |
| 506 | /* Fossil MD didn't inherit that bug; its HTML generator emits |
| 507 | * blockquote tags only for _block quotes_! A moderate indent |
| 508 | * suffices due to the visual styling applied above. */ |
| 509 | margin-left: 60pt; |
| 510 | } |
| 511 | } |
| 512 |
| --- skins/default/css.txt | |
| +++ skins/default/css.txt | |
| @@ -185,19 +185,33 @@ | |
| 185 | * differently, and /doc on *.html files works yet a third way. These |
| 186 | * rules are carefully written to capture these docs and no other use of |
| 187 | * MD/wiki/HTML. Adjust with care! |
| 188 | */ |
| 189 | |
| 190 | .markdown blockquote, .sidebar, p.blockquote { |
| 191 | /* Style it as a proper blockquote for MD only. Unlike the indent |
| 192 | * rule, this applies everywhere, including the forum, tickets… */ |
| 193 | background-color: rgba(65, 131, 196, 0.1); |
| 194 | border-left: 3px solid #4183c4; |
| 195 | padding: 0.1em 1em; |
| 196 | } |
| 197 | .sidebar { |
| 198 | float: right; |
| 199 | font-size: 0.9em; |
| 200 | max-width: 33%; |
| 201 | } |
| 202 | div.sidebar { |
| 203 | margin-left: 1em; /* don't run wraparound text right up to our border */ |
| 204 | padding: 1em; /* no p wrapper inside to get extra padding from */ |
| 205 | } |
| 206 | div.sidebar:not(.no-label):before { |
| 207 | content: "Sidebar: "; |
| 208 | font-weight: bold; |
| 209 | } |
| 210 | |
| 211 | .doc > .content dd, .content dt, |
| 212 | .doc > .content div, |
| 213 | .doc > .content li, |
| 214 | .doc > .content p, |
| 215 | .doc > .content table |
| 216 | { |
| 217 | line-height: 1.4em; |
| @@ -403,11 +417,11 @@ | |
| 417 | * |
| 418 | * .artifact, .dir, .doc { |
| 419 | * > .content, // wiki docs have no inner container |
| 420 | * > .content > .fossil-doc, // container for HTML embedded docs |
| 421 | * > .content > markdown { // ditto for MD outside forum, tickets… |
| 422 | * > div, > p, > ol, > ul, > table { |
| 423 | * margin-left: 50pt; margin-right: 50pt; |
| 424 | * } |
| 425 | * } |
| 426 | * } |
| 427 | * |
| @@ -489,10 +503,11 @@ | |
| 503 | div.pikchr-wrapper.center:not(.source) { |
| 504 | margin-left: 0; |
| 505 | } |
| 506 | |
| 507 | /* Special treatment for backward compatibility. */ |
| 508 | .indent, /* clean alternative to misusing <blockquote> */ |
| 509 | .artifact > .content > blockquote:not(.file-content), |
| 510 | .dir > .content > blockquote, |
| 511 | .doc > .content > blockquote { |
| 512 | /* We must apply extra indent relative to "p" since Fossil's wiki |
| 513 | * generator misuses the blockquote tag against HTML and MD norms |
| @@ -506,6 +521,14 @@ | |
| 521 | /* Fossil MD didn't inherit that bug; its HTML generator emits |
| 522 | * blockquote tags only for _block quotes_! A moderate indent |
| 523 | * suffices due to the visual styling applied above. */ |
| 524 | margin-left: 60pt; |
| 525 | } |
| 526 | |
| 527 | /* Alternative to BLOCK.indent when wrapped in something that is |
| 528 | * itself indented. The value is the delta between p and blockquote |
| 529 | * above, expressed as padding instead of margin so it adds to the |
| 530 | * outer margin instead of forcing the browser into picking one. */ |
| 531 | .local-indent { |
| 532 | padding-left: 30pt; |
| 533 | } |
| 534 | } |
| 535 |
+27
-28
| --- www/build.wiki | ||
| +++ www/build.wiki | ||
| @@ -438,23 +438,24 @@ | ||
| 438 | 438 | |
| 439 | 439 | For instructions on keeping the SDK up to date, see: |
| 440 | 440 | |
| 441 | 441 | [https://emscripten.org/docs/tools_reference/emsdk.html] |
| 442 | 442 | |
| 443 | - Sidebar: getting Emscripten up and running is trivial and | |
| 444 | - painless, at least on Linux systems, but the installer downloads | |
| 445 | - many hundreds of megabytes of tools and dependencies, all of which | |
| 446 | - will be installed under the single SDK directory (as opposed to | |
| 447 | - being installed at the system level). It does, however, require | |
| 448 | - that python3 be installed at the system level and it can | |
| 449 | - optionally make use of a system-level cmake for certain tasks | |
| 450 | - unrelated to how fossil uses the SDK. | |
| 443 | +<div class="sidebar">Getting Emscripten up and running is trivial and | |
| 444 | +painless, at least on Linux systems, but the installer downloads | |
| 445 | +many hundreds of megabytes of tools and dependencies, all of which | |
| 446 | +will be installed under the single SDK directory (as opposed to | |
| 447 | +being installed at the system level). It does, however, require | |
| 448 | +that python3 be installed at the system level and it can | |
| 449 | +optionally make use of a system-level cmake for certain tasks | |
| 450 | +unrelated to how fossil uses the SDK.</div> | |
| 451 | 451 | |
| 452 | 452 | After installing the SDK, configure the fossil tree with emsdk |
| 453 | 453 | support: |
| 454 | 454 | |
| 455 | -<pre><code>$ ./configure --with-emsdk=/path/to/emsdk ...other options... | |
| 455 | +<pre><code>$ ./configure --with-emsdk=/path/to/emsdk \ | |
| 456 | + --and-other-options... | |
| 456 | 457 | </code></pre> |
| 457 | 458 | |
| 458 | 459 | If the <tt>--with-emsdk</tt> flag is not provided, the configure |
| 459 | 460 | script will check for the environment variable <tt>EMSDK</tt>, which |
| 460 | 461 | is one of the standard variables the SDK environment uses. If that |
| @@ -480,27 +481,27 @@ | ||
| 480 | 481 | From the top of the source tree, all WASM-related components can be |
| 481 | 482 | built with: |
| 482 | 483 | |
| 483 | 484 | <pre><code>$ make wasm</code></pre> |
| 484 | 485 | |
| 486 | +<div class="sidebar">The file | |
| 487 | +<tt>[/file/extsrc/pikcher-worker.js|extsrc/pikcher-worker.js]</tt> | |
| 488 | +is hand-coded and intended to be loaded as a "Worker" in | |
| 489 | +JavaScript. That file loads the main module and provides an | |
| 490 | +interface via which a main JavaScript thread can communicate with | |
| 491 | +pikchr running in a Worker thread. The file | |
| 492 | +<tt>[/file/src/fossil.page.pikchrshowasm.js|src/fossil.page.pikchrshowasm.js]</tt> | |
| 493 | +implements the [/pikchrshow] app and demonstrates how | |
| 494 | +<tt>pikchr-worker.js</tt> is used.</div> | |
| 495 | + | |
| 485 | 496 | As of this writing, those parts include: |
| 486 | 497 | |
| 487 | 498 | * <tt>extsrc/pikchr.wasm</tt> is a WASM-compiled form of |
| 488 | 499 | <tt>extsrc/pikchr.c</tt>. |
| 489 | 500 | * <tt>extsrc/pikchr.js</tt> is JS/WASM glue code generated by Emscripten |
| 490 | 501 | to give JS code access to the API exported by the WASM file. |
| 491 | 502 | |
| 492 | - Sidebar: The file | |
| 493 | - <tt>[/file/extsrc/pikcher-worker.js|extsrc/pikcher-worker.js]</tt> | |
| 494 | - is hand-coded and intended to be loaded as a "Worker" in | |
| 495 | - JavaScript. That file loads the main module and provides an | |
| 496 | - interface via which a main JavaScript thread can communicate with | |
| 497 | - pikchr running in a Worker thread. The file | |
| 498 | - <tt>[/file/src/fossil.page.pikchrshowasm.js|src/fossil.page.pikchrshowasm.js]</tt> | |
| 499 | - implements the [/pikchrshow] app and demonstrates how | |
| 500 | - <tt>pikchr-worker.js</tt> is used. | |
| 501 | - | |
| 502 | 503 | When a new version of <tt>extsrc/pikchr.c</tt> is installed, the |
| 503 | 504 | files <tt>pikchr.{js,wasm}</tt> will need to be recompiled to account |
| 504 | 505 | for that. Running <tt>make wasm</tt> will, if the build is set up for |
| 505 | 506 | the emsdk, recompile those: |
| 506 | 507 | |
| @@ -509,19 +510,17 @@ | ||
| 509 | 510 | $ ls -la extsrc/pikchr.{js,wasm} |
| 510 | 511 | -rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js |
| 511 | 512 | -rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm |
| 512 | 513 | </code></pre> |
| 513 | 514 | |
| 514 | -<blockquote>Sidebar: if that fails with a message along the lines of: | |
| 515 | - | |
| 516 | -<pre><code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but got `<class 'str'>`</code></pre> | |
| 517 | - | |
| 518 | -then the emcc being invoked is too old: emcc changed the format of | |
| 519 | -list-type arguments at some point. The required minimum version is | |
| 520 | -unknown, but any SDK version from May 2022 or later "should" (as of | |
| 521 | -this writing) suffice. Any older version may or may not work. | |
| 522 | -</blockquote> | |
| 515 | +<div class="sidebar">If that fails with a message along the lines of | |
| 516 | +“<code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but | |
| 517 | +got `<class 'str'>`</code>” then the emcc being invoked is too old: emcc | |
| 518 | +changed the format of list-type arguments at some point. The required | |
| 519 | +minimum version is unknown, but any SDK version from May 2022 or later | |
| 520 | +"should" (as of this writing) suffice. Any older version may or may not | |
| 521 | +work.</div> | |
| 523 | 522 | |
| 524 | 523 | After that succeeds, we need to run the normal build so that those |
| 525 | 524 | generated files can be compiled in to the fossil binary, accessible |
| 526 | 525 | via the [/help?cmd=/builtin|/builtin page]: |
| 527 | 526 | |
| 528 | 527 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -438,23 +438,24 @@ | |
| 438 | |
| 439 | For instructions on keeping the SDK up to date, see: |
| 440 | |
| 441 | [https://emscripten.org/docs/tools_reference/emsdk.html] |
| 442 | |
| 443 | Sidebar: getting Emscripten up and running is trivial and |
| 444 | painless, at least on Linux systems, but the installer downloads |
| 445 | many hundreds of megabytes of tools and dependencies, all of which |
| 446 | will be installed under the single SDK directory (as opposed to |
| 447 | being installed at the system level). It does, however, require |
| 448 | that python3 be installed at the system level and it can |
| 449 | optionally make use of a system-level cmake for certain tasks |
| 450 | unrelated to how fossil uses the SDK. |
| 451 | |
| 452 | After installing the SDK, configure the fossil tree with emsdk |
| 453 | support: |
| 454 | |
| 455 | <pre><code>$ ./configure --with-emsdk=/path/to/emsdk ...other options... |
| 456 | </code></pre> |
| 457 | |
| 458 | If the <tt>--with-emsdk</tt> flag is not provided, the configure |
| 459 | script will check for the environment variable <tt>EMSDK</tt>, which |
| 460 | is one of the standard variables the SDK environment uses. If that |
| @@ -480,27 +481,27 @@ | |
| 480 | From the top of the source tree, all WASM-related components can be |
| 481 | built with: |
| 482 | |
| 483 | <pre><code>$ make wasm</code></pre> |
| 484 | |
| 485 | As of this writing, those parts include: |
| 486 | |
| 487 | * <tt>extsrc/pikchr.wasm</tt> is a WASM-compiled form of |
| 488 | <tt>extsrc/pikchr.c</tt>. |
| 489 | * <tt>extsrc/pikchr.js</tt> is JS/WASM glue code generated by Emscripten |
| 490 | to give JS code access to the API exported by the WASM file. |
| 491 | |
| 492 | Sidebar: The file |
| 493 | <tt>[/file/extsrc/pikcher-worker.js|extsrc/pikcher-worker.js]</tt> |
| 494 | is hand-coded and intended to be loaded as a "Worker" in |
| 495 | JavaScript. That file loads the main module and provides an |
| 496 | interface via which a main JavaScript thread can communicate with |
| 497 | pikchr running in a Worker thread. The file |
| 498 | <tt>[/file/src/fossil.page.pikchrshowasm.js|src/fossil.page.pikchrshowasm.js]</tt> |
| 499 | implements the [/pikchrshow] app and demonstrates how |
| 500 | <tt>pikchr-worker.js</tt> is used. |
| 501 | |
| 502 | When a new version of <tt>extsrc/pikchr.c</tt> is installed, the |
| 503 | files <tt>pikchr.{js,wasm}</tt> will need to be recompiled to account |
| 504 | for that. Running <tt>make wasm</tt> will, if the build is set up for |
| 505 | the emsdk, recompile those: |
| 506 | |
| @@ -509,19 +510,17 @@ | |
| 509 | $ ls -la extsrc/pikchr.{js,wasm} |
| 510 | -rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js |
| 511 | -rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm |
| 512 | </code></pre> |
| 513 | |
| 514 | <blockquote>Sidebar: if that fails with a message along the lines of: |
| 515 | |
| 516 | <pre><code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but got `<class 'str'>`</code></pre> |
| 517 | |
| 518 | then the emcc being invoked is too old: emcc changed the format of |
| 519 | list-type arguments at some point. The required minimum version is |
| 520 | unknown, but any SDK version from May 2022 or later "should" (as of |
| 521 | this writing) suffice. Any older version may or may not work. |
| 522 | </blockquote> |
| 523 | |
| 524 | After that succeeds, we need to run the normal build so that those |
| 525 | generated files can be compiled in to the fossil binary, accessible |
| 526 | via the [/help?cmd=/builtin|/builtin page]: |
| 527 | |
| 528 |
| --- www/build.wiki | |
| +++ www/build.wiki | |
| @@ -438,23 +438,24 @@ | |
| 438 | |
| 439 | For instructions on keeping the SDK up to date, see: |
| 440 | |
| 441 | [https://emscripten.org/docs/tools_reference/emsdk.html] |
| 442 | |
| 443 | <div class="sidebar">Getting Emscripten up and running is trivial and |
| 444 | painless, at least on Linux systems, but the installer downloads |
| 445 | many hundreds of megabytes of tools and dependencies, all of which |
| 446 | will be installed under the single SDK directory (as opposed to |
| 447 | being installed at the system level). It does, however, require |
| 448 | that python3 be installed at the system level and it can |
| 449 | optionally make use of a system-level cmake for certain tasks |
| 450 | unrelated to how fossil uses the SDK.</div> |
| 451 | |
| 452 | After installing the SDK, configure the fossil tree with emsdk |
| 453 | support: |
| 454 | |
| 455 | <pre><code>$ ./configure --with-emsdk=/path/to/emsdk \ |
| 456 | --and-other-options... |
| 457 | </code></pre> |
| 458 | |
| 459 | If the <tt>--with-emsdk</tt> flag is not provided, the configure |
| 460 | script will check for the environment variable <tt>EMSDK</tt>, which |
| 461 | is one of the standard variables the SDK environment uses. If that |
| @@ -480,27 +481,27 @@ | |
| 481 | From the top of the source tree, all WASM-related components can be |
| 482 | built with: |
| 483 | |
| 484 | <pre><code>$ make wasm</code></pre> |
| 485 | |
| 486 | <div class="sidebar">The file |
| 487 | <tt>[/file/extsrc/pikcher-worker.js|extsrc/pikcher-worker.js]</tt> |
| 488 | is hand-coded and intended to be loaded as a "Worker" in |
| 489 | JavaScript. That file loads the main module and provides an |
| 490 | interface via which a main JavaScript thread can communicate with |
| 491 | pikchr running in a Worker thread. The file |
| 492 | <tt>[/file/src/fossil.page.pikchrshowasm.js|src/fossil.page.pikchrshowasm.js]</tt> |
| 493 | implements the [/pikchrshow] app and demonstrates how |
| 494 | <tt>pikchr-worker.js</tt> is used.</div> |
| 495 | |
| 496 | As of this writing, those parts include: |
| 497 | |
| 498 | * <tt>extsrc/pikchr.wasm</tt> is a WASM-compiled form of |
| 499 | <tt>extsrc/pikchr.c</tt>. |
| 500 | * <tt>extsrc/pikchr.js</tt> is JS/WASM glue code generated by Emscripten |
| 501 | to give JS code access to the API exported by the WASM file. |
| 502 | |
| 503 | When a new version of <tt>extsrc/pikchr.c</tt> is installed, the |
| 504 | files <tt>pikchr.{js,wasm}</tt> will need to be recompiled to account |
| 505 | for that. Running <tt>make wasm</tt> will, if the build is set up for |
| 506 | the emsdk, recompile those: |
| 507 | |
| @@ -509,19 +510,17 @@ | |
| 510 | $ ls -la extsrc/pikchr.{js,wasm} |
| 511 | -rw-rw-r-- 1 stephan stephan 17263 Jun 8 03:59 extsrc/pikchr.js |
| 512 | -rw-rw-r-- 1 stephan stephan 97578 Jun 8 03:59 extsrc/pikchr.wasm |
| 513 | </code></pre> |
| 514 | |
| 515 | <div class="sidebar">If that fails with a message along the lines of |
| 516 | “<code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but |
| 517 | got `<class 'str'>`</code>” then the emcc being invoked is too old: emcc |
| 518 | changed the format of list-type arguments at some point. The required |
| 519 | minimum version is unknown, but any SDK version from May 2022 or later |
| 520 | "should" (as of this writing) suffice. Any older version may or may not |
| 521 | work.</div> |
| 522 | |
| 523 | After that succeeds, we need to run the normal build so that those |
| 524 | generated files can be compiled in to the fossil binary, accessible |
| 525 | via the [/help?cmd=/builtin|/builtin page]: |
| 526 | |
| 527 |
+20
-20
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -107,11 +107,11 @@ | ||
| 107 | 107 | the check-in was created, and any check-in comments associated |
| 108 | 108 | with the check-in. |
| 109 | 109 | |
| 110 | 110 | Allowed cards in the manifest are as follows: |
| 111 | 111 | |
| 112 | -<blockquote> | |
| 112 | +<p class="indent"> | |
| 113 | 113 | <b>B</b> <i>baseline-manifest</i><br> |
| 114 | 114 | <b>C</b> <i>checkin-comment</i><br> |
| 115 | 115 | <b>D</b> <i>time-and-date-stamp</i><br> |
| 116 | 116 | <b>F</b> <i>filename</i> ?<i>hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br> |
| 117 | 117 | <b>N</b> <i>mimetype</i><br> |
| @@ -119,11 +119,11 @@ | ||
| 119 | 119 | <b>Q</b> (<b>+</b>|<b>-</b>)<i>artifact-hash</i> ?<i>artifact-hash</i>?<br> |
| 120 | 120 | <b>R</b> <i>repository-checksum</i><br> |
| 121 | 121 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <b>*</b> ?<i>value</i>?<br> |
| 122 | 122 | <b>U</b> <i>user-login</i><br> |
| 123 | 123 | <b>Z</b> <i>manifest-checksum</i> |
| 124 | -</blockquote> | |
| 124 | +</p> | |
| 125 | 125 | |
| 126 | 126 | A manifest may optionally have a single <b>B</b> card. The <b>B</b> card specifies |
| 127 | 127 | another manifest that serves as the "baseline" for this manifest. A |
| 128 | 128 | manifest that has a <b>B</b> card is called a delta-manifest and a manifest |
| 129 | 129 | that omits the <b>B</b> card is a baseline-manifest. The other manifest |
| @@ -145,14 +145,14 @@ | ||
| 145 | 145 | A manifest must have exactly one <b>D</b> card. The sole argument to |
| 146 | 146 | the <b>D</b> card is a date-time stamp in the ISO8601 format. The |
| 147 | 147 | date and time should be in coordinated universal time (UTC). |
| 148 | 148 | The format one of: |
| 149 | 149 | |
| 150 | -<blockquote> | |
| 150 | +<p class="indent"> | |
| 151 | 151 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><br> |
| 152 | 152 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><b>.</b><i>SSS</i> |
| 153 | -</blockquote> | |
| 153 | +</p> | |
| 154 | 154 | |
| 155 | 155 | A manifest has zero or more <b>F</b> cards. Each <b>F</b> card identifies a file |
| 156 | 156 | that is part of the check-in. There are one, two, three, or four |
| 157 | 157 | arguments. The first argument is the pathname of the file in the |
| 158 | 158 | check-in relative to the root of the project file hierarchy. No ".." |
| @@ -260,14 +260,14 @@ | ||
| 260 | 260 | may be removed from a repository without loss or damage to the |
| 261 | 261 | underlying project code. |
| 262 | 262 | |
| 263 | 263 | Allowed cards in the cluster are as follows: |
| 264 | 264 | |
| 265 | -<blockquote> | |
| 265 | +<p class="indent"> | |
| 266 | 266 | <b>M</b> <i>artifact-id</i><br /> |
| 267 | 267 | <b>Z</b> <i>checksum</i> |
| 268 | -</blockquote> | |
| 268 | +</p> | |
| 269 | 269 | |
| 270 | 270 | A cluster contains one or more <b>M</b> cards followed by a single <b>Z</b> card. |
| 271 | 271 | Each <b>M</b> card has a single argument which is the artifact ID of |
| 272 | 272 | another artifact in the repository. The <b>Z</b> card works exactly like |
| 273 | 273 | the <b>Z</b> card of a manifest. The argument to the <b>Z</b> card is the |
| @@ -281,16 +281,16 @@ | ||
| 281 | 281 | |
| 282 | 282 | Control artifacts are used to assign properties to other artifacts |
| 283 | 283 | within the repository. |
| 284 | 284 | Allowed cards in a control artifact are as follows: |
| 285 | 285 | |
| 286 | -<blockquote> | |
| 286 | +<p class="indent"> | |
| 287 | 287 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 288 | 288 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <i>artifact-id</i> ?<i>value</i>?<br /> |
| 289 | 289 | <b>U</b> <i>user-name</i><br /> |
| 290 | 290 | <b>Z</b> <i>checksum</i><br /> |
| 291 | -</blockquote> | |
| 291 | +</p> | |
| 292 | 292 | |
| 293 | 293 | A control artifact must have one <b>D</b> card, one <b>U</b> card, one <b>Z</b> card and |
| 294 | 294 | one or more <b>T</b> cards. No other cards or other text is |
| 295 | 295 | allowed in a control artifact. Control artifacts might be PGP |
| 296 | 296 | clearsigned. |
| @@ -335,20 +335,20 @@ | ||
| 335 | 335 | A wiki artifact defines a single version of a |
| 336 | 336 | single wiki page. |
| 337 | 337 | Wiki artifacts accept |
| 338 | 338 | the following card types: |
| 339 | 339 | |
| 340 | -<blockquote> | |
| 340 | +<p class="indent"> | |
| 341 | 341 | <b>C</b> <i>change-comment</i><br> |
| 342 | 342 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 343 | 343 | <b>L</b> <i>wiki-title</i><br /> |
| 344 | 344 | <b>N</b> <i>mimetype</i><br /> |
| 345 | 345 | <b>P</b> <i>parent-artifact-id</i>+<br /> |
| 346 | 346 | <b>U</b> <i>user-name</i><br /> |
| 347 | 347 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 348 | 348 | <b>Z</b> <i>checksum</i> |
| 349 | -</blockquote> | |
| 349 | +</p> | |
| 350 | 350 | |
| 351 | 351 | The <b>D</b> card is the date and time when the wiki page was edited. |
| 352 | 352 | The <b>P</b> card specifies the parent wiki pages, if any. The <b>L</b> card |
| 353 | 353 | gives the name of the wiki page. The optional <b>N</b> card specifies |
| 354 | 354 | the mimetype of the wiki text. If the <b>N</b> card is omitted, the |
| @@ -376,17 +376,17 @@ | ||
| 376 | 376 | <h3 id="tktchng">2.5 Ticket Changes</h3> |
| 377 | 377 | |
| 378 | 378 | A ticket-change artifact represents a change to a trouble ticket. |
| 379 | 379 | The following cards are allowed on a ticket change artifact: |
| 380 | 380 | |
| 381 | -<blockquote> | |
| 381 | +<p class="indent"> | |
| 382 | 382 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 383 | 383 | <b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br /> |
| 384 | 384 | <b>K</b> <i>ticket-id</i><br /> |
| 385 | 385 | <b>U</b> <i>user-name</i><br /> |
| 386 | 386 | <b>Z</b> <i>checksum</i> |
| 387 | -</blockquote> | |
| 387 | +</p> | |
| 388 | 388 | |
| 389 | 389 | The <b>D</b> card is the usual date and time stamp and represents the point |
| 390 | 390 | in time when the change was entered. The <b>U</b> card is the login of the |
| 391 | 391 | programmer who entered this change. The <b>Z</b> card is the required checksum over |
| 392 | 392 | the entire artifact. |
| @@ -424,18 +424,18 @@ | ||
| 424 | 424 | attachment (the source artifact) with a ticket or wiki page or |
| 425 | 425 | technical note to which |
| 426 | 426 | the attachment is connected (the target artifact). |
| 427 | 427 | The following cards are allowed on an attachment artifact: |
| 428 | 428 | |
| 429 | -<blockquote> | |
| 429 | +<p class="indent"> | |
| 430 | 430 | <b>A</b> <i>filename target</i> ?<i>source</i>?<br /> |
| 431 | 431 | <b>C</b> <i>comment</i><br /> |
| 432 | 432 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 433 | 433 | <b>N</b> <i>mimetype</i><br /> |
| 434 | 434 | <b>U</b> <i>user-name</i><br /> |
| 435 | 435 | <b>Z</b> <i>checksum</i> |
| 436 | -</blockquote> | |
| 436 | +</p> | |
| 437 | 437 | |
| 438 | 438 | The <b>A</b> card specifies a filename for the attachment in its first argument. |
| 439 | 439 | The second argument to the <b>A</b> card is the name of the wiki page or |
| 440 | 440 | ticket or technical note to which the attachment is connected. The |
| 441 | 441 | third argument is either missing or else it is the lower-case artifact |
| @@ -466,21 +466,21 @@ | ||
| 466 | 466 | (similar to a wiki page) with a point in time. Technotes can be used |
| 467 | 467 | to record project milestones, release notes, blog entries, process |
| 468 | 468 | checkpoints, or news articles. |
| 469 | 469 | The following cards are allowed on an technote artifact: |
| 470 | 470 | |
| 471 | -<blockquote> | |
| 471 | +<p class="indent"> | |
| 472 | 472 | <b>C</b> <i>comment</i><br> |
| 473 | 473 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 474 | 474 | <b>E</b> <i>technote-time</i> <i>technote-id</i><br /> |
| 475 | 475 | <b>N</b> <i>mimetype</i><br /> |
| 476 | 476 | <b>P</b> <i>parent-artifact-id</i>+<br /> |
| 477 | 477 | <b>T</b> <b>+</b><i>tag-name</i> <b>*</b> ?<i>value</i>?<br /> |
| 478 | 478 | <b>U</b> <i>user-name</i><br /> |
| 479 | 479 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 480 | 480 | <b>Z</b> <i>checksum</i> |
| 481 | -</blockquote> | |
| 481 | +</p> | |
| 482 | 482 | |
| 483 | 483 | The <b>C</b> card contains text that is displayed on the timeline for the |
| 484 | 484 | technote. The <b>C</b> card is optional, but there can only be one. |
| 485 | 485 | |
| 486 | 486 | A single <b>D</b> card is required to give the date and time when the |
| @@ -531,21 +531,21 @@ | ||
| 531 | 531 | Forum posts are intended as a mechanism for users and developers to |
| 532 | 532 | discuss a project. Forum posts are like messages on a mailing list. |
| 533 | 533 | |
| 534 | 534 | The following cards are allowed on an forum post artifact: |
| 535 | 535 | |
| 536 | -<blockquote> | |
| 536 | +<p class="indent"> | |
| 537 | 537 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 538 | 538 | <b>G</b> <i>thread-root</i><br /> |
| 539 | 539 | <b>H</b> <i>thread-title</i><br /> |
| 540 | 540 | <b>I</b> <i>in-reply-to</i><br /> |
| 541 | 541 | <b>N</b> <i>mimetype</i><br /> |
| 542 | 542 | <b>P</b> <i>parent-artifact-id</i><br /> |
| 543 | 543 | <b>U</b> <i>user-name</i><br /> |
| 544 | 544 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 545 | 545 | <b>Z</b> <i>checksum</i> |
| 546 | -</blockquote> | |
| 546 | +</p> | |
| 547 | 547 | |
| 548 | 548 | Every forum post must have either one <b>I</b> card and one <b>G</b> card |
| 549 | 549 | or one <b>H</b> card. |
| 550 | 550 | Forum posts are organized into topic threads. The initial |
| 551 | 551 | post for a thread (the root post) has an <b>H</b> card giving the title or |
| @@ -903,15 +903,15 @@ | ||
| 903 | 903 | Both bugs have now been fixed. However, to prevent historical |
| 904 | 904 | Technical Note artifacts that were inserted by users in good faith |
| 905 | 905 | from being rejected by newer Fossil builds, the card ordering |
| 906 | 906 | requirement is relaxed slightly. The actual implementation is this: |
| 907 | 907 | |
| 908 | -<blockquote> | |
| 908 | +<p class=blockquote> | |
| 909 | 909 | "All cards must be in strict lexicographic order, except that the |
| 910 | 910 | N and P cards of a Technical Note artifact are allowed to be |
| 911 | 911 | interchanged." |
| 912 | -</blockquote> | |
| 912 | +</p> | |
| 913 | 913 | |
| 914 | 914 | Future versions of Fossil might strengthen this slightly to only allow |
| 915 | 915 | the out of order N and P cards for Technical Notes entered before |
| 916 | 916 | a certain date. |
| 917 | 917 | |
| 918 | 918 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -107,11 +107,11 @@ | |
| 107 | the check-in was created, and any check-in comments associated |
| 108 | with the check-in. |
| 109 | |
| 110 | Allowed cards in the manifest are as follows: |
| 111 | |
| 112 | <blockquote> |
| 113 | <b>B</b> <i>baseline-manifest</i><br> |
| 114 | <b>C</b> <i>checkin-comment</i><br> |
| 115 | <b>D</b> <i>time-and-date-stamp</i><br> |
| 116 | <b>F</b> <i>filename</i> ?<i>hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br> |
| 117 | <b>N</b> <i>mimetype</i><br> |
| @@ -119,11 +119,11 @@ | |
| 119 | <b>Q</b> (<b>+</b>|<b>-</b>)<i>artifact-hash</i> ?<i>artifact-hash</i>?<br> |
| 120 | <b>R</b> <i>repository-checksum</i><br> |
| 121 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <b>*</b> ?<i>value</i>?<br> |
| 122 | <b>U</b> <i>user-login</i><br> |
| 123 | <b>Z</b> <i>manifest-checksum</i> |
| 124 | </blockquote> |
| 125 | |
| 126 | A manifest may optionally have a single <b>B</b> card. The <b>B</b> card specifies |
| 127 | another manifest that serves as the "baseline" for this manifest. A |
| 128 | manifest that has a <b>B</b> card is called a delta-manifest and a manifest |
| 129 | that omits the <b>B</b> card is a baseline-manifest. The other manifest |
| @@ -145,14 +145,14 @@ | |
| 145 | A manifest must have exactly one <b>D</b> card. The sole argument to |
| 146 | the <b>D</b> card is a date-time stamp in the ISO8601 format. The |
| 147 | date and time should be in coordinated universal time (UTC). |
| 148 | The format one of: |
| 149 | |
| 150 | <blockquote> |
| 151 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><br> |
| 152 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><b>.</b><i>SSS</i> |
| 153 | </blockquote> |
| 154 | |
| 155 | A manifest has zero or more <b>F</b> cards. Each <b>F</b> card identifies a file |
| 156 | that is part of the check-in. There are one, two, three, or four |
| 157 | arguments. The first argument is the pathname of the file in the |
| 158 | check-in relative to the root of the project file hierarchy. No ".." |
| @@ -260,14 +260,14 @@ | |
| 260 | may be removed from a repository without loss or damage to the |
| 261 | underlying project code. |
| 262 | |
| 263 | Allowed cards in the cluster are as follows: |
| 264 | |
| 265 | <blockquote> |
| 266 | <b>M</b> <i>artifact-id</i><br /> |
| 267 | <b>Z</b> <i>checksum</i> |
| 268 | </blockquote> |
| 269 | |
| 270 | A cluster contains one or more <b>M</b> cards followed by a single <b>Z</b> card. |
| 271 | Each <b>M</b> card has a single argument which is the artifact ID of |
| 272 | another artifact in the repository. The <b>Z</b> card works exactly like |
| 273 | the <b>Z</b> card of a manifest. The argument to the <b>Z</b> card is the |
| @@ -281,16 +281,16 @@ | |
| 281 | |
| 282 | Control artifacts are used to assign properties to other artifacts |
| 283 | within the repository. |
| 284 | Allowed cards in a control artifact are as follows: |
| 285 | |
| 286 | <blockquote> |
| 287 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 288 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <i>artifact-id</i> ?<i>value</i>?<br /> |
| 289 | <b>U</b> <i>user-name</i><br /> |
| 290 | <b>Z</b> <i>checksum</i><br /> |
| 291 | </blockquote> |
| 292 | |
| 293 | A control artifact must have one <b>D</b> card, one <b>U</b> card, one <b>Z</b> card and |
| 294 | one or more <b>T</b> cards. No other cards or other text is |
| 295 | allowed in a control artifact. Control artifacts might be PGP |
| 296 | clearsigned. |
| @@ -335,20 +335,20 @@ | |
| 335 | A wiki artifact defines a single version of a |
| 336 | single wiki page. |
| 337 | Wiki artifacts accept |
| 338 | the following card types: |
| 339 | |
| 340 | <blockquote> |
| 341 | <b>C</b> <i>change-comment</i><br> |
| 342 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 343 | <b>L</b> <i>wiki-title</i><br /> |
| 344 | <b>N</b> <i>mimetype</i><br /> |
| 345 | <b>P</b> <i>parent-artifact-id</i>+<br /> |
| 346 | <b>U</b> <i>user-name</i><br /> |
| 347 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 348 | <b>Z</b> <i>checksum</i> |
| 349 | </blockquote> |
| 350 | |
| 351 | The <b>D</b> card is the date and time when the wiki page was edited. |
| 352 | The <b>P</b> card specifies the parent wiki pages, if any. The <b>L</b> card |
| 353 | gives the name of the wiki page. The optional <b>N</b> card specifies |
| 354 | the mimetype of the wiki text. If the <b>N</b> card is omitted, the |
| @@ -376,17 +376,17 @@ | |
| 376 | <h3 id="tktchng">2.5 Ticket Changes</h3> |
| 377 | |
| 378 | A ticket-change artifact represents a change to a trouble ticket. |
| 379 | The following cards are allowed on a ticket change artifact: |
| 380 | |
| 381 | <blockquote> |
| 382 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 383 | <b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br /> |
| 384 | <b>K</b> <i>ticket-id</i><br /> |
| 385 | <b>U</b> <i>user-name</i><br /> |
| 386 | <b>Z</b> <i>checksum</i> |
| 387 | </blockquote> |
| 388 | |
| 389 | The <b>D</b> card is the usual date and time stamp and represents the point |
| 390 | in time when the change was entered. The <b>U</b> card is the login of the |
| 391 | programmer who entered this change. The <b>Z</b> card is the required checksum over |
| 392 | the entire artifact. |
| @@ -424,18 +424,18 @@ | |
| 424 | attachment (the source artifact) with a ticket or wiki page or |
| 425 | technical note to which |
| 426 | the attachment is connected (the target artifact). |
| 427 | The following cards are allowed on an attachment artifact: |
| 428 | |
| 429 | <blockquote> |
| 430 | <b>A</b> <i>filename target</i> ?<i>source</i>?<br /> |
| 431 | <b>C</b> <i>comment</i><br /> |
| 432 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 433 | <b>N</b> <i>mimetype</i><br /> |
| 434 | <b>U</b> <i>user-name</i><br /> |
| 435 | <b>Z</b> <i>checksum</i> |
| 436 | </blockquote> |
| 437 | |
| 438 | The <b>A</b> card specifies a filename for the attachment in its first argument. |
| 439 | The second argument to the <b>A</b> card is the name of the wiki page or |
| 440 | ticket or technical note to which the attachment is connected. The |
| 441 | third argument is either missing or else it is the lower-case artifact |
| @@ -466,21 +466,21 @@ | |
| 466 | (similar to a wiki page) with a point in time. Technotes can be used |
| 467 | to record project milestones, release notes, blog entries, process |
| 468 | checkpoints, or news articles. |
| 469 | The following cards are allowed on an technote artifact: |
| 470 | |
| 471 | <blockquote> |
| 472 | <b>C</b> <i>comment</i><br> |
| 473 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 474 | <b>E</b> <i>technote-time</i> <i>technote-id</i><br /> |
| 475 | <b>N</b> <i>mimetype</i><br /> |
| 476 | <b>P</b> <i>parent-artifact-id</i>+<br /> |
| 477 | <b>T</b> <b>+</b><i>tag-name</i> <b>*</b> ?<i>value</i>?<br /> |
| 478 | <b>U</b> <i>user-name</i><br /> |
| 479 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 480 | <b>Z</b> <i>checksum</i> |
| 481 | </blockquote> |
| 482 | |
| 483 | The <b>C</b> card contains text that is displayed on the timeline for the |
| 484 | technote. The <b>C</b> card is optional, but there can only be one. |
| 485 | |
| 486 | A single <b>D</b> card is required to give the date and time when the |
| @@ -531,21 +531,21 @@ | |
| 531 | Forum posts are intended as a mechanism for users and developers to |
| 532 | discuss a project. Forum posts are like messages on a mailing list. |
| 533 | |
| 534 | The following cards are allowed on an forum post artifact: |
| 535 | |
| 536 | <blockquote> |
| 537 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 538 | <b>G</b> <i>thread-root</i><br /> |
| 539 | <b>H</b> <i>thread-title</i><br /> |
| 540 | <b>I</b> <i>in-reply-to</i><br /> |
| 541 | <b>N</b> <i>mimetype</i><br /> |
| 542 | <b>P</b> <i>parent-artifact-id</i><br /> |
| 543 | <b>U</b> <i>user-name</i><br /> |
| 544 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 545 | <b>Z</b> <i>checksum</i> |
| 546 | </blockquote> |
| 547 | |
| 548 | Every forum post must have either one <b>I</b> card and one <b>G</b> card |
| 549 | or one <b>H</b> card. |
| 550 | Forum posts are organized into topic threads. The initial |
| 551 | post for a thread (the root post) has an <b>H</b> card giving the title or |
| @@ -903,15 +903,15 @@ | |
| 903 | Both bugs have now been fixed. However, to prevent historical |
| 904 | Technical Note artifacts that were inserted by users in good faith |
| 905 | from being rejected by newer Fossil builds, the card ordering |
| 906 | requirement is relaxed slightly. The actual implementation is this: |
| 907 | |
| 908 | <blockquote> |
| 909 | "All cards must be in strict lexicographic order, except that the |
| 910 | N and P cards of a Technical Note artifact are allowed to be |
| 911 | interchanged." |
| 912 | </blockquote> |
| 913 | |
| 914 | Future versions of Fossil might strengthen this slightly to only allow |
| 915 | the out of order N and P cards for Technical Notes entered before |
| 916 | a certain date. |
| 917 | |
| 918 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -107,11 +107,11 @@ | |
| 107 | the check-in was created, and any check-in comments associated |
| 108 | with the check-in. |
| 109 | |
| 110 | Allowed cards in the manifest are as follows: |
| 111 | |
| 112 | <p class="indent"> |
| 113 | <b>B</b> <i>baseline-manifest</i><br> |
| 114 | <b>C</b> <i>checkin-comment</i><br> |
| 115 | <b>D</b> <i>time-and-date-stamp</i><br> |
| 116 | <b>F</b> <i>filename</i> ?<i>hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br> |
| 117 | <b>N</b> <i>mimetype</i><br> |
| @@ -119,11 +119,11 @@ | |
| 119 | <b>Q</b> (<b>+</b>|<b>-</b>)<i>artifact-hash</i> ?<i>artifact-hash</i>?<br> |
| 120 | <b>R</b> <i>repository-checksum</i><br> |
| 121 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <b>*</b> ?<i>value</i>?<br> |
| 122 | <b>U</b> <i>user-login</i><br> |
| 123 | <b>Z</b> <i>manifest-checksum</i> |
| 124 | </p> |
| 125 | |
| 126 | A manifest may optionally have a single <b>B</b> card. The <b>B</b> card specifies |
| 127 | another manifest that serves as the "baseline" for this manifest. A |
| 128 | manifest that has a <b>B</b> card is called a delta-manifest and a manifest |
| 129 | that omits the <b>B</b> card is a baseline-manifest. The other manifest |
| @@ -145,14 +145,14 @@ | |
| 145 | A manifest must have exactly one <b>D</b> card. The sole argument to |
| 146 | the <b>D</b> card is a date-time stamp in the ISO8601 format. The |
| 147 | date and time should be in coordinated universal time (UTC). |
| 148 | The format one of: |
| 149 | |
| 150 | <p class="indent"> |
| 151 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><br> |
| 152 | <i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><b>.</b><i>SSS</i> |
| 153 | </p> |
| 154 | |
| 155 | A manifest has zero or more <b>F</b> cards. Each <b>F</b> card identifies a file |
| 156 | that is part of the check-in. There are one, two, three, or four |
| 157 | arguments. The first argument is the pathname of the file in the |
| 158 | check-in relative to the root of the project file hierarchy. No ".." |
| @@ -260,14 +260,14 @@ | |
| 260 | may be removed from a repository without loss or damage to the |
| 261 | underlying project code. |
| 262 | |
| 263 | Allowed cards in the cluster are as follows: |
| 264 | |
| 265 | <p class="indent"> |
| 266 | <b>M</b> <i>artifact-id</i><br /> |
| 267 | <b>Z</b> <i>checksum</i> |
| 268 | </p> |
| 269 | |
| 270 | A cluster contains one or more <b>M</b> cards followed by a single <b>Z</b> card. |
| 271 | Each <b>M</b> card has a single argument which is the artifact ID of |
| 272 | another artifact in the repository. The <b>Z</b> card works exactly like |
| 273 | the <b>Z</b> card of a manifest. The argument to the <b>Z</b> card is the |
| @@ -281,16 +281,16 @@ | |
| 281 | |
| 282 | Control artifacts are used to assign properties to other artifacts |
| 283 | within the repository. |
| 284 | Allowed cards in a control artifact are as follows: |
| 285 | |
| 286 | <p class="indent"> |
| 287 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 288 | <b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <i>artifact-id</i> ?<i>value</i>?<br /> |
| 289 | <b>U</b> <i>user-name</i><br /> |
| 290 | <b>Z</b> <i>checksum</i><br /> |
| 291 | </p> |
| 292 | |
| 293 | A control artifact must have one <b>D</b> card, one <b>U</b> card, one <b>Z</b> card and |
| 294 | one or more <b>T</b> cards. No other cards or other text is |
| 295 | allowed in a control artifact. Control artifacts might be PGP |
| 296 | clearsigned. |
| @@ -335,20 +335,20 @@ | |
| 335 | A wiki artifact defines a single version of a |
| 336 | single wiki page. |
| 337 | Wiki artifacts accept |
| 338 | the following card types: |
| 339 | |
| 340 | <p class="indent"> |
| 341 | <b>C</b> <i>change-comment</i><br> |
| 342 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 343 | <b>L</b> <i>wiki-title</i><br /> |
| 344 | <b>N</b> <i>mimetype</i><br /> |
| 345 | <b>P</b> <i>parent-artifact-id</i>+<br /> |
| 346 | <b>U</b> <i>user-name</i><br /> |
| 347 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 348 | <b>Z</b> <i>checksum</i> |
| 349 | </p> |
| 350 | |
| 351 | The <b>D</b> card is the date and time when the wiki page was edited. |
| 352 | The <b>P</b> card specifies the parent wiki pages, if any. The <b>L</b> card |
| 353 | gives the name of the wiki page. The optional <b>N</b> card specifies |
| 354 | the mimetype of the wiki text. If the <b>N</b> card is omitted, the |
| @@ -376,17 +376,17 @@ | |
| 376 | <h3 id="tktchng">2.5 Ticket Changes</h3> |
| 377 | |
| 378 | A ticket-change artifact represents a change to a trouble ticket. |
| 379 | The following cards are allowed on a ticket change artifact: |
| 380 | |
| 381 | <p class="indent"> |
| 382 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 383 | <b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br /> |
| 384 | <b>K</b> <i>ticket-id</i><br /> |
| 385 | <b>U</b> <i>user-name</i><br /> |
| 386 | <b>Z</b> <i>checksum</i> |
| 387 | </p> |
| 388 | |
| 389 | The <b>D</b> card is the usual date and time stamp and represents the point |
| 390 | in time when the change was entered. The <b>U</b> card is the login of the |
| 391 | programmer who entered this change. The <b>Z</b> card is the required checksum over |
| 392 | the entire artifact. |
| @@ -424,18 +424,18 @@ | |
| 424 | attachment (the source artifact) with a ticket or wiki page or |
| 425 | technical note to which |
| 426 | the attachment is connected (the target artifact). |
| 427 | The following cards are allowed on an attachment artifact: |
| 428 | |
| 429 | <p class="indent"> |
| 430 | <b>A</b> <i>filename target</i> ?<i>source</i>?<br /> |
| 431 | <b>C</b> <i>comment</i><br /> |
| 432 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 433 | <b>N</b> <i>mimetype</i><br /> |
| 434 | <b>U</b> <i>user-name</i><br /> |
| 435 | <b>Z</b> <i>checksum</i> |
| 436 | </p> |
| 437 | |
| 438 | The <b>A</b> card specifies a filename for the attachment in its first argument. |
| 439 | The second argument to the <b>A</b> card is the name of the wiki page or |
| 440 | ticket or technical note to which the attachment is connected. The |
| 441 | third argument is either missing or else it is the lower-case artifact |
| @@ -466,21 +466,21 @@ | |
| 466 | (similar to a wiki page) with a point in time. Technotes can be used |
| 467 | to record project milestones, release notes, blog entries, process |
| 468 | checkpoints, or news articles. |
| 469 | The following cards are allowed on an technote artifact: |
| 470 | |
| 471 | <p class="indent"> |
| 472 | <b>C</b> <i>comment</i><br> |
| 473 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 474 | <b>E</b> <i>technote-time</i> <i>technote-id</i><br /> |
| 475 | <b>N</b> <i>mimetype</i><br /> |
| 476 | <b>P</b> <i>parent-artifact-id</i>+<br /> |
| 477 | <b>T</b> <b>+</b><i>tag-name</i> <b>*</b> ?<i>value</i>?<br /> |
| 478 | <b>U</b> <i>user-name</i><br /> |
| 479 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 480 | <b>Z</b> <i>checksum</i> |
| 481 | </p> |
| 482 | |
| 483 | The <b>C</b> card contains text that is displayed on the timeline for the |
| 484 | technote. The <b>C</b> card is optional, but there can only be one. |
| 485 | |
| 486 | A single <b>D</b> card is required to give the date and time when the |
| @@ -531,21 +531,21 @@ | |
| 531 | Forum posts are intended as a mechanism for users and developers to |
| 532 | discuss a project. Forum posts are like messages on a mailing list. |
| 533 | |
| 534 | The following cards are allowed on an forum post artifact: |
| 535 | |
| 536 | <p class="indent"> |
| 537 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 538 | <b>G</b> <i>thread-root</i><br /> |
| 539 | <b>H</b> <i>thread-title</i><br /> |
| 540 | <b>I</b> <i>in-reply-to</i><br /> |
| 541 | <b>N</b> <i>mimetype</i><br /> |
| 542 | <b>P</b> <i>parent-artifact-id</i><br /> |
| 543 | <b>U</b> <i>user-name</i><br /> |
| 544 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 545 | <b>Z</b> <i>checksum</i> |
| 546 | </p> |
| 547 | |
| 548 | Every forum post must have either one <b>I</b> card and one <b>G</b> card |
| 549 | or one <b>H</b> card. |
| 550 | Forum posts are organized into topic threads. The initial |
| 551 | post for a thread (the root post) has an <b>H</b> card giving the title or |
| @@ -903,15 +903,15 @@ | |
| 903 | Both bugs have now been fixed. However, to prevent historical |
| 904 | Technical Note artifacts that were inserted by users in good faith |
| 905 | from being rejected by newer Fossil builds, the card ordering |
| 906 | requirement is relaxed slightly. The actual implementation is this: |
| 907 | |
| 908 | <p class=blockquote> |
| 909 | "All cards must be in strict lexicographic order, except that the |
| 910 | N and P cards of a Technical Note artifact are allowed to be |
| 911 | interchanged." |
| 912 | </p> |
| 913 | |
| 914 | Future versions of Fossil might strengthen this slightly to only allow |
| 915 | the out of order N and P cards for Technical Notes entered before |
| 916 | a certain date. |
| 917 | |
| 918 |
+3
-3
| --- www/newrepo.wiki | ||
| +++ www/newrepo.wiki | ||
| @@ -38,17 +38,17 @@ | ||
| 38 | 38 | but that's personal preference.) |
| 39 | 39 | |
| 40 | 40 | Once you are done, kill the fossil server (with Ctrl-C or equivalent) |
| 41 | 41 | and close the browser window. |
| 42 | 42 | |
| 43 | -<blockquote> | |
| 44 | -Tip: it is not strictly required to configure a repository | |
| 43 | +<div class="sidebar"> | |
| 44 | +It is not strictly required to configure a repository | |
| 45 | 45 | this way, but if you are going to share a repo over the net then it |
| 46 | 46 | is highly recommended. If you are only going to work with the repo |
| 47 | 47 | locally, you can skip the configuration step and do it later if |
| 48 | 48 | you decide you want to share your repo. |
| 49 | -</blockquote> | |
| 49 | +</div> | |
| 50 | 50 | |
| 51 | 51 | The next thing we need to do is <em>open</em> the repository. To do so |
| 52 | 52 | we create a working directory and then <tt>cd</tt> to it: |
| 53 | 53 | |
| 54 | 54 | <verbatim> |
| 55 | 55 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -38,17 +38,17 @@ | |
| 38 | but that's personal preference.) |
| 39 | |
| 40 | Once you are done, kill the fossil server (with Ctrl-C or equivalent) |
| 41 | and close the browser window. |
| 42 | |
| 43 | <blockquote> |
| 44 | Tip: it is not strictly required to configure a repository |
| 45 | this way, but if you are going to share a repo over the net then it |
| 46 | is highly recommended. If you are only going to work with the repo |
| 47 | locally, you can skip the configuration step and do it later if |
| 48 | you decide you want to share your repo. |
| 49 | </blockquote> |
| 50 | |
| 51 | The next thing we need to do is <em>open</em> the repository. To do so |
| 52 | we create a working directory and then <tt>cd</tt> to it: |
| 53 | |
| 54 | <verbatim> |
| 55 |
| --- www/newrepo.wiki | |
| +++ www/newrepo.wiki | |
| @@ -38,17 +38,17 @@ | |
| 38 | but that's personal preference.) |
| 39 | |
| 40 | Once you are done, kill the fossil server (with Ctrl-C or equivalent) |
| 41 | and close the browser window. |
| 42 | |
| 43 | <div class="sidebar"> |
| 44 | It is not strictly required to configure a repository |
| 45 | this way, but if you are going to share a repo over the net then it |
| 46 | is highly recommended. If you are only going to work with the repo |
| 47 | locally, you can skip the configuration step and do it later if |
| 48 | you decide you want to share your repo. |
| 49 | </div> |
| 50 | |
| 51 | The next thing we need to do is <em>open</em> the repository. To do so |
| 52 | we create a working directory and then <tt>cd</tt> to it: |
| 53 | |
| 54 | <verbatim> |
| 55 |
+21
-21
| --- www/private.wiki | ||
| +++ www/private.wiki | ||
| @@ -8,13 +8,13 @@ | ||
| 8 | 8 | shared with others. This might be a preliminary or experimental change |
| 9 | 9 | that needs further refinement before it is shared and which might never |
| 10 | 10 | be shared at all. To do this in Fossil, simply commit the change with |
| 11 | 11 | the --private command-line option: |
| 12 | 12 | |
| 13 | -<blockquote><pre> | |
| 13 | +<pre> | |
| 14 | 14 | fossil commit --private |
| 15 | -</pre></blockquote> | |
| 15 | +</pre> | |
| 16 | 16 | |
| 17 | 17 | The --private option causes Fossil to put the check-in in a new branch |
| 18 | 18 | named "private". That branch will not participate in subsequent clone, |
| 19 | 19 | sync, push, or pull operations. The branch will remain on the one local |
| 20 | 20 | repository where it was created. Note that you only use the --private |
| @@ -25,15 +25,15 @@ | ||
| 25 | 25 | |
| 26 | 26 | After additional work, one might desire to publish the changes associated |
| 27 | 27 | with a private branch. The usual way to do this is to merge those |
| 28 | 28 | changes into a public branch. For example: |
| 29 | 29 | |
| 30 | -<blockquote><pre> | |
| 30 | +<pre> | |
| 31 | 31 | fossil update trunk |
| 32 | 32 | fossil merge private |
| 33 | 33 | fossil commit |
| 34 | -</pre></blockquote> | |
| 34 | +</pre> | |
| 35 | 35 | |
| 36 | 36 | The private branch remains private and is not recorded as a parent |
| 37 | 37 | in the merge manifest's P-card, but all of the changes associated with |
| 38 | 38 | the private branch are now folded into the public branch and are hence |
| 39 | 39 | visible to other users of the project. |
| @@ -40,10 +40,23 @@ | ||
| 40 | 40 | |
| 41 | 41 | A private branch created with Fossil version 1.30 or newer can also be |
| 42 | 42 | converted into a public branch using the <code>fossil publish</code> |
| 43 | 43 | command. However, there is no way to convert a private branch created with |
| 44 | 44 | older versions of Fossil into a public branch. |
| 45 | + | |
| 46 | +<div class="sidebar"> | |
| 47 | +To avoid generating a missing artifact | |
| 48 | +reference on peer repositories without the private branch, the merge parent | |
| 49 | +is not recorded when merging the private branch into a public branch. As a | |
| 50 | +consequence, the web UI timeline does not draw a merge line from the private | |
| 51 | +merge parent to the public merge child. Moreover, repeat private-to-public | |
| 52 | +merge operations (without the [/help?cmd=merge | --force option]) with files | |
| 53 | +added on the private branch may only work once, but later abort with | |
| 54 | +"WARNING: no common ancestor for FILE", as the parent-child relationship is | |
| 55 | +not recorded. (See the [/doc/trunk/www/branching.wiki | Branching, Forking, | |
| 56 | +Merging, and Tagging] document for more information.) | |
| 57 | +</div> | |
| 45 | 58 | |
| 46 | 59 | The <code>--integrate</code> option of <code>fossil merge</code> (to close |
| 47 | 60 | the merged branch when committing) is ignored for a private branch -- or the |
| 48 | 61 | check-in manifest of the resulting merge child would include a |
| 49 | 62 | <code>+close</code> tag referring to the leaf check-in on the private branch, |
| @@ -50,23 +63,10 @@ | ||
| 50 | 63 | and generate a missing artifact reference on repository clones without that |
| 51 | 64 | private branch. It's still possible to close the leaf of the private branch |
| 52 | 65 | (after committing the merge child) with the <code>fossil amend --close</code> |
| 53 | 66 | command. |
| 54 | 67 | |
| 55 | -<blockquote><small> | |
| 56 | -Side note: For the same reason, i.e. so as not to generate a missing artifact | |
| 57 | -reference on peer repositories without the private branch, the merge parent | |
| 58 | -is not recorded when merging the private branch into a public branch. As a | |
| 59 | -consequence, the web UI timeline does not draw a merge line from the private | |
| 60 | -merge parent to the public merge child. Moreover, repeat private-to-public | |
| 61 | -merge operations (without the [/help?cmd=merge | --force option]) with files | |
| 62 | -added on the private branch may only work once, but later abort with | |
| 63 | -"WARNING: no common ancestor for FILE", as the parent-child relationship is | |
| 64 | -not recorded (see the [/doc/trunk/www/branching.wiki | Branching, Forking, | |
| 65 | -Merging, and Tagging] document for more information). | |
| 66 | -</small></blockquote> | |
| 67 | - | |
| 68 | 68 | <h2>Syncing Private Branches</h2> |
| 69 | 69 | |
| 70 | 70 | A private branch normally stays on the one repository where it was |
| 71 | 71 | originally created. But sometimes you want to share private branches |
| 72 | 72 | with another repository. For example, you might be building a cross-platform |
| @@ -75,13 +75,13 @@ | ||
| 75 | 75 | between these machines by using the --private option on the "sync", |
| 76 | 76 | "push", "pull", and "clone" commands. For example, if you are running |
| 77 | 77 | "fossil server" on your Linux box and you want to clone that repository |
| 78 | 78 | to your Mac, including all private branches, use: |
| 79 | 79 | |
| 80 | -<blockquote><pre> | |
| 80 | +<verbatim> | |
| 81 | 81 | fossil clone --private http://[email protected]:8080/ mac-clone.fossil |
| 82 | -</pre></blockquote> | |
| 82 | +</verbatim> | |
| 83 | 83 | |
| 84 | 84 | You'll have to supply a username and password in order for this to work. |
| 85 | 85 | Fossil will not clone (or sync) private branches anonymously. |
| 86 | 86 | |
| 87 | 87 | By default, there are no users that can do private branch syncing. You |
| @@ -101,13 +101,13 @@ | ||
| 101 | 101 | |
| 102 | 102 | <h2>Purging Private Branches</h2> |
| 103 | 103 | |
| 104 | 104 | You can remove all private branches from a repository using this command: |
| 105 | 105 | |
| 106 | -<blockquote><pre> | |
| 106 | +<pre> | |
| 107 | 107 | fossil scrub --private |
| 108 | -</pre></blockquote> | |
| 108 | +</pre> | |
| 109 | 109 | |
| 110 | 110 | Note that the above is a permanent and irreversible change. You will |
| 111 | 111 | be asked to confirm before continuing. Once the private branches are |
| 112 | 112 | removed, they cannot be retrieved (unless you have synced them to another |
| 113 | 113 | repository.) So be careful with the command. |
| 114 | 114 |
| --- www/private.wiki | |
| +++ www/private.wiki | |
| @@ -8,13 +8,13 @@ | |
| 8 | shared with others. This might be a preliminary or experimental change |
| 9 | that needs further refinement before it is shared and which might never |
| 10 | be shared at all. To do this in Fossil, simply commit the change with |
| 11 | the --private command-line option: |
| 12 | |
| 13 | <blockquote><pre> |
| 14 | fossil commit --private |
| 15 | </pre></blockquote> |
| 16 | |
| 17 | The --private option causes Fossil to put the check-in in a new branch |
| 18 | named "private". That branch will not participate in subsequent clone, |
| 19 | sync, push, or pull operations. The branch will remain on the one local |
| 20 | repository where it was created. Note that you only use the --private |
| @@ -25,15 +25,15 @@ | |
| 25 | |
| 26 | After additional work, one might desire to publish the changes associated |
| 27 | with a private branch. The usual way to do this is to merge those |
| 28 | changes into a public branch. For example: |
| 29 | |
| 30 | <blockquote><pre> |
| 31 | fossil update trunk |
| 32 | fossil merge private |
| 33 | fossil commit |
| 34 | </pre></blockquote> |
| 35 | |
| 36 | The private branch remains private and is not recorded as a parent |
| 37 | in the merge manifest's P-card, but all of the changes associated with |
| 38 | the private branch are now folded into the public branch and are hence |
| 39 | visible to other users of the project. |
| @@ -40,10 +40,23 @@ | |
| 40 | |
| 41 | A private branch created with Fossil version 1.30 or newer can also be |
| 42 | converted into a public branch using the <code>fossil publish</code> |
| 43 | command. However, there is no way to convert a private branch created with |
| 44 | older versions of Fossil into a public branch. |
| 45 | |
| 46 | The <code>--integrate</code> option of <code>fossil merge</code> (to close |
| 47 | the merged branch when committing) is ignored for a private branch -- or the |
| 48 | check-in manifest of the resulting merge child would include a |
| 49 | <code>+close</code> tag referring to the leaf check-in on the private branch, |
| @@ -50,23 +63,10 @@ | |
| 50 | and generate a missing artifact reference on repository clones without that |
| 51 | private branch. It's still possible to close the leaf of the private branch |
| 52 | (after committing the merge child) with the <code>fossil amend --close</code> |
| 53 | command. |
| 54 | |
| 55 | <blockquote><small> |
| 56 | Side note: For the same reason, i.e. so as not to generate a missing artifact |
| 57 | reference on peer repositories without the private branch, the merge parent |
| 58 | is not recorded when merging the private branch into a public branch. As a |
| 59 | consequence, the web UI timeline does not draw a merge line from the private |
| 60 | merge parent to the public merge child. Moreover, repeat private-to-public |
| 61 | merge operations (without the [/help?cmd=merge | --force option]) with files |
| 62 | added on the private branch may only work once, but later abort with |
| 63 | "WARNING: no common ancestor for FILE", as the parent-child relationship is |
| 64 | not recorded (see the [/doc/trunk/www/branching.wiki | Branching, Forking, |
| 65 | Merging, and Tagging] document for more information). |
| 66 | </small></blockquote> |
| 67 | |
| 68 | <h2>Syncing Private Branches</h2> |
| 69 | |
| 70 | A private branch normally stays on the one repository where it was |
| 71 | originally created. But sometimes you want to share private branches |
| 72 | with another repository. For example, you might be building a cross-platform |
| @@ -75,13 +75,13 @@ | |
| 75 | between these machines by using the --private option on the "sync", |
| 76 | "push", "pull", and "clone" commands. For example, if you are running |
| 77 | "fossil server" on your Linux box and you want to clone that repository |
| 78 | to your Mac, including all private branches, use: |
| 79 | |
| 80 | <blockquote><pre> |
| 81 | fossil clone --private http://[email protected]:8080/ mac-clone.fossil |
| 82 | </pre></blockquote> |
| 83 | |
| 84 | You'll have to supply a username and password in order for this to work. |
| 85 | Fossil will not clone (or sync) private branches anonymously. |
| 86 | |
| 87 | By default, there are no users that can do private branch syncing. You |
| @@ -101,13 +101,13 @@ | |
| 101 | |
| 102 | <h2>Purging Private Branches</h2> |
| 103 | |
| 104 | You can remove all private branches from a repository using this command: |
| 105 | |
| 106 | <blockquote><pre> |
| 107 | fossil scrub --private |
| 108 | </pre></blockquote> |
| 109 | |
| 110 | Note that the above is a permanent and irreversible change. You will |
| 111 | be asked to confirm before continuing. Once the private branches are |
| 112 | removed, they cannot be retrieved (unless you have synced them to another |
| 113 | repository.) So be careful with the command. |
| 114 |
| --- www/private.wiki | |
| +++ www/private.wiki | |
| @@ -8,13 +8,13 @@ | |
| 8 | shared with others. This might be a preliminary or experimental change |
| 9 | that needs further refinement before it is shared and which might never |
| 10 | be shared at all. To do this in Fossil, simply commit the change with |
| 11 | the --private command-line option: |
| 12 | |
| 13 | <pre> |
| 14 | fossil commit --private |
| 15 | </pre> |
| 16 | |
| 17 | The --private option causes Fossil to put the check-in in a new branch |
| 18 | named "private". That branch will not participate in subsequent clone, |
| 19 | sync, push, or pull operations. The branch will remain on the one local |
| 20 | repository where it was created. Note that you only use the --private |
| @@ -25,15 +25,15 @@ | |
| 25 | |
| 26 | After additional work, one might desire to publish the changes associated |
| 27 | with a private branch. The usual way to do this is to merge those |
| 28 | changes into a public branch. For example: |
| 29 | |
| 30 | <pre> |
| 31 | fossil update trunk |
| 32 | fossil merge private |
| 33 | fossil commit |
| 34 | </pre> |
| 35 | |
| 36 | The private branch remains private and is not recorded as a parent |
| 37 | in the merge manifest's P-card, but all of the changes associated with |
| 38 | the private branch are now folded into the public branch and are hence |
| 39 | visible to other users of the project. |
| @@ -40,10 +40,23 @@ | |
| 40 | |
| 41 | A private branch created with Fossil version 1.30 or newer can also be |
| 42 | converted into a public branch using the <code>fossil publish</code> |
| 43 | command. However, there is no way to convert a private branch created with |
| 44 | older versions of Fossil into a public branch. |
| 45 | |
| 46 | <div class="sidebar"> |
| 47 | To avoid generating a missing artifact |
| 48 | reference on peer repositories without the private branch, the merge parent |
| 49 | is not recorded when merging the private branch into a public branch. As a |
| 50 | consequence, the web UI timeline does not draw a merge line from the private |
| 51 | merge parent to the public merge child. Moreover, repeat private-to-public |
| 52 | merge operations (without the [/help?cmd=merge | --force option]) with files |
| 53 | added on the private branch may only work once, but later abort with |
| 54 | "WARNING: no common ancestor for FILE", as the parent-child relationship is |
| 55 | not recorded. (See the [/doc/trunk/www/branching.wiki | Branching, Forking, |
| 56 | Merging, and Tagging] document for more information.) |
| 57 | </div> |
| 58 | |
| 59 | The <code>--integrate</code> option of <code>fossil merge</code> (to close |
| 60 | the merged branch when committing) is ignored for a private branch -- or the |
| 61 | check-in manifest of the resulting merge child would include a |
| 62 | <code>+close</code> tag referring to the leaf check-in on the private branch, |
| @@ -50,23 +63,10 @@ | |
| 63 | and generate a missing artifact reference on repository clones without that |
| 64 | private branch. It's still possible to close the leaf of the private branch |
| 65 | (after committing the merge child) with the <code>fossil amend --close</code> |
| 66 | command. |
| 67 | |
| 68 | <h2>Syncing Private Branches</h2> |
| 69 | |
| 70 | A private branch normally stays on the one repository where it was |
| 71 | originally created. But sometimes you want to share private branches |
| 72 | with another repository. For example, you might be building a cross-platform |
| @@ -75,13 +75,13 @@ | |
| 75 | between these machines by using the --private option on the "sync", |
| 76 | "push", "pull", and "clone" commands. For example, if you are running |
| 77 | "fossil server" on your Linux box and you want to clone that repository |
| 78 | to your Mac, including all private branches, use: |
| 79 | |
| 80 | <verbatim> |
| 81 | fossil clone --private http://[email protected]:8080/ mac-clone.fossil |
| 82 | </verbatim> |
| 83 | |
| 84 | You'll have to supply a username and password in order for this to work. |
| 85 | Fossil will not clone (or sync) private branches anonymously. |
| 86 | |
| 87 | By default, there are no users that can do private branch syncing. You |
| @@ -101,13 +101,13 @@ | |
| 101 | |
| 102 | <h2>Purging Private Branches</h2> |
| 103 | |
| 104 | You can remove all private branches from a repository using this command: |
| 105 | |
| 106 | <pre> |
| 107 | fossil scrub --private |
| 108 | </pre> |
| 109 | |
| 110 | Note that the above is a permanent and irreversible change. You will |
| 111 | be asked to confirm before continuing. Once the private branches are |
| 112 | removed, they cannot be retrieved (unless you have synced them to another |
| 113 | repository.) So be careful with the command. |
| 114 |
+17
-21
| --- www/qandc.wiki | ||
| +++ www/qandc.wiki | ||
| @@ -1,17 +1,16 @@ | ||
| 1 | 1 | <title>Questions And Criticisms</title> |
| 2 | -<nowiki> | |
| 3 | 2 | |
| 4 | 3 | This page is a collection of real questions and criticisms that were |
| 5 | 4 | raised against Fossil early in its history (circa 2008). |
| 6 | 5 | This page is old and has not been kept up-to-date. See the |
| 7 | -</nowiki>[/finfo?name=www/qandc.wiki|change history of this page]<nowiki>. | |
| 6 | +[/finfo?name=www/qandc.wiki|change history of this page]. | |
| 8 | 7 | |
| 9 | 8 | <b>Fossil sounds like a lot of reinvention of the wheel. |
| 10 | 9 | Why create your own DVCS when you could have reused mercurial?</b> |
| 11 | 10 | |
| 12 | -<blockquote> | |
| 11 | +<div class="indent"> | |
| 13 | 12 | I wrote fossil because none of the |
| 14 | 13 | other available DVCSes met my needs. If the other DVCSes do |
| 15 | 14 | meet your needs, then you might not need fossil. But they |
| 16 | 15 | don't meet mine, and so fossil is necessary for me. |
| 17 | 16 | |
| @@ -26,15 +25,15 @@ | ||
| 26 | 25 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 27 | 26 | <li> Simple, well-defined, |
| 28 | 27 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 29 | 28 | <li> Integrated <a href="webui.wiki">web interface</a> </li> |
| 30 | 29 | </ol> |
| 31 | -</blockquote> | |
| 30 | +</div> | |
| 32 | 31 | |
| 33 | 32 | <b>Why should I use this rather than Trac?</b> |
| 34 | 33 | |
| 35 | -<blockquote> | |
| 34 | +<div class="indent"> | |
| 36 | 35 | <ol> |
| 37 | 36 | <li> Fossil is distributed. You can view and/or edit tickets, wiki, and |
| 38 | 37 | code while off network, then sync your changes later. With Trac, you |
| 39 | 38 | can only view and edit tickets and wiki while you are connected to |
| 40 | 39 | the server. </li> |
| @@ -43,15 +42,15 @@ | ||
| 43 | 42 | administrator.</li> |
| 44 | 43 | <li> Fossil integrates code versioning into the same repository with |
| 45 | 44 | wiki and tickets. There is nothing extra to add or install. |
| 46 | 45 | Fossil is an all-in-one turnkey solution. </li> |
| 47 | 46 | </ol> |
| 48 | -</blockquote> | |
| 47 | +</div> | |
| 49 | 48 | |
| 50 | 49 | <b>Love the concept here. Anyone using this for real work yet?</b> |
| 51 | 50 | |
| 52 | -<blockquote> | |
| 51 | +<div class="indent"> | |
| 53 | 52 | Fossil is <a href="https://fossil-scm.org/">self-hosting</a>. |
| 54 | 53 | In fact, this page was probably delivered |
| 55 | 54 | to your web-browser via a working fossil instance. The same virtual |
| 56 | 55 | machine that hosts https://fossil-scm.org/ |
| 57 | 56 | (a <a href="http://www.linode.com/">Linode 720</a>) |
| @@ -60,32 +59,32 @@ | ||
| 60 | 59 | <a href="http://www.sqlite.org/">SQLite</a> are hosted in a |
| 61 | 60 | fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>, |
| 62 | 61 | for example. |
| 63 | 62 | Other projects are also adopting fossil. But fossil does not yet have |
| 64 | 63 | the massive user base of git or mercurial. |
| 65 | -</blockquote> | |
| 64 | +</div> | |
| 66 | 65 | |
| 67 | 66 | <b>Fossil looks like the bug tracker that would be in your |
| 68 | 67 | Linksys Router's administration screen.</b> |
| 69 | 68 | |
| 70 | -<blockquote> | |
| 69 | +<div class="indent"> | |
| 71 | 70 | I take a pragmatic approach to software: form follows function. |
| 72 | 71 | To me, it is more important to have a reliable, fast, efficient, |
| 73 | 72 | enduring, and simple DVCS than one that looks pretty. |
| 74 | 73 | |
| 75 | 74 | On the other hand, if you have patches that improve the appearance |
| 76 | 75 | of Fossil without seriously compromising its reliability, performance, |
| 77 | 76 | and/or maintainability, I will be happy to accept them. Fossil is |
| 78 | 77 | self-hosting. Send email to request a password that will let |
| 79 | 78 | you push to the main fossil repository. |
| 80 | -</blockquote> | |
| 79 | +</div> | |
| 81 | 80 | |
| 82 | 81 | <b>It would be useful to have a separate application that |
| 83 | 82 | keeps the bug-tracking database in a versioned file. That file can |
| 84 | 83 | then be pushed and pulled along with the rest repository.</b> |
| 85 | 84 | |
| 86 | -<blockquote> | |
| 85 | +<div class="indent"> | |
| 87 | 86 | Fossil already <u>does</u> push and pull bugs along with the files |
| 88 | 87 | in your repository. |
| 89 | 88 | But fossil does <u>not</u> track bugs as files in the source tree. |
| 90 | 89 | That approach to bug tracking was rejected for three reasons: |
| 91 | 90 | |
| @@ -106,39 +105,39 @@ | ||
| 106 | 105 | be permitted to create tickets. |
| 107 | 106 | </ol> |
| 108 | 107 | |
| 109 | 108 | These points are reiterated in the opening paragraphs of |
| 110 | 109 | the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document. |
| 111 | -</blockquote> | |
| 110 | +</div> | |
| 112 | 111 | |
| 113 | 112 | <b>Fossil is already the name of a plan9 versioned |
| 114 | 113 | append-only filesystem.</b> |
| 115 | 114 | |
| 116 | -<blockquote> | |
| 115 | +<div class="indent"> | |
| 117 | 116 | I did not know that. Perhaps they selected the name for the same reason that |
| 118 | 117 | I did: because a repository with immutable artifacts preserves |
| 119 | 118 | an excellent fossil record of a long-running project. |
| 120 | -</blockquote> | |
| 119 | +</div> | |
| 121 | 120 | |
| 122 | 121 | <b>The idea of storing a repository in a binary blob like an |
| 123 | 122 | SQLite database terrifies me.</b> |
| 124 | 123 | |
| 125 | -<blockquote> | |
| 124 | +<div class="indent"> | |
| 126 | 125 | The use of SQLite to store the database is likely more stable and secure |
| 127 | 126 | than any other approach, due to the fact that SQLite is transactional. |
| 128 | 127 | Fossil also implements several internal |
| 129 | 128 | <a href="selfcheck.wiki">self-checks</a> to insure that no information |
| 130 | 129 | is ever lost. |
| 131 | -</blockquote> | |
| 130 | +</div> | |
| 132 | 131 | |
| 133 | 132 | |
| 134 | 133 | <b>I am dubious of the benefits of including wikis and bug trackers |
| 135 | 134 | directly in the VCS - either they are under-featured compared to full |
| 136 | 135 | software like Trac, or the VCS is massively bloated compared to |
| 137 | 136 | Subversion or Bazaar.</b> |
| 138 | 137 | |
| 139 | -<blockquote> | |
| 138 | +<div class="indent"> | |
| 140 | 139 | I have no doubt that Trac has many features that fossil lacks. But that |
| 141 | 140 | is not the point. Fossil has several key features that Trac lacks and that |
| 142 | 141 | I need: most notably the fact that |
| 143 | 142 | fossil supports disconnected operation. |
| 144 | 143 | |
| @@ -150,9 +149,6 @@ | ||
| 150 | 149 | by itself. And the self-contained fossil |
| 151 | 150 | executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
| 152 | 151 | grown in the years since the previous sentence was written but is still |
| 153 | 152 | much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
| 154 | 153 | Fossil is the very opposite of bloat. |
| 155 | -</blockquote> | |
| 156 | - | |
| 157 | - | |
| 158 | -</nowiki> | |
| 154 | +</div> | |
| 159 | 155 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -1,17 +1,16 @@ | |
| 1 | <title>Questions And Criticisms</title> |
| 2 | <nowiki> |
| 3 | |
| 4 | This page is a collection of real questions and criticisms that were |
| 5 | raised against Fossil early in its history (circa 2008). |
| 6 | This page is old and has not been kept up-to-date. See the |
| 7 | </nowiki>[/finfo?name=www/qandc.wiki|change history of this page]<nowiki>. |
| 8 | |
| 9 | <b>Fossil sounds like a lot of reinvention of the wheel. |
| 10 | Why create your own DVCS when you could have reused mercurial?</b> |
| 11 | |
| 12 | <blockquote> |
| 13 | I wrote fossil because none of the |
| 14 | other available DVCSes met my needs. If the other DVCSes do |
| 15 | meet your needs, then you might not need fossil. But they |
| 16 | don't meet mine, and so fossil is necessary for me. |
| 17 | |
| @@ -26,15 +25,15 @@ | |
| 26 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 27 | <li> Simple, well-defined, |
| 28 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 29 | <li> Integrated <a href="webui.wiki">web interface</a> </li> |
| 30 | </ol> |
| 31 | </blockquote> |
| 32 | |
| 33 | <b>Why should I use this rather than Trac?</b> |
| 34 | |
| 35 | <blockquote> |
| 36 | <ol> |
| 37 | <li> Fossil is distributed. You can view and/or edit tickets, wiki, and |
| 38 | code while off network, then sync your changes later. With Trac, you |
| 39 | can only view and edit tickets and wiki while you are connected to |
| 40 | the server. </li> |
| @@ -43,15 +42,15 @@ | |
| 43 | administrator.</li> |
| 44 | <li> Fossil integrates code versioning into the same repository with |
| 45 | wiki and tickets. There is nothing extra to add or install. |
| 46 | Fossil is an all-in-one turnkey solution. </li> |
| 47 | </ol> |
| 48 | </blockquote> |
| 49 | |
| 50 | <b>Love the concept here. Anyone using this for real work yet?</b> |
| 51 | |
| 52 | <blockquote> |
| 53 | Fossil is <a href="https://fossil-scm.org/">self-hosting</a>. |
| 54 | In fact, this page was probably delivered |
| 55 | to your web-browser via a working fossil instance. The same virtual |
| 56 | machine that hosts https://fossil-scm.org/ |
| 57 | (a <a href="http://www.linode.com/">Linode 720</a>) |
| @@ -60,32 +59,32 @@ | |
| 60 | <a href="http://www.sqlite.org/">SQLite</a> are hosted in a |
| 61 | fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>, |
| 62 | for example. |
| 63 | Other projects are also adopting fossil. But fossil does not yet have |
| 64 | the massive user base of git or mercurial. |
| 65 | </blockquote> |
| 66 | |
| 67 | <b>Fossil looks like the bug tracker that would be in your |
| 68 | Linksys Router's administration screen.</b> |
| 69 | |
| 70 | <blockquote> |
| 71 | I take a pragmatic approach to software: form follows function. |
| 72 | To me, it is more important to have a reliable, fast, efficient, |
| 73 | enduring, and simple DVCS than one that looks pretty. |
| 74 | |
| 75 | On the other hand, if you have patches that improve the appearance |
| 76 | of Fossil without seriously compromising its reliability, performance, |
| 77 | and/or maintainability, I will be happy to accept them. Fossil is |
| 78 | self-hosting. Send email to request a password that will let |
| 79 | you push to the main fossil repository. |
| 80 | </blockquote> |
| 81 | |
| 82 | <b>It would be useful to have a separate application that |
| 83 | keeps the bug-tracking database in a versioned file. That file can |
| 84 | then be pushed and pulled along with the rest repository.</b> |
| 85 | |
| 86 | <blockquote> |
| 87 | Fossil already <u>does</u> push and pull bugs along with the files |
| 88 | in your repository. |
| 89 | But fossil does <u>not</u> track bugs as files in the source tree. |
| 90 | That approach to bug tracking was rejected for three reasons: |
| 91 | |
| @@ -106,39 +105,39 @@ | |
| 106 | be permitted to create tickets. |
| 107 | </ol> |
| 108 | |
| 109 | These points are reiterated in the opening paragraphs of |
| 110 | the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document. |
| 111 | </blockquote> |
| 112 | |
| 113 | <b>Fossil is already the name of a plan9 versioned |
| 114 | append-only filesystem.</b> |
| 115 | |
| 116 | <blockquote> |
| 117 | I did not know that. Perhaps they selected the name for the same reason that |
| 118 | I did: because a repository with immutable artifacts preserves |
| 119 | an excellent fossil record of a long-running project. |
| 120 | </blockquote> |
| 121 | |
| 122 | <b>The idea of storing a repository in a binary blob like an |
| 123 | SQLite database terrifies me.</b> |
| 124 | |
| 125 | <blockquote> |
| 126 | The use of SQLite to store the database is likely more stable and secure |
| 127 | than any other approach, due to the fact that SQLite is transactional. |
| 128 | Fossil also implements several internal |
| 129 | <a href="selfcheck.wiki">self-checks</a> to insure that no information |
| 130 | is ever lost. |
| 131 | </blockquote> |
| 132 | |
| 133 | |
| 134 | <b>I am dubious of the benefits of including wikis and bug trackers |
| 135 | directly in the VCS - either they are under-featured compared to full |
| 136 | software like Trac, or the VCS is massively bloated compared to |
| 137 | Subversion or Bazaar.</b> |
| 138 | |
| 139 | <blockquote> |
| 140 | I have no doubt that Trac has many features that fossil lacks. But that |
| 141 | is not the point. Fossil has several key features that Trac lacks and that |
| 142 | I need: most notably the fact that |
| 143 | fossil supports disconnected operation. |
| 144 | |
| @@ -150,9 +149,6 @@ | |
| 150 | by itself. And the self-contained fossil |
| 151 | executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
| 152 | grown in the years since the previous sentence was written but is still |
| 153 | much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
| 154 | Fossil is the very opposite of bloat. |
| 155 | </blockquote> |
| 156 | |
| 157 | |
| 158 | </nowiki> |
| 159 |
| --- www/qandc.wiki | |
| +++ www/qandc.wiki | |
| @@ -1,17 +1,16 @@ | |
| 1 | <title>Questions And Criticisms</title> |
| 2 | |
| 3 | This page is a collection of real questions and criticisms that were |
| 4 | raised against Fossil early in its history (circa 2008). |
| 5 | This page is old and has not been kept up-to-date. See the |
| 6 | [/finfo?name=www/qandc.wiki|change history of this page]. |
| 7 | |
| 8 | <b>Fossil sounds like a lot of reinvention of the wheel. |
| 9 | Why create your own DVCS when you could have reused mercurial?</b> |
| 10 | |
| 11 | <div class="indent"> |
| 12 | I wrote fossil because none of the |
| 13 | other available DVCSes met my needs. If the other DVCSes do |
| 14 | meet your needs, then you might not need fossil. But they |
| 15 | don't meet mine, and so fossil is necessary for me. |
| 16 | |
| @@ -26,15 +25,15 @@ | |
| 25 | a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li> |
| 26 | <li> Simple, well-defined, |
| 27 | <a href="fileformat.wiki">enduring file format</a> </li> |
| 28 | <li> Integrated <a href="webui.wiki">web interface</a> </li> |
| 29 | </ol> |
| 30 | </div> |
| 31 | |
| 32 | <b>Why should I use this rather than Trac?</b> |
| 33 | |
| 34 | <div class="indent"> |
| 35 | <ol> |
| 36 | <li> Fossil is distributed. You can view and/or edit tickets, wiki, and |
| 37 | code while off network, then sync your changes later. With Trac, you |
| 38 | can only view and edit tickets and wiki while you are connected to |
| 39 | the server. </li> |
| @@ -43,15 +42,15 @@ | |
| 42 | administrator.</li> |
| 43 | <li> Fossil integrates code versioning into the same repository with |
| 44 | wiki and tickets. There is nothing extra to add or install. |
| 45 | Fossil is an all-in-one turnkey solution. </li> |
| 46 | </ol> |
| 47 | </div> |
| 48 | |
| 49 | <b>Love the concept here. Anyone using this for real work yet?</b> |
| 50 | |
| 51 | <div class="indent"> |
| 52 | Fossil is <a href="https://fossil-scm.org/">self-hosting</a>. |
| 53 | In fact, this page was probably delivered |
| 54 | to your web-browser via a working fossil instance. The same virtual |
| 55 | machine that hosts https://fossil-scm.org/ |
| 56 | (a <a href="http://www.linode.com/">Linode 720</a>) |
| @@ -60,32 +59,32 @@ | |
| 59 | <a href="http://www.sqlite.org/">SQLite</a> are hosted in a |
| 60 | fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>, |
| 61 | for example. |
| 62 | Other projects are also adopting fossil. But fossil does not yet have |
| 63 | the massive user base of git or mercurial. |
| 64 | </div> |
| 65 | |
| 66 | <b>Fossil looks like the bug tracker that would be in your |
| 67 | Linksys Router's administration screen.</b> |
| 68 | |
| 69 | <div class="indent"> |
| 70 | I take a pragmatic approach to software: form follows function. |
| 71 | To me, it is more important to have a reliable, fast, efficient, |
| 72 | enduring, and simple DVCS than one that looks pretty. |
| 73 | |
| 74 | On the other hand, if you have patches that improve the appearance |
| 75 | of Fossil without seriously compromising its reliability, performance, |
| 76 | and/or maintainability, I will be happy to accept them. Fossil is |
| 77 | self-hosting. Send email to request a password that will let |
| 78 | you push to the main fossil repository. |
| 79 | </div> |
| 80 | |
| 81 | <b>It would be useful to have a separate application that |
| 82 | keeps the bug-tracking database in a versioned file. That file can |
| 83 | then be pushed and pulled along with the rest repository.</b> |
| 84 | |
| 85 | <div class="indent"> |
| 86 | Fossil already <u>does</u> push and pull bugs along with the files |
| 87 | in your repository. |
| 88 | But fossil does <u>not</u> track bugs as files in the source tree. |
| 89 | That approach to bug tracking was rejected for three reasons: |
| 90 | |
| @@ -106,39 +105,39 @@ | |
| 105 | be permitted to create tickets. |
| 106 | </ol> |
| 107 | |
| 108 | These points are reiterated in the opening paragraphs of |
| 109 | the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document. |
| 110 | </div> |
| 111 | |
| 112 | <b>Fossil is already the name of a plan9 versioned |
| 113 | append-only filesystem.</b> |
| 114 | |
| 115 | <div class="indent"> |
| 116 | I did not know that. Perhaps they selected the name for the same reason that |
| 117 | I did: because a repository with immutable artifacts preserves |
| 118 | an excellent fossil record of a long-running project. |
| 119 | </div> |
| 120 | |
| 121 | <b>The idea of storing a repository in a binary blob like an |
| 122 | SQLite database terrifies me.</b> |
| 123 | |
| 124 | <div class="indent"> |
| 125 | The use of SQLite to store the database is likely more stable and secure |
| 126 | than any other approach, due to the fact that SQLite is transactional. |
| 127 | Fossil also implements several internal |
| 128 | <a href="selfcheck.wiki">self-checks</a> to insure that no information |
| 129 | is ever lost. |
| 130 | </div> |
| 131 | |
| 132 | |
| 133 | <b>I am dubious of the benefits of including wikis and bug trackers |
| 134 | directly in the VCS - either they are under-featured compared to full |
| 135 | software like Trac, or the VCS is massively bloated compared to |
| 136 | Subversion or Bazaar.</b> |
| 137 | |
| 138 | <div class="indent"> |
| 139 | I have no doubt that Trac has many features that fossil lacks. But that |
| 140 | is not the point. Fossil has several key features that Trac lacks and that |
| 141 | I need: most notably the fact that |
| 142 | fossil supports disconnected operation. |
| 143 | |
| @@ -150,9 +149,6 @@ | |
| 149 | by itself. And the self-contained fossil |
| 150 | executable is much less than 1MB in size. (Update 2015-01-12: Fossil has |
| 151 | grown in the years since the previous sentence was written but is still |
| 152 | much less than 2MB according to "size" when compiled using -Os on x64 Linux.) |
| 153 | Fossil is the very opposite of bloat. |
| 154 | </div> |
| 155 |
+6
-6
| --- www/reviews.wiki | ||
| +++ www/reviews.wiki | ||
| @@ -8,21 +8,21 @@ | ||
| 8 | 8 | |
| 9 | 9 | * [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes] |
| 10 | 10 | |
| 11 | 11 | <b>Daniel writes on 2009-01-06:</b> |
| 12 | 12 | |
| 13 | -<blockquote> | |
| 13 | +<div class="indent"> | |
| 14 | 14 | The reasons I use fossil are that it's the only version control I |
| 15 | 15 | have found that I can get working through the VERY annoying MS |
| 16 | 16 | firewalls at work.. (albeit through an ntlm proxy) and I just love |
| 17 | 17 | single .exe applications! |
| 18 | -</blockquote> | |
| 18 | +</div> | |
| 19 | 19 | |
| 20 | 20 | |
| 21 | 21 | <b>Joshua Paine on 2010-10-22:</b> |
| 22 | 22 | |
| 23 | -<blockquote> | |
| 23 | +<div class="indent"> | |
| 24 | 24 | With one of my several hats on, I'm in a small team using git. Another |
| 25 | 25 | team member just checked some stuff into trunk that should have been on |
| 26 | 26 | a branch. Nothing else had happened since, so in fossil I would have |
| 27 | 27 | just edited that commit and put it on a new branch. In git that can't |
| 28 | 28 | actually be done without danger once other people have pulled, so I had |
| @@ -30,15 +30,15 @@ | ||
| 30 | 30 | pick the earlier changes, then figure out how to make my new branch |
| 31 | 31 | shared instead of private. Just want to say thanks for fossil making my |
| 32 | 32 | life easier on most of my projects, and being able to move commits to |
| 33 | 33 | another branch after the fact and shared-by-default branches are good |
| 34 | 34 | features. Also not having a misanthropic command line interface. |
| 35 | -</blockquote> | |
| 35 | +</div> | |
| 36 | 36 | |
| 37 | 37 | <b>Stephan Beal writes on 2009-01-11:</b> |
| 38 | 38 | |
| 39 | -<blockquote> | |
| 39 | +<div class="indent"> | |
| 40 | 40 | Sometime in late 2007 I came across a link to fossil on |
| 41 | 41 | <a href="http://www.sqlite.org/">sqlite.org</a>. It |
| 42 | 42 | was a good thing I bookmarked it, because I was never able to find the |
| 43 | 43 | link again (it might have been in a bug report or something). The |
| 44 | 44 | reasons I first took a close look at it were (A) it stemmed from the |
| @@ -135,6 +135,6 @@ | ||
| 135 | 135 | sitting on our hard drives but which don't justify the hassle of |
| 136 | 136 | version control)." A year of daily use in over 15 source trees has |
| 137 | 137 | confirmed that, and I continue to heartily recommend fossil to other |
| 138 | 138 | developers I know who also have their own collection of "unhosted" pet |
| 139 | 139 | projects. |
| 140 | -</blockquote> | |
| 140 | +</div> | |
| 141 | 141 |
| --- www/reviews.wiki | |
| +++ www/reviews.wiki | |
| @@ -8,21 +8,21 @@ | |
| 8 | |
| 9 | * [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes] |
| 10 | |
| 11 | <b>Daniel writes on 2009-01-06:</b> |
| 12 | |
| 13 | <blockquote> |
| 14 | The reasons I use fossil are that it's the only version control I |
| 15 | have found that I can get working through the VERY annoying MS |
| 16 | firewalls at work.. (albeit through an ntlm proxy) and I just love |
| 17 | single .exe applications! |
| 18 | </blockquote> |
| 19 | |
| 20 | |
| 21 | <b>Joshua Paine on 2010-10-22:</b> |
| 22 | |
| 23 | <blockquote> |
| 24 | With one of my several hats on, I'm in a small team using git. Another |
| 25 | team member just checked some stuff into trunk that should have been on |
| 26 | a branch. Nothing else had happened since, so in fossil I would have |
| 27 | just edited that commit and put it on a new branch. In git that can't |
| 28 | actually be done without danger once other people have pulled, so I had |
| @@ -30,15 +30,15 @@ | |
| 30 | pick the earlier changes, then figure out how to make my new branch |
| 31 | shared instead of private. Just want to say thanks for fossil making my |
| 32 | life easier on most of my projects, and being able to move commits to |
| 33 | another branch after the fact and shared-by-default branches are good |
| 34 | features. Also not having a misanthropic command line interface. |
| 35 | </blockquote> |
| 36 | |
| 37 | <b>Stephan Beal writes on 2009-01-11:</b> |
| 38 | |
| 39 | <blockquote> |
| 40 | Sometime in late 2007 I came across a link to fossil on |
| 41 | <a href="http://www.sqlite.org/">sqlite.org</a>. It |
| 42 | was a good thing I bookmarked it, because I was never able to find the |
| 43 | link again (it might have been in a bug report or something). The |
| 44 | reasons I first took a close look at it were (A) it stemmed from the |
| @@ -135,6 +135,6 @@ | |
| 135 | sitting on our hard drives but which don't justify the hassle of |
| 136 | version control)." A year of daily use in over 15 source trees has |
| 137 | confirmed that, and I continue to heartily recommend fossil to other |
| 138 | developers I know who also have their own collection of "unhosted" pet |
| 139 | projects. |
| 140 | </blockquote> |
| 141 |
| --- www/reviews.wiki | |
| +++ www/reviews.wiki | |
| @@ -8,21 +8,21 @@ | |
| 8 | |
| 9 | * [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes] |
| 10 | |
| 11 | <b>Daniel writes on 2009-01-06:</b> |
| 12 | |
| 13 | <div class="indent"> |
| 14 | The reasons I use fossil are that it's the only version control I |
| 15 | have found that I can get working through the VERY annoying MS |
| 16 | firewalls at work.. (albeit through an ntlm proxy) and I just love |
| 17 | single .exe applications! |
| 18 | </div> |
| 19 | |
| 20 | |
| 21 | <b>Joshua Paine on 2010-10-22:</b> |
| 22 | |
| 23 | <div class="indent"> |
| 24 | With one of my several hats on, I'm in a small team using git. Another |
| 25 | team member just checked some stuff into trunk that should have been on |
| 26 | a branch. Nothing else had happened since, so in fossil I would have |
| 27 | just edited that commit and put it on a new branch. In git that can't |
| 28 | actually be done without danger once other people have pulled, so I had |
| @@ -30,15 +30,15 @@ | |
| 30 | pick the earlier changes, then figure out how to make my new branch |
| 31 | shared instead of private. Just want to say thanks for fossil making my |
| 32 | life easier on most of my projects, and being able to move commits to |
| 33 | another branch after the fact and shared-by-default branches are good |
| 34 | features. Also not having a misanthropic command line interface. |
| 35 | </div> |
| 36 | |
| 37 | <b>Stephan Beal writes on 2009-01-11:</b> |
| 38 | |
| 39 | <div class="indent"> |
| 40 | Sometime in late 2007 I came across a link to fossil on |
| 41 | <a href="http://www.sqlite.org/">sqlite.org</a>. It |
| 42 | was a good thing I bookmarked it, because I was never able to find the |
| 43 | link again (it might have been in a bug report or something). The |
| 44 | reasons I first took a close look at it were (A) it stemmed from the |
| @@ -135,6 +135,6 @@ | |
| 135 | sitting on our hard drives but which don't justify the hassle of |
| 136 | version control)." A year of daily use in over 15 source trees has |
| 137 | confirmed that, and I continue to heartily recommend fossil to other |
| 138 | developers I know who also have their own collection of "unhosted" pet |
| 139 | projects. |
| 140 | </div> |
| 141 |
+8
-12
| --- www/webui.wiki | ||
| +++ www/webui.wiki | ||
| @@ -32,14 +32,14 @@ | ||
| 32 | 32 | the entire [./index.wiki | Fossil website], |
| 33 | 33 | including the document you are now reading, |
| 34 | 34 | is rendered using the Fossil web interface, with no enhancements, |
| 35 | 35 | and little customization. |
| 36 | 36 | |
| 37 | -<blockquote> | |
| 37 | +<p class="indent"> | |
| 38 | 38 | <b>Key point:</b> <i>The Fossil website is just a running instance |
| 39 | 39 | of Fossil! |
| 40 | -</blockquote> | |
| 40 | +</p> | |
| 41 | 41 | |
| 42 | 42 | Note also that because Fossil is a distributed system, you can run |
| 43 | 43 | the web interface on your local machine while off network (for example, |
| 44 | 44 | while on an airplane) including |
| 45 | 45 | making changes to wiki pages and/or trouble ticket, then synchronize with your |
| @@ -50,19 +50,19 @@ | ||
| 50 | 50 | <h2>Very Simple Startup</h2> |
| 51 | 51 | |
| 52 | 52 | To start using the built-in Fossil web interface on an existing Fossil |
| 53 | 53 | repository, simply type this: |
| 54 | 54 | |
| 55 | - <b>fossil ui existing-repository.fossil</b> | |
| 55 | +<pre>fossil ui existing-repository.fossil</pre> | |
| 56 | 56 | |
| 57 | 57 | Substitute the name of your repository, of course. |
| 58 | 58 | The "ui" command will start a web server running (it figures out an |
| 59 | 59 | available TCP port to use on its own) and then automatically launches |
| 60 | 60 | your web browser to point at that server. If you run the "ui" command |
| 61 | 61 | from within an open check-out, you can omit the repository name: |
| 62 | 62 | |
| 63 | - <b>fossil ui</b> | |
| 63 | +<pre>fossil ui</pre> | |
| 64 | 64 | |
| 65 | 65 | The latter case is a very useful short-cut when you are working on a |
| 66 | 66 | Fossil project and you want to quickly do some work with the web interface. |
| 67 | 67 | Notice that Fossil automatically finds an unused TCP port to run the |
| 68 | 68 | server on and automatically points your web browser to the correct |
| @@ -153,14 +153,12 @@ | ||
| 153 | 153 | run Fossil as CGI, just put the |
| 154 | 154 | <b>sample-project.fossil</b> file in a directory where CGI scripts |
| 155 | 155 | have both read and write permission on the file and the directory that |
| 156 | 156 | contains the file, then add a CGI script that looks something like this: |
| 157 | 157 | |
| 158 | - <verbatim> | |
| 159 | - #!/usr/local/bin/fossil | |
| 160 | - repository: /home/www/sample-project.fossil | |
| 161 | - </verbatim> | |
| 158 | +<verbatim> #!/usr/local/bin/fossil | |
| 159 | + repository: /home/www/sample-project.fossil</verbatim> | |
| 162 | 160 | |
| 163 | 161 | Adjust the script above so that the paths are correct for your system, |
| 164 | 162 | of course, and also make sure the Fossil binary is installed on the server. |
| 165 | 163 | But that is <u>all</u> you have to do. You now have everything you need to host |
| 166 | 164 | a distributed software development project in less than five minutes using a |
| @@ -173,13 +171,11 @@ | ||
| 173 | 171 | server machine? |
| 174 | 172 | Not a problem. The Fossil interface can also be launched via inetd or |
| 175 | 173 | xinetd. An inetd configuration line sufficient to launch the Fossil |
| 176 | 174 | web interface looks like this: |
| 177 | 175 | |
| 178 | - <verbatim> | |
| 179 | - 80 stream tcp nowait.1000 root /usr/local/bin/fossil \ | |
| 180 | - /usr/local/bin/fossil http /home/www/sample-project.fossil | |
| 181 | - </verbatim> | |
| 176 | +<verbatim> 80 stream tcp nowait.1000 root /usr/local/bin/fossil \ | |
| 177 | + /usr/local/bin/fossil http /home/www/sample-project.fossil</verbatim> | |
| 182 | 178 | |
| 183 | 179 | As always, you'll want to adjust the pathnames to whatever is appropriate |
| 184 | 180 | for your system. The xinetd setup uses a different syntax but follows |
| 185 | 181 | the same idea. |
| 186 | 182 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -32,14 +32,14 @@ | |
| 32 | the entire [./index.wiki | Fossil website], |
| 33 | including the document you are now reading, |
| 34 | is rendered using the Fossil web interface, with no enhancements, |
| 35 | and little customization. |
| 36 | |
| 37 | <blockquote> |
| 38 | <b>Key point:</b> <i>The Fossil website is just a running instance |
| 39 | of Fossil! |
| 40 | </blockquote> |
| 41 | |
| 42 | Note also that because Fossil is a distributed system, you can run |
| 43 | the web interface on your local machine while off network (for example, |
| 44 | while on an airplane) including |
| 45 | making changes to wiki pages and/or trouble ticket, then synchronize with your |
| @@ -50,19 +50,19 @@ | |
| 50 | <h2>Very Simple Startup</h2> |
| 51 | |
| 52 | To start using the built-in Fossil web interface on an existing Fossil |
| 53 | repository, simply type this: |
| 54 | |
| 55 | <b>fossil ui existing-repository.fossil</b> |
| 56 | |
| 57 | Substitute the name of your repository, of course. |
| 58 | The "ui" command will start a web server running (it figures out an |
| 59 | available TCP port to use on its own) and then automatically launches |
| 60 | your web browser to point at that server. If you run the "ui" command |
| 61 | from within an open check-out, you can omit the repository name: |
| 62 | |
| 63 | <b>fossil ui</b> |
| 64 | |
| 65 | The latter case is a very useful short-cut when you are working on a |
| 66 | Fossil project and you want to quickly do some work with the web interface. |
| 67 | Notice that Fossil automatically finds an unused TCP port to run the |
| 68 | server on and automatically points your web browser to the correct |
| @@ -153,14 +153,12 @@ | |
| 153 | run Fossil as CGI, just put the |
| 154 | <b>sample-project.fossil</b> file in a directory where CGI scripts |
| 155 | have both read and write permission on the file and the directory that |
| 156 | contains the file, then add a CGI script that looks something like this: |
| 157 | |
| 158 | <verbatim> |
| 159 | #!/usr/local/bin/fossil |
| 160 | repository: /home/www/sample-project.fossil |
| 161 | </verbatim> |
| 162 | |
| 163 | Adjust the script above so that the paths are correct for your system, |
| 164 | of course, and also make sure the Fossil binary is installed on the server. |
| 165 | But that is <u>all</u> you have to do. You now have everything you need to host |
| 166 | a distributed software development project in less than five minutes using a |
| @@ -173,13 +171,11 @@ | |
| 173 | server machine? |
| 174 | Not a problem. The Fossil interface can also be launched via inetd or |
| 175 | xinetd. An inetd configuration line sufficient to launch the Fossil |
| 176 | web interface looks like this: |
| 177 | |
| 178 | <verbatim> |
| 179 | 80 stream tcp nowait.1000 root /usr/local/bin/fossil \ |
| 180 | /usr/local/bin/fossil http /home/www/sample-project.fossil |
| 181 | </verbatim> |
| 182 | |
| 183 | As always, you'll want to adjust the pathnames to whatever is appropriate |
| 184 | for your system. The xinetd setup uses a different syntax but follows |
| 185 | the same idea. |
| 186 |
| --- www/webui.wiki | |
| +++ www/webui.wiki | |
| @@ -32,14 +32,14 @@ | |
| 32 | the entire [./index.wiki | Fossil website], |
| 33 | including the document you are now reading, |
| 34 | is rendered using the Fossil web interface, with no enhancements, |
| 35 | and little customization. |
| 36 | |
| 37 | <p class="indent"> |
| 38 | <b>Key point:</b> <i>The Fossil website is just a running instance |
| 39 | of Fossil! |
| 40 | </p> |
| 41 | |
| 42 | Note also that because Fossil is a distributed system, you can run |
| 43 | the web interface on your local machine while off network (for example, |
| 44 | while on an airplane) including |
| 45 | making changes to wiki pages and/or trouble ticket, then synchronize with your |
| @@ -50,19 +50,19 @@ | |
| 50 | <h2>Very Simple Startup</h2> |
| 51 | |
| 52 | To start using the built-in Fossil web interface on an existing Fossil |
| 53 | repository, simply type this: |
| 54 | |
| 55 | <pre>fossil ui existing-repository.fossil</pre> |
| 56 | |
| 57 | Substitute the name of your repository, of course. |
| 58 | The "ui" command will start a web server running (it figures out an |
| 59 | available TCP port to use on its own) and then automatically launches |
| 60 | your web browser to point at that server. If you run the "ui" command |
| 61 | from within an open check-out, you can omit the repository name: |
| 62 | |
| 63 | <pre>fossil ui</pre> |
| 64 | |
| 65 | The latter case is a very useful short-cut when you are working on a |
| 66 | Fossil project and you want to quickly do some work with the web interface. |
| 67 | Notice that Fossil automatically finds an unused TCP port to run the |
| 68 | server on and automatically points your web browser to the correct |
| @@ -153,14 +153,12 @@ | |
| 153 | run Fossil as CGI, just put the |
| 154 | <b>sample-project.fossil</b> file in a directory where CGI scripts |
| 155 | have both read and write permission on the file and the directory that |
| 156 | contains the file, then add a CGI script that looks something like this: |
| 157 | |
| 158 | <verbatim> #!/usr/local/bin/fossil |
| 159 | repository: /home/www/sample-project.fossil</verbatim> |
| 160 | |
| 161 | Adjust the script above so that the paths are correct for your system, |
| 162 | of course, and also make sure the Fossil binary is installed on the server. |
| 163 | But that is <u>all</u> you have to do. You now have everything you need to host |
| 164 | a distributed software development project in less than five minutes using a |
| @@ -173,13 +171,11 @@ | |
| 171 | server machine? |
| 172 | Not a problem. The Fossil interface can also be launched via inetd or |
| 173 | xinetd. An inetd configuration line sufficient to launch the Fossil |
| 174 | web interface looks like this: |
| 175 | |
| 176 | <verbatim> 80 stream tcp nowait.1000 root /usr/local/bin/fossil \ |
| 177 | /usr/local/bin/fossil http /home/www/sample-project.fossil</verbatim> |
| 178 | |
| 179 | As always, you'll want to adjust the pathnames to whatever is appropriate |
| 180 | for your system. The xinetd setup uses a different syntax but follows |
| 181 | the same idea. |
| 182 |