33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
|
choose to automatically sync
after each commit and before each update. Developers all stay
in sync with each other without having to interrupt each other
constantly to set up a peer-to-peer sync.
3. <b>A server provides project leaders with up-to-date status.</b><p>
Project coordinators and BDFLs can click on a link or two at the
central Fossil server for a project, and quickly tell what is
going on. They can do this from anywhere, even from their phones,
without needing to actually sync to the device they are using.
4. <b>A server provides automatic off-site backups.</b><p>
A Fossil server is an automatic remote backup for all the work
going into a project. You can even set up multiple servers, at
multiple sites, with automatic synchronization between them, for
added redundancy. Such a set up means that no work is lost due
to a single machine failure.
5. <b>A server consolidates [https://www.sqlite.org/howtocorrupt.html
| SQLite corruption risk mitigation] to a single point.</b><p>
The concerns in section 1 of that document assume you have direct
access to the central DB files, which isn't the case when the
server is remote and secure against tampering.<p>
|
|
|
|
>
|
|
|
|
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
|
choose to automatically sync
after each commit and before each update. Developers all stay
in sync with each other without having to interrupt each other
constantly to set up a peer-to-peer sync.
3. <b>A server provides project leaders with up-to-date status.</b><p>
Project coordinators and BDFLs can click on a link or two at the
central Fossil server for a project and quickly tell what is
going on. They can do this from anywhere — even from their phones
— without needing to actually sync to the device they are using.
4. <b>A server provides automatic off-site backups.</b><p>
A Fossil server is an automatic remote backup for all the work
going into a project. ([../backup.md | Within limits].)
You can even set up multiple servers at
multiple sites with automatic synchronization between them for
added redundancy. Such a setup means that no work is lost due
to a single machine failure.
5. <b>A server consolidates [https://www.sqlite.org/howtocorrupt.html
| SQLite corruption risk mitigation] to a single point.</b><p>
The concerns in section 1 of that document assume you have direct
access to the central DB files, which isn't the case when the
server is remote and secure against tampering.<p>
|
65
66
67
68
69
70
71
72
73
74
75
76
|
is an argument for off-machine backups, which Fossil provides when
you set the clients up to sync with a server.<p>
Sections 3.2 and the entirety of section 7 are no concern with
Fossil at all, since it's primarily written by the creator and
primary maintainer of SQLite, so you can be certain Fossil doesn't
actively pursue coding strategies that risk database corruption.<p>
6. <b>A server allows [./caps/ | Fossil's RBAC system] to work.</b><p>
The role-based access control (RBAC) system in Fossil only works
when the remote system is on the other side of an HTTP barrier.
([./caps/#webonly | Details].) If you want its benefits, you need
a Fossil server setup of some kind.
|
|
|
|
66
67
68
69
70
71
72
73
74
75
76
77
|
is an argument for off-machine backups, which Fossil provides when
you set the clients up to sync with a server.<p>
Sections 3.2 and the entirety of section 7 are no concern with
Fossil at all, since it's primarily written by the creator and
primary maintainer of SQLite, so you can be certain Fossil doesn't
actively pursue coding strategies that risk database corruption.<p>
6. <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b><p>
The role-based access control (RBAC) system in Fossil only works
when the remote system is on the other side of an HTTP barrier.
([../caps/#webonly | Details].) If you want its benefits, you need
a Fossil server setup of some kind.
|