1
2
3
4
5
6
7
8
9
10
|
<title>The Fossil Sync Protocol</title>
<p>This document describes the wire protocol used to synchronize
content between two Fossil repositories.</p>
<h2>1.0 Overview</h2>
<p>The global state of a fossil repository consists of an unordered
collection of artifacts. Each artifact is identified by its SHA1 hash
expressed as a 40-character lower-case hexadecimal string.
|
|
|
1
2
3
4
5
6
7
8
9
10
|
<title>The Fossil Sync Protocol</title>
<p>This document describes the wire protocol used to synchronize
content between two Fossil repositories.</p>
<h2>1.0 Overview</h2>
<p>The global state of a fossil repository consists of an unordered
collection of artifacts. Each artifact is identified by its SHA1 hash
expressed as a 40-character lower-case hexadecimal string.
|
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
SHA1 hashes for this many artifacts can be large. So optimizations are
employed that usually reduce the number of SHA1 hashes that need to be
shared to a few hundred.</p>
<p>Each repository also has local state. The local state determines
the web-page formatting preferences, authorized users, ticket formats,
and similar information that varies from one repository to another.
The local state is not using transferred during a sync. Except,
some local state is transferred during a [/help?cmd=clone|clone]
in order to initialize the local state of the new repository. And
the [/help?cmd=configuration|config push] and
[/help?cmd=configuration|config pull]
commands can be an administrator to sync local state.</p>
<h2>2.0 Transport</h2>
<p>All communication between client and server is via HTTP requests.
The server is listening for incoming HTTP requests. The client
issues one or more HTTP requests and receives replies for each
request.</p>
<p>The server might be running as an independent server
using the <b>server</b> command, or it might be launched from
inetd or xinetd using the <b>http</b> command. Or the server might
be launched from CGI.
(See "[./server.wiki|How To Configure A Fossil Server]" for details.)
The specifics of how the server listens
for incoming HTTP requests is immaterial to this protocol.
The important point is that the server is listening for requests and
the client is the issuer of the requests.</p>
<p>A single push, pull, or sync might involve multiple HTTP requests.
The client maintains state between all requests. But on the server
side, each request is independent. The server does not preserve
any information about the client from one request to the next.</p>
<h4>2.0.1 Encrypted Transport</h4>
<p>In the current implementation of Fossil, the server only
understands HTTP requests. The client can send either
clear-text HTTP requests or encrypted HTTPS requests. But when
HTTPS requests are sent, they first must be decrypted by a webserver
or proxy before being passed to the Fossil server. This limitation
may be relaxed in a future release.</p>
<h3>2.1 Server Identification</h3>
|
|
|
|
|
|
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
|
SHA1 hashes for this many artifacts can be large. So optimizations are
employed that usually reduce the number of SHA1 hashes that need to be
shared to a few hundred.</p>
<p>Each repository also has local state. The local state determines
the web-page formatting preferences, authorized users, ticket formats,
and similar information that varies from one repository to another.
The local state is not using transferred during a sync. Except,
some local state is transferred during a [/help?cmd=clone|clone]
in order to initialize the local state of the new repository. And
the [/help?cmd=configuration|config push] and
[/help?cmd=configuration|config pull]
commands can be an administrator to sync local state.</p>
<h2>2.0 Transport</h2>
<p>All communication between client and server is via HTTP requests.
The server is listening for incoming HTTP requests. The client
issues one or more HTTP requests and receives replies for each
request.</p>
<p>The server might be running as an independent server
using the <b>server</b> command, or it might be launched from
inetd or xinetd using the <b>http</b> command. Or the server might
be launched from CGI.
(See "[./server.wiki|How To Configure A Fossil Server]" for details.)
The specifics of how the server listens
for incoming HTTP requests is immaterial to this protocol.
The important point is that the server is listening for requests and
the client is the issuer of the requests.</p>
<p>A single push, pull, or sync might involve multiple HTTP requests.
The client maintains state between all requests. But on the server
side, each request is independent. The server does not preserve
any information about the client from one request to the next.</p>
<h4>2.0.1 Encrypted Transport</h4>
<p>In the current implementation of Fossil, the server only
understands HTTP requests. The client can send either
clear-text HTTP requests or encrypted HTTPS requests. But when
HTTPS requests are sent, they first must be decrypted by a webserver
or proxy before being passed to the Fossil server. This limitation
may be relaxed in a future release.</p>
<h3>2.1 Server Identification</h3>
|
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
|
<blockquote>
<b>uvigot</b> <i>name mtime hash size</i>
</blockquote>
<p>The <i>name</i> argument is the name of an unversioned file.
The <i>mtime</i> is the last modification time of the unversioned file
in seconds since 1970.
The <i>hash</i> is the SHA1 hash of the unversioned file content, or
"<b>-</b>" if the file has been deleted.
The <i>size</i> is the uncompressed size of the file in bytes.
<p>When the server sees a "pragma uv-hash" card for which the hash
does not match, it sends uvigot cards for every unversioned file that it
holds. The client will use this information to figure out which
|
|
|
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
|
<blockquote>
<b>uvigot</b> <i>name mtime hash size</i>
</blockquote>
<p>The <i>name</i> argument is the name of an unversioned file.
The <i>mtime</i> is the last modification time of the unversioned file
in seconds since 1970.
The <i>hash</i> is the SHA1 hash of the unversioned file content, or
"<b>-</b>" if the file has been deleted.
The <i>size</i> is the uncompressed size of the file in bytes.
<p>When the server sees a "pragma uv-hash" card for which the hash
does not match, it sends uvigot cards for every unversioned file that it
holds. The client will use this information to figure out which
|