61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
not how the artifacts are stored on disk. It is the artifact format that
is intended to be enduring. The specifics of how artifacts are stored on
disk, though stable, is not intended to have as long a lifespan as the
artifact format.</p>
<h2>1.0 The Manifest</h2>
<p>A manifest defines a baseline or version of the project
source tree. The manifest contains a list of artifacts for
each file in the project and the corresponding filenames, as
well as information such as parent baselines, the name of the
programmer who created the baseline, the date and time when
the baseline was created, and any check-in comments associated
with the baseline.</p>
<p>
Any artifact in the repository that follows the syntactic rules
of a manifest is a manifest. Note that a manifest can
be both a real manifest and also a content file, though this
is rare.
</p>
|
|
|
|
|
|
|
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
|
not how the artifacts are stored on disk. It is the artifact format that
is intended to be enduring. The specifics of how artifacts are stored on
disk, though stable, is not intended to have as long a lifespan as the
artifact format.</p>
<h2>1.0 The Manifest</h2>
<p>A manifest defines a check-in or version of the project
source tree. The manifest contains a list of artifacts for
each file in the project and the corresponding filenames, as
well as information such as parent check-ins, the name 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.</p>
<p>
Any artifact in the repository that follows the syntactic rules
of a manifest is a manifest. Note that a manifest can
be both a real manifest and also a content file, though this
is rare.
</p>
|
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
<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>
</blockquote>
<p>
A manifest has zero or more F-cards. Each F-card defines a file
(other than the manifest itself) which is part of the baseline that
the manifest defines. There are two, three, or three arguments.
The first argument
is the pathname of the file in the baseline 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. The optional 3rd argument defines any special access
permissions associated with the file. The only special code currently
defined is "x" which means that the file is executable. All files are
always readable and writable. This can be expressed by "w" permission
if desired but is optional.
The optional 4th argument is the name of the same file as it existed in
the parent baseline. If the name of the file is unchanged from its
parent, then the 4th argument is omitted.
</p>
<p>
A manifest has zero or more N-cards. Each N card records a name changes
to one of the files in the manifest. The first argument to the N code is
the name of the file in the parent baseline. The second argument is the
name of the file in the baseline defined by the manifest.
</p>
<p>
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.
The first predecessor is the direct ancestor of the manifest.
Other arguments define manifests with which the first was
merged to yield the current manifest. Most manifests have
a P-card with a single argument. The first manifest in the
project has no ancestors and thus has no P-card.
</p>
<p>
A manifest may optionally have a single R-card. The R-card has
a single argument which is the MD5 checksum of all files in
the baseline except the manifest itself. The checksum is expressed
as 32-characters of lowercase hexadecimal. The checksum is
computed as follows: For each file in the baseline (except for
the manifest itself) in strict sorted lexicographical order,
take the pathname of the file relative to the root of the
repository, append a single space (ASCII 0x20), the
size of the file in ASCII decimal, a single newline
character (ASCII 0x0A), and the complete text of the file.
Compute the MD5 checksum of the the result.
</p>
|
|
|
|
|
|
|
|
|
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
<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>
</blockquote>
<p>
A manifest has zero or more F-cards. Each F-card defines a file
(other than the manifest itself) which is part of the check-in that
the manifest defines. There are two, three, or three 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 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. The optional 3rd argument defines any special access
permissions associated with the file. The only special code currently
defined is "x" which means that the file is executable. All files are
always readable and writable. This can be expressed by "w" permission
if desired but is optional.
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.
</p>
<p>
A manifest has zero or more N-cards. Each N card records a name changes
to one of the files in the manifest. The first argument to the N code is
the name of the file in the parent check-in. The second argument is the
name of the file in the check-in defined by the manifest.
</p>
<p>
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.
The first predecessor is the direct ancestor of the manifest.
Other arguments define manifests with which the first was
merged to yield the current manifest. Most manifests have
a P-card with a single argument. The first manifest in the
project has no ancestors and thus has no P-card.
</p>
<p>
A manifest may optionally have a single R-card. The R-card has
a single argument which is the MD5 checksum of all files in
the check-in except the manifest itself. The checksum is expressed
as 32-characters of lowercase hexadecimal. The checksum is
computed as follows: For each file in the check-in (except for
the manifest itself) in strict sorted lexicographical order,
take the pathname of the file relative to the root of the
repository, append a single space (ASCII 0x20), the
size of the file in ASCII decimal, a single newline
character (ASCII 0x0A), and the complete text of the file.
Compute the MD5 checksum of the the result.
</p>
|
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
|
without a value is a boolean.</p>
<p>When two or more tags with the same name are applied to the
same artifact, the tag with the latest (most recent) date is
used.</p>
<p>Some tags have special meaning. The "comment" tag when applied
to a baseline will override the check-in comment of that baseline
for display purposes.</p>
<a name="wikichng"></a>
<h2>4.0 Wiki Pages</h2>
<p>A wiki page is an artifact with a format similar to manifests,
clusters, and control artifacts. The artifact is divided into
|
|
|
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
|
without a value is a boolean.</p>
<p>When two or more tags with the same name are applied to the
same artifact, the tag with the latest (most recent) date is
used.</p>
<p>Some tags have special meaning. The "comment" tag when applied
to a check-in will override the check-in comment of that check-in
for display purposes.</p>
<a name="wikichng"></a>
<h2>4.0 Wiki Pages</h2>
<p>A wiki page is an artifact with a format similar to manifests,
clusters, and control artifacts. The artifact is divided into
|