Fossil

Check-in [d8e2a3b874]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:The skin's new "indent" class for block elements doesn't apply to "p" tags due to CSS cascading rules. Changed them to divs to sidestep this limitation. Also fixed another instance of bold formatting interfering with abutting italics.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: d8e2a3b87402a496d4ee2573cb2a9d35b75dbf05aeaf41a660cce8896c724655
User & Date: wyoung 2024-02-18 13:25:57.148
Context
2024-02-18
13:27
Removed manual indents in verbatim blocks in forum doc. check-in: 6c9755b9a6 user: wyoung tags: trunk
13:25
The skin's new "indent" class for block elements doesn't apply to "p" tags due to CSS cascading rules. Changed them to divs to sidestep this limitation. Also fixed another instance of bold formatting interfering with abutting italics. check-in: d8e2a3b874 user: wyoung tags: trunk
13:19
Modernized table-based formatting in delta_encoder_algorithm doc. check-in: 65853cc1e4 user: wyoung tags: trunk
Changes
Unified Diff Ignore Whitespace Patch
Changes to www/fileformat.wiki.
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
well as information such as parent check-ins, the username of the
programmer who created the check-in, the date and time when
the check-in was created, and any check-in comments associated
with the check-in.

Allowed cards in the manifest are as follows:

<p class="indent">
<b>B</b> <i>baseline-manifest</i><br>
<b>C</b> <i>checkin-comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br>
<b>F</b> <i>filename</i> ?<i>hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br>
<b>N</b> <i>mimetype</i><br>
<b>P</b> <i>artifact-hash</i>+<br>
<b>Q</b> (<b>+</b>|<b>-</b>)<i>artifact-hash</i> ?<i>artifact-hash</i>?<br>
<b>R</b> <i>repository-checksum</i><br>
<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <b>*</b> ?<i>value</i>?<br>
<b>U</b> <i>user-login</i><br>
<b>Z</b> <i>manifest-checksum</i>
</p>

A manifest may optionally have a single <b>B</b> card.  The <b>B</b> card specifies
another manifest that serves as the "baseline" for this manifest.  A
manifest that has a <b>B</b> card is called a delta-manifest and a manifest
that omits the <b>B</b> card is a baseline-manifest.  The other manifest
identified by the argument of the <b>B</b> card must be a baseline-manifest.
A baseline-manifest records the complete contents of a check-in.







|











|







105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
well as information such as parent check-ins, the username of the
programmer who created the check-in, the date and time when
the check-in was created, and any check-in comments associated
with the check-in.

Allowed cards in the manifest are as follows:

<div class="indent">
<b>B</b> <i>baseline-manifest</i><br>
<b>C</b> <i>checkin-comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br>
<b>F</b> <i>filename</i> ?<i>hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br>
<b>N</b> <i>mimetype</i><br>
<b>P</b> <i>artifact-hash</i>+<br>
<b>Q</b> (<b>+</b>|<b>-</b>)<i>artifact-hash</i> ?<i>artifact-hash</i>?<br>
<b>R</b> <i>repository-checksum</i><br>
<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <b>*</b> ?<i>value</i>?<br>
<b>U</b> <i>user-login</i><br>
<b>Z</b> <i>manifest-checksum</i>
</div>

A manifest may optionally have a single <b>B</b> card.  The <b>B</b> card specifies
another manifest that serves as the "baseline" for this manifest.  A
manifest that has a <b>B</b> card is called a delta-manifest and a manifest
that omits the <b>B</b> card is a baseline-manifest.  The other manifest
identified by the argument of the <b>B</b> card must be a baseline-manifest.
A baseline-manifest records the complete contents of a check-in.
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
in the comment.

A manifest must have exactly one <b>D</b> card.  The sole argument to
the <b>D</b> card is a date-time stamp in the ISO8601 format.  The
date and time should be in coordinated universal time (UTC).
The format one of:

<p class="indent">
<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>
<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>
</p>

