|
1
|
<title>Benefits of a Fossil Server</title> |
|
2
|
|
|
3
|
<h2>No Server Required</h2> |
|
4
|
|
|
5
|
Fossil does not require a central server. |
|
6
|
Data sharing and synchronization can be entirely peer-to-peer. |
|
7
|
Fossil uses |
|
8
|
[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type | |
|
9
|
conflict-free replicated data types] |
|
10
|
to ensure that (in the limit) all participating peers see the same content. |
|
11
|
|
|
12
|
<h2>But, a Server Can Be Useful</h2> |
|
13
|
|
|
14
|
Fossil does not require a server, but a server can be very useful. |
|
15
|
Here are a few reasons to set up a Fossil server for your project: |
|
16
|
|
|
17
|
1. <b>A server works as a complete project website.</b> |
|
18
|
|
|
19
|
Fossil does more than just version control. It also supports |
|
20
|
[../tickets.wiki|trouble-tickets], |
|
21
|
[../wikitheory.wiki|wiki], |
|
22
|
a [../chat.md|developer chat room], and a [../forum.wiki|forum]. |
|
23
|
The [../embeddeddoc.wiki|embedded documentation] |
|
24
|
feature provides a great mechanism for providing project documentation. |
|
25
|
The [../unvers.wiki|unversioned files] feature is a convenient way |
|
26
|
to host builds and downloads on the project website. |
|
27
|
|
|
28
|
2. <b>A server gives developers a common point of rendezvous for |
|
29
|
syncing their work.</b> |
|
30
|
|
|
31
|
It is possible for developers to synchronize peer-to-peer but |
|
32
|
that requires the developers coordinate the sync, which in turn |
|
33
|
requires that the developers both want to sync at the same moment. |
|
34
|
A server alleviates this time dependency by allowing each developer |
|
35
|
to sync whenever it is convenient. For example, a developer may |
|
36
|
choose to automatically sync |
|
37
|
after each commit and before each update. Developers all stay |
|
38
|
in sync with each other without having to interrupt each other |
|
39
|
constantly to set up a peer-to-peer sync. |
|
40
|
|
|
41
|
3. <b>A server provides project leaders with up-to-date status.</b> |
|
42
|
|
|
43
|
Project coordinators and BDFLs can click on a link or two at the |
|
44
|
central Fossil server for a project and quickly tell what is |
|
45
|
going on. They can do this from anywhere — even from their phones |
|
46
|
— without needing to actually sync to the device they are using. |
|
47
|
|
|
48
|
4. <b>A server provides automatic off-site backups.</b> |
|
49
|
|
|
50
|
A Fossil server is an automatic remote backup for all the work |
|
51
|
going into a project. ([../backup.md | Within limits].) |
|
52
|
You can even set up multiple servers at |
|
53
|
multiple sites with automatic synchronization between them for |
|
54
|
added redundancy. Such a setup means that no work is lost due |
|
55
|
to a single machine failure. |
|
56
|
|
|
57
|
5. <b>A server consolidates [https://www.sqlite.org/howtocorrupt.html |
|
58
|
| SQLite corruption risk mitigation] to a single point.</b> |
|
59
|
|
|
60
|
The concerns in section 1 of that document assume you have direct |
|
61
|
access to the central DB files, which isn't the case when the |
|
62
|
server is remote and secure against tampering. |
|
63
|
|
|
64
|
Section 2 is about file locking, which concerns disappear when Fossil's |
|
65
|
on the other side of an HTTP boundary and your server is set up |
|
66
|
properly. |
|
67
|
|
|
68
|
Sections 3.1, 4 thru 6, and 8 apply to all Fossil configurations, |
|
69
|
but setting up a server lets you address the risks |
|
70
|
in a single place. Once a given commit is |
|
71
|
sync'd to the server, you can be reasonably sure any client-side |
|
72
|
corruption can be fixed with a fresh clone. Ultimately, this |
|
73
|
is an argument for off-machine backups, which returns us to reason |
|
74
|
#4 above. |
|
75
|
|
|
76
|
Sections 3.2 and the entirety of section 7 are no concern with |
|
77
|
Fossil at all, since it's primarily written by the creator and |
|
78
|
primary maintainer of SQLite, so you can be certain Fossil doesn't |
|
79
|
actively pursue coding strategies known to risk database corruption. |
|
80
|
|
|
81
|
For another take on this topic, see the article |
|
82
|
"[https://sqlite.org/useovernet.html | SQLite Over a Network, |
|
83
|
Caveats and Considerations]". Fossil runs in rollback mode by |
|
84
|
default per recommendation #3 at the end of that article, and a |
|
85
|
Fossil server operates as a network proxy for the underlying |
|
86
|
SQLite repository DB per recommendation #2. This <i>may</i> permit |
|
87
|
you to safely switch it into WAL mode (<b>fossil rebuild --wal</b>) |
|
88
|
depending on the underlying storage used by the server itself. |
|
89
|
|
|
90
|
6. <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b> |
|
91
|
|
|
92
|
The role-based access control (RBAC) system in Fossil only works |
|
93
|
when the remote system is on the other side of an HTTP barrier. |
|
94
|
([../caps/#webonly | Details].) If you want its benefits, you need |
|
95
|
a Fossil server setup of some kind. |
|
96
|
|