Allowed cards in the manifest are as follows:

<blockquote>
<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>SHA1-hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br>

<b>N</b> <i>mimetype</i><br>
<b>P</b> <i>SHA1-hash</i>+<br>
<b>Q</b> (<b>+</b>|<b>-</b>)<i>SHA1-hash</i> ?<i>SHA1-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>

The format must be one of:

<blockquote>
<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>
</blockquote>

A manifest has zero or more F-cards.  Each F-card identifies a file or
subdirectory
that is part of the check-in.  There are one, two, three, or four
arguments.  The first argument is the pathname of the file or
subdirectory 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 C-card comment text.  Backslash characters and
newlines are not allowed within filenames.  The directory separator
character is a forward slash (ASCII 0x2F).  The second argument to the
F-card is the full 40-character lower-case hexadecimal SHA1 hash of
the content artifact, or of the [#directory|directory artifact] if
the "d" permission is present.  The second argument is required for baseline
manifests but is optional for delta manifests.  When the second
argument to the F-card is omitted, it means that the file has been
deleted relative to the baseline (files removed in baseline manifests
versions are <em>not</em> added as F-cards). The optional 3rd argument
defines any special access permissions associated with the file.  This

can be defined as "x" to mean that the file is executable or "l"
(small letter ell) to mean a symlink or "d" to mean the entry describes
a subdirectory rather than a file.  All files and subdirectories 
are always readable and writable.  This can be expressed by "w" 
permission if desired but the "w" permission is optional and is ignored
by Fossil.  The file format might be extended with new permission
letters in the future.  The optional 4th argument is the name of the
same file as it existed in the parent check-in.  If the name of the
file is unchanged from its parent, then the 4th argument is omitted.

Manifests may be either flat or hierarchical.  A flat manifest lists
all files in the check-in, including all files in subdirectories.  A
flat manifest may not include F-cards with the "d" permission.  An
heirarchical manifest only lists the files or subdirectories at the
top-level of the check-in.  An heirarchical manifest may not include
an F-card entries that have a directory separator character ("/").  
An heirarchical manifest may not be a delta-manifest (it may not have
a B-card) nor may it be used as a baseline-manifest by some other
delta-manifest.  Hierarchical manifests
are only recognized by Fossil versions 1.35 and later.  Repositories
that contain hierarchical manifests will cause problems for earlier
versions of Fossil.

When an F-card refers to a subdirectory (that is to say, when the
F-card is part of an hierarchical manifest and contains the "d"
permission) then the referenced directory artifact must be a 
[#directory|well-formed directory artifact] that contains a
G-card that exactly matches the name of the subdirectory as assigned

by the F-card.  If these conditions are not met, then the artifact is

not a valid manifest.

A manifest has zero or one P-cards.  Most manifests have one P-card.
The P-card has a varying number of arguments that
defines other manifests from which the current manifest
is derived.  Each argument is an 40-character lowercase 
hexadecimal SHA1 of the predecessor manifest.  All arguments
to the P-card must be unique to that line.

<h3>1.2 Directory Artifacts</h3>

A directory artifact describes the files and subdirectories within a
single directory of an hierarchical manifest.  Directory artifacts
are only recognized by Fossil version 1.35 and later (circa 2015-12-23).

Directory artifacts contain zero or more F-cards and exactly one Z-card,
in the same format as a manifest.  A directory artifact also contains
exactly one G-card with a single argument that is the pathname
of the directory relative to the root of the repository.
The format of the directory name in a G-card is
the same as the format of a filename in an F-card.


The F-cards in a directory artifact may not contain directory separator

characters.  The content of subdirectories must be expressed using


additional directory artifacts referenced by F-cards with the "d"

permission.  All F-cards in a directory artifact must contain at least
two arguments.

When an F-card X of directory artifact Y refers to 
subdirectory Z (that is to say, when F-card X contains
the "d" permission and the second argument on X is the SHA1
hash of directory artifact Z) then the G-card of Z must
be the concatenation of the G-card on artifact Y, the
directory separator character "/" and the first argument to
the F-card X.  Otherwise, the artifact Y is not a valid
directory artifact.


<a name="cluster"></a>
<h3>1.3 Clusters Artifacts</h3>

A cluster is an artifact that declares the existence of other artifacts.
Clusters are used during repository synchronization to help 
reduce network traffic.  As such, clusters are an optimization and

<td>&nbsp;</td>
<td>&nbsp;</td>
<td align=center><b>1</b></td>
<td>&nbsp;</td>
</tr>
<tr>
<td><b>B</b> <i>baseline</i></td>
<td align=center><b>0-1*</b></td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr><td>&nbsp;</td><td colspan='8'>* = Required for delta manifests,
Disallowed for hierarchical manifests.</td></tr>
<tr>
<td><b>C</b> <i>comment-text</i></td>
<td align=center><b>1</b></td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align=center><b>0-1</b></td>
<td align=center><b>0-1</b></td>
</tr>
<tr>
<td><b>D</b> <i>date-time-stamp</i></td>
<td align=center><b>1</b></td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td align=center><b>1</b></td>

<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>
<tr>
<td><b>G</b> <i>fileame</i>

<td>&nbsp;</td>
<td align=center><b>1</b></td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
<td>&nbsp;</td>
</tr>

manifests.  That means that all the files of a check-in had to be
listed in every manifest.  Because manifests are delta-encoded, there
is not a storage space issue.  Fossil was originally designed
specifically to support the SQLite project, and as SQLite has fewer
than 2000 files on any give version, a flat baseline manifest design
worked well there and was simple to implement.

However, some project (ex: NetBSD) contain a huge number of files in
every version, and even though the manifests compressed will using
delta-compression, many CPU cycles had to be spent to decompress those
manifests.  To help make Fossil more efficient for large projects like
NetBSD, the concept of a delta-manifest was added.  This helped a lot
but was not a perfect solution.

Later, the concept of an hierarchical manifest was added.  By breaking
up each manifest into many separate subdirectories it is hoped that