Fossil SCM
Small additions and a broken link fix in sync.wiki.
Commit
22191108aa91f0847db8202d86647e2c07b22d5262a58ae071bf5fcf04f5beca
Parent
07a16b79331d839…
1 file changed
+10
-6
+10
-6
| --- www/sync.wiki | ||
| +++ www/sync.wiki | ||
| @@ -58,20 +58,20 @@ | ||
| 58 | 58 | request. |
| 59 | 59 | |
| 60 | 60 | The server might be running as an independent server |
| 61 | 61 | using the [/help?cmd=server|"fossil server" command], or it |
| 62 | 62 | might be launched from inetd or xinetd using the |
| 63 | -["fossil http" command|/help?cmd=http]. Or the server might | |
| 63 | +[/help?cmd=http|"fossil http" command]. Or the server might | |
| 64 | 64 | be [./server/any/cgi.md|launched from CGI] or from |
| 65 | 65 | [./server/any/scgi.md|SCGI]. |
| 66 | 66 | (See "[./server/|How To Configure A Fossil Server]" for details.) |
| 67 | 67 | The specifics of how the server listens |
| 68 | 68 | for incoming HTTP requests is immaterial to this protocol. |
| 69 | 69 | The important point is that the server is listening for requests and |
| 70 | 70 | the client is the issuer of the requests. |
| 71 | 71 | |
| 72 | -A single [/help?cmd=push|push], | |
| 72 | +A single [/help?cmd=push|push], | |
| 73 | 73 | [/help?cmd=pull|pull], or [/help?cmd=sync|sync] |
| 74 | 74 | might involve multiple HTTP requests. |
| 75 | 75 | The client maintains state between all requests. But on the server |
| 76 | 76 | side, each request is independent. The server does not preserve |
| 77 | 77 | any information about the client from one request to the next. |
| @@ -250,11 +250,11 @@ | ||
| 250 | 250 | |
| 251 | 251 | <h4 id="ordinary-fc">3.3.1 Ordinary File Cards</h4> |
| 252 | 252 | |
| 253 | 253 | For sync protocols, artifacts are transferred using "file" |
| 254 | 254 | cards. File cards come in two different formats depending |
| 255 | -on whether the artifact is sent directly or as a | |
| 255 | +on whether the artifact is sent directly or as a | |
| 256 | 256 | [./delta_format.wiki|delta] from some |
| 257 | 257 | other artifact. |
| 258 | 258 | |
| 259 | 259 | <pre> |
| 260 | 260 | <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i> |
| @@ -273,11 +273,11 @@ | ||
| 273 | 273 | representation of the name hash for the artifact. |
| 274 | 274 | The last argument of the file card is the number of bytes of |
| 275 | 275 | payload that immediately follow the file card. If the file |
| 276 | 276 | card has only two arguments, that means the payload is the |
| 277 | 277 | complete content of the artifact. If the file card has three |
| 278 | -arguments, then the payload is a | |
| 278 | +arguments, then the payload is a | |
| 279 | 279 | [./delta_format.wiki|delta] and the second argument is |
| 280 | 280 | the ID of another artifact that is the source of the delta. |
| 281 | 281 | |
| 282 | 282 | File cards are sent in both directions: client to server and |
| 283 | 283 | server to client. A delta might be sent before the source of |
| @@ -286,12 +286,16 @@ | ||
| 286 | 286 | |
| 287 | 287 | <h4 id="compressed-fc">3.3.2 Compressed File Cards</h4> |
| 288 | 288 | |
| 289 | 289 | A client that sends a clone protocol version "3" or greater will |
| 290 | 290 | receive artifacts as "cfile" cards while cloning. This card was |
| 291 | -introduced to improve the speed of the transfer of content by sending the | |
| 292 | -compressed artifact directly from the server database to the client. | |
| 291 | +introduced to improve the speed of the transfer of content by sending | |
| 292 | +the compressed artifact directly from the server database to the | |
| 293 | +client. In this case, the containing response body is <em>not</em> | |
| 294 | +compressed separately because the vast majority of the response is | |
| 295 | +already compressed in cfile cards. In practice, version "3" is | |
| 296 | +significantly faster than version "2". | |
| 293 | 297 | |
| 294 | 298 | Compressed File cards are similar to File cards, sharing the same |
| 295 | 299 | in-line "payload" data characteristics and also the same treatment of |
| 296 | 300 | direct content or delta content. Cfile cards come in two different formats |
| 297 | 301 | depending on whether the artifact is sent directly or as a delta from |
| 298 | 302 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -58,20 +58,20 @@ | |
| 58 | request. |
| 59 | |
| 60 | The server might be running as an independent server |
| 61 | using the [/help?cmd=server|"fossil server" command], or it |
| 62 | might be launched from inetd or xinetd using the |
| 63 | ["fossil http" command|/help?cmd=http]. Or the server might |
| 64 | be [./server/any/cgi.md|launched from CGI] or from |
| 65 | [./server/any/scgi.md|SCGI]. |
| 66 | (See "[./server/|How To Configure A Fossil Server]" for details.) |
| 67 | The specifics of how the server listens |
| 68 | for incoming HTTP requests is immaterial to this protocol. |
| 69 | The important point is that the server is listening for requests and |
| 70 | the client is the issuer of the requests. |
| 71 | |
| 72 | A single [/help?cmd=push|push], |
| 73 | [/help?cmd=pull|pull], or [/help?cmd=sync|sync] |
| 74 | might involve multiple HTTP requests. |
| 75 | The client maintains state between all requests. But on the server |
| 76 | side, each request is independent. The server does not preserve |
| 77 | any information about the client from one request to the next. |
| @@ -250,11 +250,11 @@ | |
| 250 | |
| 251 | <h4 id="ordinary-fc">3.3.1 Ordinary File Cards</h4> |
| 252 | |
| 253 | For sync protocols, artifacts are transferred using "file" |
| 254 | cards. File cards come in two different formats depending |
| 255 | on whether the artifact is sent directly or as a |
| 256 | [./delta_format.wiki|delta] from some |
| 257 | other artifact. |
| 258 | |
| 259 | <pre> |
| 260 | <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i> |
| @@ -273,11 +273,11 @@ | |
| 273 | representation of the name hash for the artifact. |
| 274 | The last argument of the file card is the number of bytes of |
| 275 | payload that immediately follow the file card. If the file |
| 276 | card has only two arguments, that means the payload is the |
| 277 | complete content of the artifact. If the file card has three |
| 278 | arguments, then the payload is a |
| 279 | [./delta_format.wiki|delta] and the second argument is |
| 280 | the ID of another artifact that is the source of the delta. |
| 281 | |
| 282 | File cards are sent in both directions: client to server and |
| 283 | server to client. A delta might be sent before the source of |
| @@ -286,12 +286,16 @@ | |
| 286 | |
| 287 | <h4 id="compressed-fc">3.3.2 Compressed File Cards</h4> |
| 288 | |
| 289 | A client that sends a clone protocol version "3" or greater will |
| 290 | receive artifacts as "cfile" cards while cloning. This card was |
| 291 | introduced to improve the speed of the transfer of content by sending the |
| 292 | compressed artifact directly from the server database to the client. |
| 293 | |
| 294 | Compressed File cards are similar to File cards, sharing the same |
| 295 | in-line "payload" data characteristics and also the same treatment of |
| 296 | direct content or delta content. Cfile cards come in two different formats |
| 297 | depending on whether the artifact is sent directly or as a delta from |
| 298 |
| --- www/sync.wiki | |
| +++ www/sync.wiki | |
| @@ -58,20 +58,20 @@ | |
| 58 | request. |
| 59 | |
| 60 | The server might be running as an independent server |
| 61 | using the [/help?cmd=server|"fossil server" command], or it |
| 62 | might be launched from inetd or xinetd using the |
| 63 | [/help?cmd=http|"fossil http" command]. Or the server might |
| 64 | be [./server/any/cgi.md|launched from CGI] or from |
| 65 | [./server/any/scgi.md|SCGI]. |
| 66 | (See "[./server/|How To Configure A Fossil Server]" for details.) |
| 67 | The specifics of how the server listens |
| 68 | for incoming HTTP requests is immaterial to this protocol. |
| 69 | The important point is that the server is listening for requests and |
| 70 | the client is the issuer of the requests. |
| 71 | |
| 72 | A single [/help?cmd=push|push], |
| 73 | [/help?cmd=pull|pull], or [/help?cmd=sync|sync] |
| 74 | might involve multiple HTTP requests. |
| 75 | The client maintains state between all requests. But on the server |
| 76 | side, each request is independent. The server does not preserve |
| 77 | any information about the client from one request to the next. |
| @@ -250,11 +250,11 @@ | |
| 250 | |
| 251 | <h4 id="ordinary-fc">3.3.1 Ordinary File Cards</h4> |
| 252 | |
| 253 | For sync protocols, artifacts are transferred using "file" |
| 254 | cards. File cards come in two different formats depending |
| 255 | on whether the artifact is sent directly or as a |
| 256 | [./delta_format.wiki|delta] from some |
| 257 | other artifact. |
| 258 | |
| 259 | <pre> |
| 260 | <b>file</b> <i>artifact-id size</i> <b>\n</b> <i>content</i> |
| @@ -273,11 +273,11 @@ | |
| 273 | representation of the name hash for the artifact. |
| 274 | The last argument of the file card is the number of bytes of |
| 275 | payload that immediately follow the file card. If the file |
| 276 | card has only two arguments, that means the payload is the |
| 277 | complete content of the artifact. If the file card has three |
| 278 | arguments, then the payload is a |
| 279 | [./delta_format.wiki|delta] and the second argument is |
| 280 | the ID of another artifact that is the source of the delta. |
| 281 | |
| 282 | File cards are sent in both directions: client to server and |
| 283 | server to client. A delta might be sent before the source of |
| @@ -286,12 +286,16 @@ | |
| 286 | |
| 287 | <h4 id="compressed-fc">3.3.2 Compressed File Cards</h4> |
| 288 | |
| 289 | A client that sends a clone protocol version "3" or greater will |
| 290 | receive artifacts as "cfile" cards while cloning. This card was |
| 291 | introduced to improve the speed of the transfer of content by sending |
| 292 | the compressed artifact directly from the server database to the |
| 293 | client. In this case, the containing response body is <em>not</em> |
| 294 | compressed separately because the vast majority of the response is |
| 295 | already compressed in cfile cards. In practice, version "3" is |
| 296 | significantly faster than version "2". |
| 297 | |
| 298 | Compressed File cards are similar to File cards, sharing the same |
| 299 | in-line "payload" data characteristics and also the same treatment of |
| 300 | direct content or delta content. Cfile cards come in two different formats |
| 301 | depending on whether the artifact is sent directly or as a delta from |
| 302 |