Fossil SCM
Added an answer to SQLite's "how to corrupt" document to the "Benefits of a Fossil Server" doc, since setting up a server does largely solve those problems.
Commit
f9cfadf1b499e52eaf26989d2d438dc235c27ae10ff1a1668fafbd2adc15731a
Parent
dad521bb06757a7…
1 file changed
+25
-2
+25
-2
| --- www/server/whyuseaserver.wiki | ||
| +++ www/server/whyuseaserver.wiki | ||
| @@ -1,16 +1,16 @@ | ||
| 1 | -<title>Benefits Of A Fossil Server</title> | |
| 1 | +<title>Benefits of a Fossil Server</title> | |
| 2 | 2 | |
| 3 | 3 | <h2>No Server Required</h2> |
| 4 | 4 | |
| 5 | 5 | Fossil does not require a central server. |
| 6 | 6 | Data sharing and synchronization can be entirely peer-to-peer. |
| 7 | 7 | Fossil uses |
| 8 | 8 | [https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type|conflict-free replicated data types] |
| 9 | 9 | to ensure that (in the limit) all participating peers see the same content. |
| 10 | 10 | |
| 11 | -<h2>But, A Server Can Be Useful</h2> | |
| 11 | +<h2>But, a Server Can Be Useful</h2> | |
| 12 | 12 | |
| 13 | 13 | Fossil does not require a server, but a server can be very useful. |
| 14 | 14 | Here are a few reasons to set up a Fossil server for your project: |
| 15 | 15 | |
| 16 | 16 | 1. <b>A server works as a complete project website.</b><p> |
| @@ -44,5 +44,28 @@ | ||
| 44 | 44 | A Fossil server is an automatic remote backup for all the work |
| 45 | 45 | going into a project. You can even set up multiple servers, at |
| 46 | 46 | multiple sites, with automatic synchronization between them, for |
| 47 | 47 | added redundancy. Such a set up means that no work is lost due |
| 48 | 48 | to a single machine failure. |
| 49 | + | |
| 50 | + 5. <b>A server consolidates [https://www.sqlite.org/howtocorrupt.html | |
| 51 | + | SQLite corruption risk mitigation] to a single point.</b><p> | |
| 52 | + The concerns in section 1 of that document assume you have direct | |
| 53 | + access to the central DB files, which isn't the case when the | |
| 54 | + server is remote and secure against tampering.<p> | |
| 55 | + Section 2 is about file locking, which concerns disappear when Fossil's | |
| 56 | + on the other side of an HTTP boundary and your server is set up | |
| 57 | + properly.<p> | |
| 58 | + Sections 3.1, 4 thru 6, and 8 apply to both server-based and | |
| 59 | + serverless Fossil configs, and they apply to the clients in | |
| 60 | + server-based setups, but with a server, you can address these | |
| 61 | + problems in a single place. This means that once a given commit is | |
| 62 | + sync'd to the server, you can be reasonably sure any client-side | |
| 63 | + corruption can be fixed with a fresh clone. Ultimately, this | |
| 64 | + is an argument for off-machine backups, which Fossil provides when | |
| 65 | + you set the clients up to sync with a server.<p> | |
| 66 | + Sections 3.2 and the entirety of section 7 are no concern with | |
| 67 | + Fossil at all, since it's primarily written by the creator and | |
| 68 | + primary maintainer of SQLite, so you can be certain Fossil doesn't | |
| 69 | + actively pursue coding strategies that risk database corruption.<p> | |
| 70 | + | |
| 71 | + | |
| 49 | 72 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -1,16 +1,16 @@ | |
| 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|conflict-free replicated data types] |
| 9 | to ensure that (in the limit) all participating peers see the same content. |
| 10 | |
| 11 | <h2>But, A Server Can Be Useful</h2> |
| 12 | |
| 13 | Fossil does not require a server, but a server can be very useful. |
| 14 | Here are a few reasons to set up a Fossil server for your project: |
| 15 | |
| 16 | 1. <b>A server works as a complete project website.</b><p> |
| @@ -44,5 +44,28 @@ | |
| 44 | A Fossil server is an automatic remote backup for all the work |
| 45 | going into a project. You can even set up multiple servers, at |
| 46 | multiple sites, with automatic synchronization between them, for |
| 47 | added redundancy. Such a set up means that no work is lost due |
| 48 | to a single machine failure. |
| 49 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -1,16 +1,16 @@ | |
| 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|conflict-free replicated data types] |
| 9 | to ensure that (in the limit) all participating peers see the same content. |
| 10 | |
| 11 | <h2>But, a Server Can Be Useful</h2> |
| 12 | |
| 13 | Fossil does not require a server, but a server can be very useful. |
| 14 | Here are a few reasons to set up a Fossil server for your project: |
| 15 | |
| 16 | 1. <b>A server works as a complete project website.</b><p> |
| @@ -44,5 +44,28 @@ | |
| 44 | A Fossil server is an automatic remote backup for all the work |
| 45 | going into a project. You can even set up multiple servers, at |
| 46 | multiple sites, with automatic synchronization between them, for |
| 47 | added redundancy. Such a set up means that no work is lost due |
| 48 | to a single machine failure. |
| 49 | |
| 50 | 5. <b>A server consolidates [https://www.sqlite.org/howtocorrupt.html |
| 51 | | SQLite corruption risk mitigation] to a single point.</b><p> |
| 52 | The concerns in section 1 of that document assume you have direct |
| 53 | access to the central DB files, which isn't the case when the |
| 54 | server is remote and secure against tampering.<p> |
| 55 | Section 2 is about file locking, which concerns disappear when Fossil's |
| 56 | on the other side of an HTTP boundary and your server is set up |
| 57 | properly.<p> |
| 58 | Sections 3.1, 4 thru 6, and 8 apply to both server-based and |
| 59 | serverless Fossil configs, and they apply to the clients in |
| 60 | server-based setups, but with a server, you can address these |
| 61 | problems in a single place. This means that once a given commit is |
| 62 | sync'd to the server, you can be reasonably sure any client-side |
| 63 | corruption can be fixed with a fresh clone. Ultimately, this |
| 64 | is an argument for off-machine backups, which Fossil provides when |
| 65 | you set the clients up to sync with a server.<p> |
| 66 | Sections 3.2 and the entirety of section 7 are no concern with |
| 67 | Fossil at all, since it's primarily written by the creator and |
| 68 | primary maintainer of SQLite, so you can be certain Fossil doesn't |
| 69 | actively pursue coding strategies that risk database corruption.<p> |
| 70 | |
| 71 | |
| 72 |