1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
<h1 align="center">
Fossil File Formats
</h1>
<p>The state of a fossil repository is kept simple so that it can
endure in useful form for decades or centuries.
A fossil repository is intended to be readable,
searchable, and extensible by people not yet born.</p>
<p>
The global state of a fossil repository is determined by an unordered
set of <i>artifacts</i>.
An artifact might be a source code file, the text of a wiki page,
part of a trouble ticket, or one of several special control artifacts
used to show the relationships between other artifacts within the
project. Each artifact is normally represented on disk as a separate
file. Artifacts can be text or binary.
</p>
<p>
Each artifact in the repository is named by its SHA1 hash.
No prefixes or meta information is added to a artifact before
its hash is computed. The name of a artifact in the repository
is exactly the same SHA1 hash that is computed by sha1sum
on the file as it exists in your source tree.</p>
|
|
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
<h1 align="center">
Fossil File Formats
</h1>
<p>The global state of a fossil repository is kept simple so that it can
endure in useful form for decades or centuries.
A fossil repository is intended to be readable,
searchable, and extensible by people not yet born.</p>
<p>
The global state of a fossil repository is an unordered
set of <i>artifacts</i>.
An artifact might be a source code file, the text of a wiki page,
part of a trouble ticket, or one of several special control artifacts
used to show the relationships between other artifacts within the
project. Each artifact is normally represented on disk as a separate
file. Artifacts can be text or binary.
</p>
<p>
In addition to the global state,
each fossil repository also contains local state.
The local state consists of web-page formatting
preferences, authorized users, ticket display and reporting formats,
and so forth. The global state is shared in common among all
repositories for the same project, whereas the local state is often
different in separate repositories.
The local state is not versioned and is not synchronized
with the global state.
The local state is not composed of artifacts and is not intended to be enduring.
This document is concerned with global state only. Local state is only
mentioned here in order to distinguish it from global state.
</p>
<p>
Each artifact in the repository is named by its SHA1 hash.
No prefixes or meta information is added to a artifact before
its hash is computed. The name of a artifact in the repository
is exactly the same SHA1 hash that is computed by sha1sum
on the file as it exists in your source tree.</p>
|
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
|
<h2>5.0 Ticket Changes</h2>
<p>A ticket-change artifact represents a change to a trouble ticket.
The following cards are allowed on a ticket change artifact:</p>
<blockquote>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>J</b> ?<b>+</b>?<i>name 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>
</blockquote>
<p>
The D card is the usual date and time stamp and represents the point
in time when the change was entered. The U card is the login of the
programmer who entered this change. The Z card is the checksum over
the entire artifact.</p>
<p>
Every ticket has a unique ID. The ticket to which this change is applied
is specified by the K card. A ticket exists if it contains one or
more changes. The first "change" to a ticket is what brings the
ticket into existance.</p>
<p>
J cards specify changes to "fields" of the ticket. Each fossil
server has a ticket configuration which specifies the fields its
understands. This is not a limit on the fields that can appear
on the J cards, however. If a J card specifies a field that a
particular fossil server does not recognize, then that J card
is simply ignored.</p>
<p>
The first argument of the J card is the field name. The second
value is the field value. If the field name begins with "+" then
the value is appended to the prior value. Otherwise, the value
on the J card replaces any previous value of the field.
The field name and value are both encoded using the character
escapes defined for the C card of a manifest.
</p>
|
|
|
>
>
|
|
>
>
|
|
|
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
|
<h2>5.0 Ticket Changes</h2>
<p>A ticket-change artifact represents a change to a trouble ticket.
The following cards are allowed on a ticket change artifact:</p>
<blockquote>
<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>
</blockquote>
<p>
The D card is the usual date and time stamp and represents the point
in time when the change was entered. The U card is the login of the
programmer who entered this change. The Z card is the checksum over
the entire artifact.</p>
<p>
Every ticket has a unique ID. The ticket to which this change is applied
is specified by the K card. A ticket exists if it contains one or
more changes. The first "change" to a ticket is what brings the
ticket into existance.</p>
<p>
J cards specify changes to the "value" of "fields" in the ticket.
If the <i>value</i> parameter of the J card is omitted, then the
field is set to an empty string.
Each fossil server has a ticket configuration which specifies the fields its
understands. The ticket configuration is part of the local state for
the repository and thus can vary from one repository to another.
Hencd a J card might specify a <i>field</i> that do not exist in the
local ticket configuration. If a J card specifies a <i>field</i> that
is not in the local configuration, then that J card
is simply ignored.</p>
<p>
The first argument of the J card is the field name. The second
value is the field value. If the field name begins with "+" then
the value is appended to the prior value. Otherwise, the value
on the J card replaces any previous value of the field.
The field name and value are both encoded using the character
escapes defined for the C card of a manifest.
</p>
|