initial commitHEADmaster

1 files changed, 95 insertions, 0 deletions

diff --git a/www/server/whyuseaserver.wiki b/www/server/whyuseaserver.wiki
new file mode 100644
index 0000000..cdd9823
--- /dev/null
+++ b/www/server/whyuseaserver.wiki
@@ -0,0 +1,95 @@
+<title>Benefits of a Fossil Server</title>
+
+<h2>No Server Required</h2>
+
+Fossil does not require a central server.
+Data sharing and synchronization can be entirely peer-to-peer.
+Fossil uses 
+[https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type |
+conflict-free replicated data types]
+to ensure that (in the limit) all participating peers see the same content.
+
+<h2>But, a Server Can Be Useful</h2>
+
+Fossil does not require a server, but a server can be very useful.
+Here are a few reasons to set up a Fossil server for your project:
+
+  1.  <b>A server works as a complete project website.</b>
+
+      Fossil does more than just version control.  It also supports
+      [../tickets.wiki|trouble-tickets], 
+      [../wikitheory.wiki|wiki], 
+      a [../chat.md|developer chat room], and a [../forum.wiki|forum].
+      The [../embeddeddoc.wiki|embedded documentation]
+      feature provides  a great mechanism for providing project documentation.
+      The [../unvers.wiki|unversioned files] feature is a convenient way
+      to host builds and downloads on the project website.
+
+  2.  <b>A server gives developers a common point of rendezvous for
+      syncing their work.</b>
+
+      It is possible for developers to synchronize peer-to-peer but
+      that requires the developers coordinate the sync, which in turn
+      requires that the developers both want to sync at the same moment.
+      A server alleviates this time dependency by allowing each developer
+      to sync whenever it is convenient. For example, a developer may
+      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>
+
+      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>
+
+      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>
+
+      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.
+
+      Section 2 is about file locking, which concerns disappear when Fossil's
+      on the other side of an HTTP boundary and your server is set up
+      properly.
+
+      Sections 3.1, 4 thru 6, and 8 apply to all Fossil configurations,
+      but setting up a server lets you address the risks
+      in a single place. Once a given commit is
+      sync'd to the server, you can be reasonably sure any client-side
+      corruption can be fixed with a fresh clone. Ultimately, this
+      is an argument for off-machine backups, which returns us to reason
+      #4 above.
+
+      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 known to risk database corruption.
+
+      For another take on this topic, see the article
+      "[https://sqlite.org/useovernet.html | SQLite Over a Network,
+      Caveats and Considerations]". Fossil runs in rollback mode by
+      default per recommendation #3 at the end of that article, and a
+      Fossil server operates as a network proxy for the underlying
+      SQLite repository DB per recommendation #2. This <i>may</i> permit
+      you to safely switch it into WAL mode (<b>fossil rebuild --wal</b>)
+      depending on the underlying storage used by the server itself.
+
+  6.  <b>A server allows [../caps/ | Fossil's RBAC system] to work.</b>
+
+      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.