A manifest has zero or more <b>F</b> cards.  Each <b>F</b> card identifies a file
that is part of the check-in.  There are one, two, three, or four
arguments.  The first argument is the pathname of the file in the
check-in relative to the root of the project file hierarchy.  No ".."
or "." directories are allowed within the filename.  Space characters
are escaped as in <b>C</b> card comment text.  Backslash characters and







|
<
<
|







143
144
145
146
147
148
149
150


151
152
153
154
155
156
157
158
in the comment.

A manifest must have exactly one <b>D</b> card.  The sole argument to
the <b>D</b> card is a date-time stamp in the ISO8601 format.  The
date and time should be in coordinated universal time (UTC).
The format one of:

<pre class="indent"><i>YYYY-MM-DD<b>T</b>HH:MM:SS


YYYY-MM-DD<b>T</b>HH:MM:SS.SSS</i></pre>

A manifest has zero or more <b>F</b> cards.  Each <b>F</b> card identifies a file
that is part of the check-in.  There are one, two, three, or four
arguments.  The first argument is the pathname of the file in the
check-in relative to the root of the project file hierarchy.  No ".."
or "." directories are allowed within the filename.  Space characters
are escaped as in <b>C</b> card comment text.  Backslash characters and
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
Clusters are used during repository synchronization to help
reduce network traffic.  As such, clusters are an optimization and
may be removed from a repository without loss or damage to the
underlying project code.

Allowed cards in the cluster are as follows:

<p class="indent">
<b>M</b> <i>artifact-id</i><br />
<b>Z</b> <i>checksum</i>
</p>

A cluster contains one or more <b>M</b> cards followed by a single <b>Z</b> card.
Each <b>M</b> card has a single argument which is the artifact ID of
another artifact in the repository.  The <b>Z</b> card works exactly like
the <b>Z</b> card of a manifest.  The argument to the <b>Z</b> card is the
lower-case hexadecimal representation of the MD5 checksum of all
prior cards in the cluster.  The <b>Z</b> card is required.

An example cluster from Fossil can be seen
[/artifact/d03dbdd73a2a8 | here].

<h3 id="ctrl">2.3 Control Artifacts</h3>

Control artifacts are used to assign properties to other artifacts
within the repository.
Allowed cards in a control artifact are as follows:

<p class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <i>artifact-id</i> ?<i>value</i>?<br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i><br />
</p>

A control artifact must have one <b>D</b> card, one <b>U</b> card, one <b>Z</b> card and
one or more <b>T</b> cards.  No other cards or other text is
allowed in a control artifact.  Control artifacts might be PGP
clearsigned.

The <b>D</b> card and the <b>Z</b> card of a control artifact are the same







|


|

















|




|







256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
Clusters are used during repository synchronization to help
reduce network traffic.  As such, clusters are an optimization and
may be removed from a repository without loss or damage to the
underlying project code.

Allowed cards in the cluster are as follows:

<div class="indent">
<b>M</b> <i>artifact-id</i><br />
<b>Z</b> <i>checksum</i>
</div>

A cluster contains one or more <b>M</b> cards followed by a single <b>Z</b> card.
Each <b>M</b> card has a single argument which is the artifact ID of
another artifact in the repository.  The <b>Z</b> card works exactly like
the <b>Z</b> card of a manifest.  The argument to the <b>Z</b> card is the
lower-case hexadecimal representation of the MD5 checksum of all
prior cards in the cluster.  The <b>Z</b> card is required.

An example cluster from Fossil can be seen
[/artifact/d03dbdd73a2a8 | here].

<h3 id="ctrl">2.3 Control Artifacts</h3>

Control artifacts are used to assign properties to other artifacts
within the repository.
Allowed cards in a control artifact are as follows:

<div class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <i>artifact-id</i> ?<i>value</i>?<br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i><br />
</div>

A control artifact must have one <b>D</b> card, one <b>U</b> card, one <b>Z</b> card and
one or more <b>T</b> cards.  No other cards or other text is
allowed in a control artifact.  Control artifacts might be PGP
clearsigned.

The <b>D</b> card and the <b>Z</b> card of a control artifact are the same
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
<h3 id="wikichng">2.4 Wiki Pages</h3>

A wiki artifact defines a single version of a
single wiki page.
Wiki artifacts accept
the following card types:

