Fossil SCM
Tightened up the new reason #5 for "why set up a server".
Commit
50a0e024fbf4d94ebd64e8f80ff5532cedc1e5ab4a2a5d0ec5093d4a336a44fe
Parent
0e1cc786bba5d57…
1 file changed
+6
-7
+6
-7
| --- www/server/whyuseaserver.wiki | ||
| +++ www/server/whyuseaserver.wiki | ||
| @@ -55,22 +55,21 @@ | ||
| 55 | 55 | access to the central DB files, which isn't the case when the |
| 56 | 56 | server is remote and secure against tampering.<p> |
| 57 | 57 | Section 2 is about file locking, which concerns disappear when Fossil's |
| 58 | 58 | on the other side of an HTTP boundary and your server is set up |
| 59 | 59 | properly.<p> |
| 60 | - Sections 3.1, 4 thru 6, and 8 apply to both server-based and | |
| 61 | - serverless Fossil configs, and they apply to the clients in | |
| 62 | - server-based setups, but with a server, you can address these | |
| 63 | - problems in a single place. This means that once a given commit is | |
| 60 | + Sections 3.1, 4 thru 6, and 8 apply to all Fossil configurations, | |
| 61 | + but setting up a server lets you address the risks | |
| 62 | + in a single place. Once a given commit is | |
| 64 | 63 | sync'd to the server, you can be reasonably sure any client-side |
| 65 | 64 | corruption can be fixed with a fresh clone. Ultimately, this |
| 66 | - is an argument for off-machine backups, which Fossil provides when | |
| 67 | - you set the clients up to sync with a server.<p> | |
| 65 | + is an argument for off-machine backups, which returns us to reason | |
| 66 | + #4 above.<p> | |
| 68 | 67 | Sections 3.2 and the entirety of section 7 are no concern with |
| 69 | 68 | Fossil at all, since it's primarily written by the creator and |
| 70 | 69 | primary maintainer of SQLite, so you can be certain Fossil doesn't |
| 71 | - actively pursue coding strategies that risk database corruption.<p> | |
| 70 | + actively pursue coding strategies known to risk database corruption.<p> | |
| 72 | 71 | |
| 73 | 72 | 6. <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b><p> |
| 74 | 73 | The role-based access control (RBAC) system in Fossil only works |
| 75 | 74 | when the remote system is on the other side of an HTTP barrier. |
| 76 | 75 | ([../caps/#webonly | Details].) If you want its benefits, you need |
| 77 | 76 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -55,22 +55,21 @@ | |
| 55 | access to the central DB files, which isn't the case when the |
| 56 | server is remote and secure against tampering.<p> |
| 57 | Section 2 is about file locking, which concerns disappear when Fossil's |
| 58 | on the other side of an HTTP boundary and your server is set up |
| 59 | properly.<p> |
| 60 | Sections 3.1, 4 thru 6, and 8 apply to both server-based and |
| 61 | serverless Fossil configs, and they apply to the clients in |
| 62 | server-based setups, but with a server, you can address these |
| 63 | problems in a single place. This means that once a given commit is |
| 64 | sync'd to the server, you can be reasonably sure any client-side |
| 65 | corruption can be fixed with a fresh clone. Ultimately, this |
| 66 | is an argument for off-machine backups, which Fossil provides when |
| 67 | you set the clients up to sync with a server.<p> |
| 68 | Sections 3.2 and the entirety of section 7 are no concern with |
| 69 | Fossil at all, since it's primarily written by the creator and |
| 70 | primary maintainer of SQLite, so you can be certain Fossil doesn't |
| 71 | actively pursue coding strategies that risk database corruption.<p> |
| 72 | |
| 73 | 6. <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b><p> |
| 74 | The role-based access control (RBAC) system in Fossil only works |
| 75 | when the remote system is on the other side of an HTTP barrier. |
| 76 | ([../caps/#webonly | Details].) If you want its benefits, you need |
| 77 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -55,22 +55,21 @@ | |
| 55 | access to the central DB files, which isn't the case when the |
| 56 | server is remote and secure against tampering.<p> |
| 57 | Section 2 is about file locking, which concerns disappear when Fossil's |
| 58 | on the other side of an HTTP boundary and your server is set up |
| 59 | properly.<p> |
| 60 | Sections 3.1, 4 thru 6, and 8 apply to all Fossil configurations, |
| 61 | but setting up a server lets you address the risks |
| 62 | in a single place. Once a given commit is |
| 63 | sync'd to the server, you can be reasonably sure any client-side |
| 64 | corruption can be fixed with a fresh clone. Ultimately, this |
| 65 | is an argument for off-machine backups, which returns us to reason |
| 66 | #4 above.<p> |
| 67 | Sections 3.2 and the entirety of section 7 are no concern with |
| 68 | Fossil at all, since it's primarily written by the creator and |
| 69 | primary maintainer of SQLite, so you can be certain Fossil doesn't |
| 70 | actively pursue coding strategies known to risk database corruption.<p> |
| 71 | |
| 72 | 6. <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b><p> |
| 73 | The role-based access control (RBAC) system in Fossil only works |
| 74 | when the remote system is on the other side of an HTTP barrier. |
| 75 | ([../caps/#webonly | Details].) If you want its benefits, you need |
| 76 |