22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
-
+
-
-
+
+
|
employed that usually reduce the number of hashes that need to be
shared to a few dozen.
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 usually transferred during a sync. Except,
some local state is transferred during a [/help?cmd=clone|clone]
some local state is transferred during a [/help/clone|clone]
in order to initialize the local state of the new repository. Also,
an administrator can sync local state using
the [/help?cmd=configuration|config push] and
[/help?cmd=configuration|config pull]
the [/help/configuration|config push] and
[/help/configuration|config pull]
commands.
<h3 id="crdt">1.1 Conflict-Free Replicated Datatypes</h3>
The "bag of artifacts" data model used by Fossil is apparently an
implementation of a particular
[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|Conflict-Free
|
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
-
+
-
+
-
-
+
+
|
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.
The server might be running as an independent server
using the [/help?cmd=server|"fossil server" command], or it
using the [/help/server|"fossil server" command], or it
might be launched from inetd or xinetd using the
[/help?cmd=http|"fossil http" command]. Or the server might
[/help/http|"fossil http" command]. Or the server might
be [./server/any/cgi.md|launched from CGI] or from
[./server/any/scgi.md|SCGI].
(See "[./server/|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.
A single [/help?cmd=push|push],
[/help?cmd=pull|pull], or [/help?cmd=sync|sync]
A single [/help/push|push],
[/help/pull|pull], or [/help?cmd=sync|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.
Note: Throughout this article, we use the terms "server" and "client"
to represent the listener and initiator of the interaction, respectively.
|