<p class="indent">
<b>C</b> <i>change-comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>L</b> <i>wiki-title</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i>+<br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>D</b> card is the date and time when the wiki page was edited.
The <b>P</b> card specifies the parent wiki pages, if any.  The <b>L</b> card
gives the name of the wiki page.  The optional <b>N</b> card specifies
the mimetype of the wiki text.  If the <b>N</b> card is omitted, the
mimetype is assumed to be text/x-fossil-wiki.
The <b>U</b> card specifies the login







|








|







331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
<h3 id="wikichng">2.4 Wiki Pages</h3>

A wiki artifact defines a single version of a
single wiki page.
Wiki artifacts accept
the following card types:

<div class="indent">
<b>C</b> <i>change-comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>L</b> <i>wiki-title</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i>+<br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</div>

The <b>D</b> card is the date and time when the wiki page was edited.
The <b>P</b> card specifies the parent wiki pages, if any.  The <b>L</b> card
gives the name of the wiki page.  The optional <b>N</b> card specifies
the mimetype of the wiki text.  If the <b>N</b> card is omitted, the
mimetype is assumed to be text/x-fossil-wiki.
The <b>U</b> card specifies the login
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
[/artifact?name=7b2f5fd0e0&txt=1 | here].

<h3 id="tktchng">2.5 Ticket Changes</h3>

A ticket-change artifact represents a change to a trouble ticket.
The following cards are allowed on a ticket change artifact:

<p class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br />
<b>K</b> <i>ticket-id</i><br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>D</b> card is the usual date and time stamp and represents the point
in time when the change was entered.  The <b>U</b> card is the login of the
programmer who entered this change.  The <b>Z</b> card is the required checksum over
the entire artifact.

Every ticket has a distinct ticket-id:







|





|







372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
[/artifact?name=7b2f5fd0e0&txt=1 | here].

<h3 id="tktchng">2.5 Ticket Changes</h3>

A ticket-change artifact represents a change to a trouble ticket.
The following cards are allowed on a ticket change artifact:

<div class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br />
<b>K</b> <i>ticket-id</i><br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i>
</div>

The <b>D</b> card is the usual date and time stamp and represents the point
in time when the change was entered.  The <b>U</b> card is the login of the
programmer who entered this change.  The <b>Z</b> card is the required checksum over
the entire artifact.

Every ticket has a distinct ticket-id:
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443

An attachment artifact associates some other artifact that is the
attachment (the source artifact) with a ticket or wiki page or
technical note to which
the attachment is connected (the target artifact).
The following cards are allowed on an attachment artifact:

<p class="indent">
<b>A</b> <i>filename target</i> ?<i>source</i>?<br />
<b>C</b> <i>comment</i><br />
<b>D</b> <i>time-and-date-stamp</i><br />
<b>N</b> <i>mimetype</i><br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>A</b> card specifies a filename for the attachment in its first argument.
The second argument to the <b>A</b> card is the name of the wiki page or
ticket or technical note to which the attachment is connected.  The
third argument is either missing or else it is the lower-case artifact
ID of the attachment itself.  A missing third argument means that the
attachment should be deleted.







|






|







420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441

An attachment artifact associates some other artifact that is the
attachment (the source artifact) with a ticket or wiki page or
technical note to which
the attachment is connected (the target artifact).
The following cards are allowed on an attachment artifact:

<div class="indent">
<b>A</b> <i>filename target</i> ?<i>source</i>?<br />
<b>C</b> <i>comment</i><br />
<b>D</b> <i>time-and-date-stamp</i><br />
<b>N</b> <i>mimetype</i><br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i>
</div>

The <b>A</b> card specifies a filename for the attachment in its first argument.
The second argument to the <b>A</b> card is the name of the wiki page or
ticket or technical note to which the attachment is connected.  The
third argument is either missing or else it is the lower-case artifact
ID of the attachment itself.  A missing third argument means that the
attachment should be deleted.
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
A technical note or "technote" artifact (formerly known as an "event" artifact)
associates a timeline comment and a page of text
(similar to a wiki page) with a point in time.  Technotes can be used
to record project milestones, release notes, blog entries, process
checkpoints, or news articles.
The following cards are allowed on an technote artifact:

