Fossil SCM
Change the default subsystem list for tickets to an empty set. Update documentation to begin making a clearer distinction between local state and global state.
Commit
efb759a07da0ea5c540e2b73ae63d8c636bf8673
Parent
31e94c0a04f2a50…
3 files changed
+2
-1
+27
-8
+29
-3
+2
-1
| --- src/tktsetup.c | ||
| +++ src/tktsetup.c | ||
| @@ -215,11 +215,12 @@ | ||
| 215 | 215 | @ Deferred |
| 216 | 216 | @ Fixed |
| 217 | 217 | @ Tested |
| 218 | 218 | @ Closed |
| 219 | 219 | @ } |
| 220 | -@ set subsystem_choices {one two three} | |
| 220 | +@ set subsystem_choices { | |
| 221 | +@ } | |
| 221 | 222 | ; |
| 222 | 223 | |
| 223 | 224 | /* |
| 224 | 225 | ** Return the ticket common code. |
| 225 | 226 | */ |
| 226 | 227 |
| --- src/tktsetup.c | |
| +++ src/tktsetup.c | |
| @@ -215,11 +215,12 @@ | |
| 215 | @ Deferred |
| 216 | @ Fixed |
| 217 | @ Tested |
| 218 | @ Closed |
| 219 | @ } |
| 220 | @ set subsystem_choices {one two three} |
| 221 | ; |
| 222 | |
| 223 | /* |
| 224 | ** Return the ticket common code. |
| 225 | */ |
| 226 |
| --- src/tktsetup.c | |
| +++ src/tktsetup.c | |
| @@ -215,11 +215,12 @@ | |
| 215 | @ Deferred |
| 216 | @ Fixed |
| 217 | @ Tested |
| 218 | @ Closed |
| 219 | @ } |
| 220 | @ set subsystem_choices { |
| 221 | @ } |
| 222 | ; |
| 223 | |
| 224 | /* |
| 225 | ** Return the ticket common code. |
| 226 | */ |
| 227 |
+27
-8
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -1,24 +1,39 @@ | ||
| 1 | 1 | <h1 align="center"> |
| 2 | 2 | Fossil File Formats |
| 3 | 3 | </h1> |
| 4 | 4 | |
| 5 | -<p>The state of a fossil repository is kept simple so that it can | |
| 5 | +<p>The global state of a fossil repository is kept simple so that it can | |
| 6 | 6 | endure in useful form for decades or centuries. |
| 7 | 7 | A fossil repository is intended to be readable, |
| 8 | 8 | searchable, and extensible by people not yet born.</p> |
| 9 | 9 | |
| 10 | 10 | <p> |
| 11 | -The global state of a fossil repository is determined by an unordered | |
| 11 | +The global state of a fossil repository is an unordered | |
| 12 | 12 | set of <i>artifacts</i>. |
| 13 | 13 | An artifact might be a source code file, the text of a wiki page, |
| 14 | 14 | part of a trouble ticket, or one of several special control artifacts |
| 15 | 15 | used to show the relationships between other artifacts within the |
| 16 | 16 | project. Each artifact is normally represented on disk as a separate |
| 17 | 17 | file. Artifacts can be text or binary. |
| 18 | 18 | </p> |
| 19 | 19 | |
| 20 | +<p> | |
| 21 | +In addition to the global state, | |
| 22 | +each fossil repository also contains local state. | |
| 23 | +The local state consists of web-page formatting | |
| 24 | +preferences, authorized users, ticket display and reporting formats, | |
| 25 | +and so forth. The global state is shared in common among all | |
| 26 | +repositories for the same project, whereas the local state is often | |
| 27 | +different in separate repositories. | |
| 28 | +The local state is not versioned and is not synchronized | |
| 29 | +with the global state. | |
| 30 | +The local state is not composed of artifacts and is not intended to be enduring. | |
| 31 | +This document is concerned with global state only. Local state is only | |
| 32 | +mentioned here in order to distinguish it from global state. | |
| 33 | +</p> | |
| 34 | + | |
| 20 | 35 | <p> |
| 21 | 36 | Each artifact in the repository is named by its SHA1 hash. |
| 22 | 37 | No prefixes or meta information is added to a artifact before |
| 23 | 38 | its hash is computed. The name of a artifact in the repository |
| 24 | 39 | is exactly the same SHA1 hash that is computed by sha1sum |
| @@ -331,11 +346,11 @@ | ||
| 331 | 346 | <p>A ticket-change artifact represents a change to a trouble ticket. |
| 332 | 347 | The following cards are allowed on a ticket change artifact:</p> |
| 333 | 348 | |
| 334 | 349 | <blockquote> |
| 335 | 350 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 336 | -<b>J</b> ?<b>+</b>?<i>name value</i><br /> | |
| 351 | +<b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br /> | |
| 337 | 352 | <b>K</b> <i>ticket-id</i><br /> |
| 338 | 353 | <b>U</b> <i>user-name</i><br /> |
| 339 | 354 | <b>Z</b> <i>checksum</i> |
| 340 | 355 | </blockquote> |
| 341 | 356 | |
| @@ -350,15 +365,19 @@ | ||
| 350 | 365 | is specified by the K card. A ticket exists if it contains one or |
| 351 | 366 | more changes. The first "change" to a ticket is what brings the |
| 352 | 367 | ticket into existance.</p> |
| 353 | 368 | |
| 354 | 369 | <p> |
| 355 | -J cards specify changes to "fields" of the ticket. Each fossil | |
| 356 | -server has a ticket configuration which specifies the fields its | |
| 357 | -understands. This is not a limit on the fields that can appear | |
| 358 | -on the J cards, however. If a J card specifies a field that a | |
| 359 | -particular fossil server does not recognize, then that J card | |
| 370 | +J cards specify changes to the "value" of "fields" in the ticket. | |
| 371 | +If the <i>value</i> parameter of the J card is omitted, then the | |
| 372 | +field is set to an empty string. | |
| 373 | +Each fossil server has a ticket configuration which specifies the fields its | |
| 374 | +understands. The ticket configuration is part of the local state for | |
| 375 | +the repository and thus can vary from one repository to another. | |
| 376 | +Hencd a J card might specify a <i>field</i> that do not exist in the | |
| 377 | +local ticket configuration. If a J card specifies a <i>field</i> that | |
| 378 | +is not in the local configuration, then that J card | |
| 360 | 379 | is simply ignored.</p> |
| 361 | 380 | |
| 362 | 381 | <p> |
| 363 | 382 | The first argument of the J card is the field name. The second |
| 364 | 383 | value is the field value. If the field name begins with "+" then |
| 365 | 384 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -1,24 +1,39 @@ | |
| 1 | <h1 align="center"> |
| 2 | Fossil File Formats |
| 3 | </h1> |
| 4 | |
| 5 | <p>The state of a fossil repository is kept simple so that it can |
| 6 | endure in useful form for decades or centuries. |
| 7 | A fossil repository is intended to be readable, |
| 8 | searchable, and extensible by people not yet born.</p> |
| 9 | |
| 10 | <p> |
| 11 | The global state of a fossil repository is determined by an unordered |
| 12 | set of <i>artifacts</i>. |
| 13 | An artifact might be a source code file, the text of a wiki page, |
| 14 | part of a trouble ticket, or one of several special control artifacts |
| 15 | used to show the relationships between other artifacts within the |
| 16 | project. Each artifact is normally represented on disk as a separate |
| 17 | file. Artifacts can be text or binary. |
| 18 | </p> |
| 19 | |
| 20 | <p> |
| 21 | Each artifact in the repository is named by its SHA1 hash. |
| 22 | No prefixes or meta information is added to a artifact before |
| 23 | its hash is computed. The name of a artifact in the repository |
| 24 | is exactly the same SHA1 hash that is computed by sha1sum |
| @@ -331,11 +346,11 @@ | |
| 331 | <p>A ticket-change artifact represents a change to a trouble ticket. |
| 332 | The following cards are allowed on a ticket change artifact:</p> |
| 333 | |
| 334 | <blockquote> |
| 335 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 336 | <b>J</b> ?<b>+</b>?<i>name value</i><br /> |
| 337 | <b>K</b> <i>ticket-id</i><br /> |
| 338 | <b>U</b> <i>user-name</i><br /> |
| 339 | <b>Z</b> <i>checksum</i> |
| 340 | </blockquote> |
| 341 | |
| @@ -350,15 +365,19 @@ | |
| 350 | is specified by the K card. A ticket exists if it contains one or |
| 351 | more changes. The first "change" to a ticket is what brings the |
| 352 | ticket into existance.</p> |
| 353 | |
| 354 | <p> |
| 355 | J cards specify changes to "fields" of the ticket. Each fossil |
| 356 | server has a ticket configuration which specifies the fields its |
| 357 | understands. This is not a limit on the fields that can appear |
| 358 | on the J cards, however. If a J card specifies a field that a |
| 359 | particular fossil server does not recognize, then that J card |
| 360 | is simply ignored.</p> |
| 361 | |
| 362 | <p> |
| 363 | The first argument of the J card is the field name. The second |
| 364 | value is the field value. If the field name begins with "+" then |
| 365 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -1,24 +1,39 @@ | |
| 1 | <h1 align="center"> |
| 2 | Fossil File Formats |
| 3 | </h1> |
| 4 | |
| 5 | <p>The global state of a fossil repository is kept simple so that it can |
| 6 | endure in useful form for decades or centuries. |
| 7 | A fossil repository is intended to be readable, |
| 8 | searchable, and extensible by people not yet born.</p> |
| 9 | |
| 10 | <p> |
| 11 | The global state of a fossil repository is an unordered |
| 12 | set of <i>artifacts</i>. |
| 13 | An artifact might be a source code file, the text of a wiki page, |
| 14 | part of a trouble ticket, or one of several special control artifacts |
| 15 | used to show the relationships between other artifacts within the |
| 16 | project. Each artifact is normally represented on disk as a separate |
| 17 | file. Artifacts can be text or binary. |
| 18 | </p> |
| 19 | |
| 20 | <p> |
| 21 | In addition to the global state, |
| 22 | each fossil repository also contains local state. |
| 23 | The local state consists of web-page formatting |
| 24 | preferences, authorized users, ticket display and reporting formats, |
| 25 | and so forth. The global state is shared in common among all |
| 26 | repositories for the same project, whereas the local state is often |
| 27 | different in separate repositories. |
| 28 | The local state is not versioned and is not synchronized |
| 29 | with the global state. |
| 30 | The local state is not composed of artifacts and is not intended to be enduring. |
| 31 | This document is concerned with global state only. Local state is only |
| 32 | mentioned here in order to distinguish it from global state. |
| 33 | </p> |
| 34 | |
| 35 | <p> |
| 36 | Each artifact in the repository is named by its SHA1 hash. |
| 37 | No prefixes or meta information is added to a artifact before |
| 38 | its hash is computed. The name of a artifact in the repository |
| 39 | is exactly the same SHA1 hash that is computed by sha1sum |
| @@ -331,11 +346,11 @@ | |
| 346 | <p>A ticket-change artifact represents a change to a trouble ticket. |
| 347 | The following cards are allowed on a ticket change artifact:</p> |
| 348 | |
| 349 | <blockquote> |
| 350 | <b>D</b> <i>time-and-date-stamp</i><br /> |
| 351 | <b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br /> |
| 352 | <b>K</b> <i>ticket-id</i><br /> |
| 353 | <b>U</b> <i>user-name</i><br /> |
| 354 | <b>Z</b> <i>checksum</i> |
| 355 | </blockquote> |
| 356 | |
| @@ -350,15 +365,19 @@ | |
| 365 | is specified by the K card. A ticket exists if it contains one or |
| 366 | more changes. The first "change" to a ticket is what brings the |
| 367 | ticket into existance.</p> |
| 368 | |
| 369 | <p> |
| 370 | J cards specify changes to the "value" of "fields" in the ticket. |
| 371 | If the <i>value</i> parameter of the J card is omitted, then the |
| 372 | field is set to an empty string. |
| 373 | Each fossil server has a ticket configuration which specifies the fields its |
| 374 | understands. The ticket configuration is part of the local state for |
| 375 | the repository and thus can vary from one repository to another. |
| 376 | Hencd a J card might specify a <i>field</i> that do not exist in the |
| 377 | local ticket configuration. If a J card specifies a <i>field</i> that |
| 378 | is not in the local configuration, then that J card |
| 379 | is simply ignored.</p> |
| 380 | |
| 381 | <p> |
| 382 | The first argument of the J card is the field name. The second |
| 383 | value is the field value. If the field name begins with "+" then |
| 384 |
+29
-3
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -15,17 +15,27 @@ | ||
| 15 | 15 | Synchronization is simply the process of sharing artifacts between |
| 16 | 16 | servers so that all servers have copies of all artifacts. Because |
| 17 | 17 | artifacts are unordered, the order in which artifacts are received |
| 18 | 18 | at a server is inconsequential. It is assumed that the SHA1 hashes |
| 19 | 19 | of artifacts are unique - that every artifact has a different SHA1 hash. |
| 20 | -To first approximation, synchronization proceeds by sharing lists | |
| 20 | +To a first approximation, synchronization proceeds by sharing lists | |
| 21 | 21 | SHA1 hashes of available artifacts, then sharing those artifacts that |
| 22 | 22 | are not found on one side or the other of the connection. In practice, |
| 23 | 23 | a repository might contain millions of artifacts. The list of |
| 24 | 24 | SHA1 hashes for this many artifacts can be large. So optimizations are |
| 25 | 25 | employed that usually reduce the number of SHA1 hashes that need to be |
| 26 | 26 | shared to a few hundred.</p> |
| 27 | + | |
| 28 | +<p>Each repository also has local state. The local state determines | |
| 29 | +the web-page formatting preferences, authorized users, ticket formats, | |
| 30 | +and similar information that varies from one repository to another. | |
| 31 | +The local state is not transfered by the <b>push</b>, <b>pull</b>, | |
| 32 | +and <b>sync</b> command, though some local state is transfered during | |
| 33 | +a <b>clone</b> in order to initialize the local state of the new | |
| 34 | +repository. The <b>configuration push</b> and <b>configuration pull</b> | |
| 35 | +commands can be used to send or receive local state.</p> | |
| 36 | + | |
| 27 | 37 | |
| 28 | 38 | <h2>2.0 Transport</h2> |
| 29 | 39 | |
| 30 | 40 | <p>All communication between client and server is via HTTP requests. |
| 31 | 41 | The server is listening for incoming HTTP requests. The client |
| @@ -275,11 +285,19 @@ | ||
| 275 | 285 | cookie and the server must structure the cookie payload in such |
| 276 | 286 | a way that it can tell if the cookie it sees is its own cookie or |
| 277 | 287 | a cookie from another server. (Typically the server will embed |
| 278 | 288 | its servercode as part of the cookie.)</p> |
| 279 | 289 | |
| 280 | -<h3>3.9 Error Cards</h3> | |
| 290 | +<h3>3.9 Request-Configuration Cards</h3> | |
| 291 | + | |
| 292 | +<i>TBD...</i> | |
| 293 | + | |
| 294 | +<h3>3.10 Configuration Cards</h3> | |
| 295 | + | |
| 296 | +<i>TBD...</i> | |
| 297 | + | |
| 298 | +<h3>3.11 Error Cards</h3> | |
| 281 | 299 | |
| 282 | 300 | <p>If the server discovers anything wrong with a request, it generates |
| 283 | 301 | an error card in its reply. When the client sees the error card, |
| 284 | 302 | it displays an error message to the user and aborts the sync |
| 285 | 303 | operation. An error card looks like this:</p> |
| @@ -295,11 +313,16 @@ | ||
| 295 | 313 | (ASCII 0x5C) is represented as two backslashes "\\". Apart from |
| 296 | 314 | space and newline, no other whitespace characters nor any |
| 297 | 315 | unprintable characters are allowed in |
| 298 | 316 | the error message.</p> |
| 299 | 317 | |
| 300 | -<h3>3.10 Unknown Cards</h3> | |
| 318 | +<h3>3.12 Comment Cards</h3> | |
| 319 | + | |
| 320 | +<p>Any card that begins with "#" (ASCII 0x23) is a comment card and | |
| 321 | +is silently ignored.</p> | |
| 322 | + | |
| 323 | +<h3>3.13 Unknown Cards</h3> | |
| 301 | 324 | |
| 302 | 325 | <p>If either the client or the server sees a card that is not |
| 303 | 326 | described above, then it generates an error and aborts.</p> |
| 304 | 327 | |
| 305 | 328 | <h2>4.0 Phantoms And Clusters</h2> |
| @@ -463,10 +486,13 @@ | ||
| 463 | 486 | <li> <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i> |
| 464 | 487 | <li> <b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i> |
| 465 | 488 | <li> <b>igot</b> <i>artifact-id</i> |
| 466 | 489 | <li> <b>gimme</b> <i>artifact-id</i> |
| 467 | 490 | <li> <b>cookie</b> <i>cookie-text</i> |
| 491 | + <li> <b>reqconfig</b> <i>parameter-name</i> | |
| 492 | + <li> <b>config</b> <i>parameter-name size</i> <b>\n</b> <i>content</i> | |
| 493 | + <li> <b>#</b> <i>arbitrary-text...</i> | |
| 468 | 494 | <li> <b>error</b> <i>error-message</i> |
| 469 | 495 | </ul> |
| 470 | 496 | <li>Phantoms are artifacts that a repository knows exist but does not possess. |
| 471 | 497 | <li>Clusters are artifacts that contain IDs of other artifacts. |
| 472 | 498 | <li>Clusters are created automatically on the server during a pull. |
| 473 | 499 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -15,17 +15,27 @@ | |
| 15 | Synchronization is simply the process of sharing artifacts between |
| 16 | servers so that all servers have copies of all artifacts. Because |
| 17 | artifacts are unordered, the order in which artifacts are received |
| 18 | at a server is inconsequential. It is assumed that the SHA1 hashes |
| 19 | of artifacts are unique - that every artifact has a different SHA1 hash. |
| 20 | To first approximation, synchronization proceeds by sharing lists |
| 21 | SHA1 hashes of available artifacts, then sharing those artifacts that |
| 22 | are not found on one side or the other of the connection. In practice, |
| 23 | a repository might contain millions of artifacts. The list of |
| 24 | SHA1 hashes for this many artifacts can be large. So optimizations are |
| 25 | employed that usually reduce the number of SHA1 hashes that need to be |
| 26 | shared to a few hundred.</p> |
| 27 | |
| 28 | <h2>2.0 Transport</h2> |
| 29 | |
| 30 | <p>All communication between client and server is via HTTP requests. |
| 31 | The server is listening for incoming HTTP requests. The client |
| @@ -275,11 +285,19 @@ | |
| 275 | cookie and the server must structure the cookie payload in such |
| 276 | a way that it can tell if the cookie it sees is its own cookie or |
| 277 | a cookie from another server. (Typically the server will embed |
| 278 | its servercode as part of the cookie.)</p> |
| 279 | |
| 280 | <h3>3.9 Error Cards</h3> |
| 281 | |
| 282 | <p>If the server discovers anything wrong with a request, it generates |
| 283 | an error card in its reply. When the client sees the error card, |
| 284 | it displays an error message to the user and aborts the sync |
| 285 | operation. An error card looks like this:</p> |
| @@ -295,11 +313,16 @@ | |
| 295 | (ASCII 0x5C) is represented as two backslashes "\\". Apart from |
| 296 | space and newline, no other whitespace characters nor any |
| 297 | unprintable characters are allowed in |
| 298 | the error message.</p> |
| 299 | |
| 300 | <h3>3.10 Unknown Cards</h3> |
| 301 | |
| 302 | <p>If either the client or the server sees a card that is not |
| 303 | described above, then it generates an error and aborts.</p> |
| 304 | |
| 305 | <h2>4.0 Phantoms And Clusters</h2> |
| @@ -463,10 +486,13 @@ | |
| 463 | <li> <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i> |
| 464 | <li> <b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i> |
| 465 | <li> <b>igot</b> <i>artifact-id</i> |
| 466 | <li> <b>gimme</b> <i>artifact-id</i> |
| 467 | <li> <b>cookie</b> <i>cookie-text</i> |
| 468 | <li> <b>error</b> <i>error-message</i> |
| 469 | </ul> |
| 470 | <li>Phantoms are artifacts that a repository knows exist but does not possess. |
| 471 | <li>Clusters are artifacts that contain IDs of other artifacts. |
| 472 | <li>Clusters are created automatically on the server during a pull. |
| 473 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -15,17 +15,27 @@ | |
| 15 | Synchronization is simply the process of sharing artifacts between |
| 16 | servers so that all servers have copies of all artifacts. Because |
| 17 | artifacts are unordered, the order in which artifacts are received |
| 18 | at a server is inconsequential. It is assumed that the SHA1 hashes |
| 19 | of artifacts are unique - that every artifact has a different SHA1 hash. |
| 20 | To a first approximation, synchronization proceeds by sharing lists |
| 21 | SHA1 hashes of available artifacts, then sharing those artifacts that |
| 22 | are not found on one side or the other of the connection. In practice, |
| 23 | a repository might contain millions of artifacts. The list of |
| 24 | SHA1 hashes for this many artifacts can be large. So optimizations are |
| 25 | employed that usually reduce the number of SHA1 hashes that need to be |
| 26 | shared to a few hundred.</p> |
| 27 | |
| 28 | <p>Each repository also has local state. The local state determines |
| 29 | the web-page formatting preferences, authorized users, ticket formats, |
| 30 | and similar information that varies from one repository to another. |
| 31 | The local state is not transfered by the <b>push</b>, <b>pull</b>, |
| 32 | and <b>sync</b> command, though some local state is transfered during |
| 33 | a <b>clone</b> in order to initialize the local state of the new |
| 34 | repository. The <b>configuration push</b> and <b>configuration pull</b> |
| 35 | commands can be used to send or receive local state.</p> |
| 36 | |
| 37 | |
| 38 | <h2>2.0 Transport</h2> |
| 39 | |
| 40 | <p>All communication between client and server is via HTTP requests. |
| 41 | The server is listening for incoming HTTP requests. The client |
| @@ -275,11 +285,19 @@ | |
| 285 | cookie and the server must structure the cookie payload in such |
| 286 | a way that it can tell if the cookie it sees is its own cookie or |
| 287 | a cookie from another server. (Typically the server will embed |
| 288 | its servercode as part of the cookie.)</p> |
| 289 | |
| 290 | <h3>3.9 Request-Configuration Cards</h3> |
| 291 | |
| 292 | <i>TBD...</i> |
| 293 | |
| 294 | <h3>3.10 Configuration Cards</h3> |
| 295 | |
| 296 | <i>TBD...</i> |
| 297 | |
| 298 | <h3>3.11 Error Cards</h3> |
| 299 | |
| 300 | <p>If the server discovers anything wrong with a request, it generates |
| 301 | an error card in its reply. When the client sees the error card, |
| 302 | it displays an error message to the user and aborts the sync |
| 303 | operation. An error card looks like this:</p> |
| @@ -295,11 +313,16 @@ | |
| 313 | (ASCII 0x5C) is represented as two backslashes "\\". Apart from |
| 314 | space and newline, no other whitespace characters nor any |
| 315 | unprintable characters are allowed in |
| 316 | the error message.</p> |
| 317 | |
| 318 | <h3>3.12 Comment Cards</h3> |
| 319 | |
| 320 | <p>Any card that begins with "#" (ASCII 0x23) is a comment card and |
| 321 | is silently ignored.</p> |
| 322 | |
| 323 | <h3>3.13 Unknown Cards</h3> |
| 324 | |
| 325 | <p>If either the client or the server sees a card that is not |
| 326 | described above, then it generates an error and aborts.</p> |
| 327 | |
| 328 | <h2>4.0 Phantoms And Clusters</h2> |
| @@ -463,10 +486,13 @@ | |
| 486 | <li> <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i> |
| 487 | <li> <b>file</b> <i>artifact-id delta-artifact-id size</i> <b>\n</b> <i>content</i> |
| 488 | <li> <b>igot</b> <i>artifact-id</i> |
| 489 | <li> <b>gimme</b> <i>artifact-id</i> |
| 490 | <li> <b>cookie</b> <i>cookie-text</i> |
| 491 | <li> <b>reqconfig</b> <i>parameter-name</i> |
| 492 | <li> <b>config</b> <i>parameter-name size</i> <b>\n</b> <i>content</i> |
| 493 | <li> <b>#</b> <i>arbitrary-text...</i> |
| 494 | <li> <b>error</b> <i>error-message</i> |
| 495 | </ul> |
| 496 | <li>Phantoms are artifacts that a repository knows exist but does not possess. |
| 497 | <li>Clusters are artifacts that contain IDs of other artifacts. |
| 498 | <li>Clusters are created automatically on the server during a pull. |
| 499 |