<p class="indent">
<b>C</b> <i>comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>E</b> <i>technote-time</i> <i>technote-id</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i>+<br />
<b>T</b> <b>+</b><i>tag-name</i> <b>*</b> ?<i>value</i>?<br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>C</b> card contains text that is displayed on the timeline for the
technote.  The <b>C</b> card is optional, but there can only be one.

A single <b>D</b> card is required to give the date and time when the
technote artifact was created.  This is different from the time at which
the technote appears on the timeline.







|









|







462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
A technical note or "technote" artifact (formerly known as an "event" artifact)
associates a timeline comment and a page of text
(similar to a wiki page) with a point in time.  Technotes can be used
to record project milestones, release notes, blog entries, process
checkpoints, or news articles.
The following cards are allowed on an technote artifact:

<div class="indent">
<b>C</b> <i>comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>E</b> <i>technote-time</i> <i>technote-id</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i>+<br />
<b>T</b> <b>+</b><i>tag-name</i> <b>*</b> ?<i>value</i>?<br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</div>

The <b>C</b> card contains text that is displayed on the timeline for the
technote.  The <b>C</b> card is optional, but there can only be one.

A single <b>D</b> card is required to give the date and time when the
technote artifact was created.  This is different from the time at which
the technote appears on the timeline.
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
<h3 id="forum">2.8 Forum Posts</h3>

Forum posts are intended as a mechanism for users and developers to
discuss a project.  Forum posts are like messages on a mailing list.

The following cards are allowed on an forum post artifact:

<p class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>G</b> <i>thread-root</i><br />
<b>H</b> <i>thread-title</i><br />
<b>I</b> <i>in-reply-to</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i><br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</p>

Every forum post must have either one <b>I</b> card and one <b>G</b> card
or one <b>H</b> card.
Forum posts are organized into topic threads.  The initial
post for a thread (the root post) has an <b>H</b> card giving the title or
subject for that thread.  The argument to the <b>H</b> card is a string
in the same format as a comment string in a <b>C</b> card.







|









|







527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
<h3 id="forum">2.8 Forum Posts</h3>

Forum posts are intended as a mechanism for users and developers to
discuss a project.  Forum posts are like messages on a mailing list.

The following cards are allowed on an forum post artifact:

<div class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>G</b> <i>thread-root</i><br />
<b>H</b> <i>thread-title</i><br />
<b>I</b> <i>in-reply-to</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i><br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</div>

Every forum post must have either one <b>I</b> card and one <b>G</b> card
or one <b>H</b> card.
Forum posts are organized into topic threads.  The initial
post for a thread (the root post) has an <b>H</b> card giving the title or
subject for that thread.  The argument to the <b>H</b> card is a string
in the same format as a comment string in a <b>C</b> card.
Changes to www/webui.wiki.
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

As an example of how useful this web interface can be,
the entire [./index.wiki | Fossil website],
including the document you are now reading,
is rendered using the Fossil web interface, with no enhancements,
and little customization.

<p class="indent">
<b>Key point:</b> <i>The Fossil website is just a running instance
of Fossil!
</p>

Note also that because Fossil is a distributed system, you can run
the web interface on your local machine while off network (for example,
while on an airplane) including
making changes to wiki pages and/or trouble ticket, then synchronize with your
co-workers after you reconnect.  When you clone a Fossil repository, you
don't just get the project source code, you get the entire project







|


|







30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

As an example of how useful this web interface can be,
the entire [./index.wiki | Fossil website],
including the document you are now reading,
is rendered using the Fossil web interface, with no enhancements,
and little customization.

<div class="indent">
<b>Key point:</b> <i>The Fossil website is just a running instance
of Fossil!
</div>

Note also that because Fossil is a distributed system, you can run
the web interface on your local machine while off network (for example,
while on an airplane) including
making changes to wiki pages and/or trouble ticket, then synchronize with your
co-workers after you reconnect.  When you clone a Fossil repository, you
don't just get the project source code, you get the entire project