Fossil SCM
Server documentation updates.
Commit
b2426c278669b8b4173a33609a5749e5b5e01a1c625e39c5580d25a0e6386ec1
Parent
2da704c5a17a802…
2 files changed
+21
-16
+13
-10
+21
-16
| --- www/server/index.html | ||
| +++ www/server/index.html | ||
| @@ -52,25 +52,29 @@ | ||
| 52 | 52 | |
| 53 | 53 | |
| 54 | 54 | <h2>No Server Required</h2> |
| 55 | 55 | |
| 56 | 56 | <p>Fossil does not require a central server, but <a |
| 57 | -href="whyuseaserver.wiki">a server can be very useful</a>.</p> | |
| 57 | +href="whyuseaserver.wiki">a server can be useful</a>.</p> | |
| 58 | + | |
| 59 | +<p>A Fossil server does not require much memory, CPU, or disk space | |
| 60 | +and can run comfortably on a generic $5/month virtual host | |
| 61 | +or on a small device like a RaspberryPI, or it can co-exist | |
| 62 | +on a host running other services without getting in the way. | |
| 58 | 63 | |
| 59 | 64 | <p>This article is a quick-reference guide for setting up your own |
| 60 | 65 | Fossil server, with links to more detailed instructions specific to |
| 61 | 66 | particular systems, should you want extra help.</p> |
| 62 | - | |
| 63 | 67 | |
| 64 | 68 | <h2 id="methods">Methods</h2> |
| 65 | 69 | |
| 66 | 70 | <p>There are basically four ways to set up a Fossil server:</p> |
| 67 | 71 | |
| 68 | 72 | <ol> |
| 69 | 73 | <li><a id="cgi" href="any/cgi.md">CGI</a> |
| 70 | - <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> | |
| 71 | 74 | <li>Socket listener |
| 75 | + <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> | |
| 72 | 76 | <li><a id="scgi" href="any/scgi.md">SCGI</a> |
| 73 | 77 | </ol> |
| 74 | 78 | |
| 75 | 79 | <p>All of these methods can serve either a single repository or a |
| 76 | 80 | directory containing repositories named "<tt>*.fossil</tt>".</p> |
| @@ -87,30 +91,20 @@ | ||
| 87 | 91 | <p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a |
| 88 | 92 | CGI script</a>. This method is known to work with Apache, |
| 89 | 93 | <tt>lighttpd</tt>, and <a |
| 90 | 94 | href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server |
| 91 | 95 | administrator places a <a href="/help?cmd=cgi">short CGI script</a> in |
| 92 | -the web server's document hierarchy, and when a client requests the | |
| 93 | -appropriate URL, that script runs Fossil to generate the response.</p> | |
| 96 | +the web server's document hierarchy, and when a client requests the URL | |
| 97 | +that corresponds to that script, the script runs Fossil to generate the | |
| 98 | +response.</p> | |
| 94 | 99 | |
| 95 | 100 | <p>CGI is a good choice for merging Fossil into an existing web site, |
| 96 | 101 | particularly on hosts that have CGI set up for you already and won't let |
| 97 | 102 | you modify the web server configuration further. The Fossil <a |
| 98 | 103 | href="../selfhost.wiki">self-hosting repositories</a> are implemented |
| 99 | 104 | with CGI underneath <tt>althttpd</tt>.</p> |
| 100 | 105 | |
| 101 | -<h3>Stand-alone HTTP Server</h3> | |
| 102 | - | |
| 103 | -<p>This is the <a href="any/none.md">easiest method</a>. | |
| 104 | -A stand-alone server uses the <a | |
| 105 | -href="/help?cmd=server"><tt>fossil server</tt></a> command to run a | |
| 106 | -process that listens for incoming HTTP requests on a socket and then | |
| 107 | -dispatches a copy of itself to deal with each incoming request. You can | |
| 108 | -expose Fossil directly to the clients in this way or you can interpose a | |
| 109 | -<a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> | |
| 110 | -layer between the clients and Fossil.</p> | |
| 111 | - | |
| 112 | 106 | <h3>Socket Listener</h3> |
| 113 | 107 | |
| 114 | 108 | <p>Only slightly more complicated is the socket listener method. |
| 115 | 109 | Instead of letting Fossil run in the background continuously to handle |
| 116 | 110 | HTTP requests from clients, you configure a socket listener daemon to |
| @@ -122,10 +116,21 @@ | ||
| 122 | 116 | href="any/xinetd.md"><tt>xinetd</tt></a>, <a id="stunnel" |
| 123 | 117 | href="any/stunnel.md"><tt>stunnel</tt></a>, <a |
| 124 | 118 | href="macos/service.md"><tt>launchd</tt></a>, and <a |
| 125 | 119 | href="debian/service.md"><tt>systemd</tt></a>.</p> |
| 126 | 120 | |
| 121 | +<h3>Stand-alone HTTP Server</h3> | |
| 122 | + | |
| 123 | +<p>This is the <a href="any/none.md">easiest method</a>. | |
| 124 | +A stand-alone server uses the <a | |
| 125 | +href="/help?cmd=server"><tt>fossil server</tt></a> command to run a | |
| 126 | +process that listens for incoming HTTP requests on a socket and then | |
| 127 | +dispatches a copy of itself to deal with each incoming request. You can | |
| 128 | +expose Fossil directly to the clients in this way or you can interpose a | |
| 129 | +<a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> | |
| 130 | +layer between the clients and Fossil.</p> | |
| 131 | + | |
| 127 | 132 | <h3>SCGI</h3> |
| 128 | 133 | |
| 129 | 134 | <p>The Fossil standalone server can also run <a href="any/scgi.md">in |
| 130 | 135 | SCGI mode</a> — <a href="/help/server"><tt>fossil server --scgi</tt></a> |
| 131 | 136 | — instead of <a href="any/none.md">HTTP mode</a>, which allows it to |
| 132 | 137 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -52,25 +52,29 @@ | |
| 52 | |
| 53 | |
| 54 | <h2>No Server Required</h2> |
| 55 | |
| 56 | <p>Fossil does not require a central server, but <a |
| 57 | href="whyuseaserver.wiki">a server can be very useful</a>.</p> |
| 58 | |
| 59 | <p>This article is a quick-reference guide for setting up your own |
| 60 | Fossil server, with links to more detailed instructions specific to |
| 61 | particular systems, should you want extra help.</p> |
| 62 | |
| 63 | |
| 64 | <h2 id="methods">Methods</h2> |
| 65 | |
| 66 | <p>There are basically four ways to set up a Fossil server:</p> |
| 67 | |
| 68 | <ol> |
| 69 | <li><a id="cgi" href="any/cgi.md">CGI</a> |
| 70 | <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> |
| 71 | <li>Socket listener |
| 72 | <li><a id="scgi" href="any/scgi.md">SCGI</a> |
| 73 | </ol> |
| 74 | |
| 75 | <p>All of these methods can serve either a single repository or a |
| 76 | directory containing repositories named "<tt>*.fossil</tt>".</p> |
| @@ -87,30 +91,20 @@ | |
| 87 | <p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a |
| 88 | CGI script</a>. This method is known to work with Apache, |
| 89 | <tt>lighttpd</tt>, and <a |
| 90 | href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server |
| 91 | administrator places a <a href="/help?cmd=cgi">short CGI script</a> in |
| 92 | the web server's document hierarchy, and when a client requests the |
| 93 | appropriate URL, that script runs Fossil to generate the response.</p> |
| 94 | |
| 95 | <p>CGI is a good choice for merging Fossil into an existing web site, |
| 96 | particularly on hosts that have CGI set up for you already and won't let |
| 97 | you modify the web server configuration further. The Fossil <a |
| 98 | href="../selfhost.wiki">self-hosting repositories</a> are implemented |
| 99 | with CGI underneath <tt>althttpd</tt>.</p> |
| 100 | |
| 101 | <h3>Stand-alone HTTP Server</h3> |
| 102 | |
| 103 | <p>This is the <a href="any/none.md">easiest method</a>. |
| 104 | A stand-alone server uses the <a |
| 105 | href="/help?cmd=server"><tt>fossil server</tt></a> command to run a |
| 106 | process that listens for incoming HTTP requests on a socket and then |
| 107 | dispatches a copy of itself to deal with each incoming request. You can |
| 108 | expose Fossil directly to the clients in this way or you can interpose a |
| 109 | <a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> |
| 110 | layer between the clients and Fossil.</p> |
| 111 | |
| 112 | <h3>Socket Listener</h3> |
| 113 | |
| 114 | <p>Only slightly more complicated is the socket listener method. |
| 115 | Instead of letting Fossil run in the background continuously to handle |
| 116 | HTTP requests from clients, you configure a socket listener daemon to |
| @@ -122,10 +116,21 @@ | |
| 122 | href="any/xinetd.md"><tt>xinetd</tt></a>, <a id="stunnel" |
| 123 | href="any/stunnel.md"><tt>stunnel</tt></a>, <a |
| 124 | href="macos/service.md"><tt>launchd</tt></a>, and <a |
| 125 | href="debian/service.md"><tt>systemd</tt></a>.</p> |
| 126 | |
| 127 | <h3>SCGI</h3> |
| 128 | |
| 129 | <p>The Fossil standalone server can also run <a href="any/scgi.md">in |
| 130 | SCGI mode</a> — <a href="/help/server"><tt>fossil server --scgi</tt></a> |
| 131 | — instead of <a href="any/none.md">HTTP mode</a>, which allows it to |
| 132 |
| --- www/server/index.html | |
| +++ www/server/index.html | |
| @@ -52,25 +52,29 @@ | |
| 52 | |
| 53 | |
| 54 | <h2>No Server Required</h2> |
| 55 | |
| 56 | <p>Fossil does not require a central server, but <a |
| 57 | href="whyuseaserver.wiki">a server can be useful</a>.</p> |
| 58 | |
| 59 | <p>A Fossil server does not require much memory, CPU, or disk space |
| 60 | and can run comfortably on a generic $5/month virtual host |
| 61 | or on a small device like a RaspberryPI, or it can co-exist |
| 62 | on a host running other services without getting in the way. |
| 63 | |
| 64 | <p>This article is a quick-reference guide for setting up your own |
| 65 | Fossil server, with links to more detailed instructions specific to |
| 66 | particular systems, should you want extra help.</p> |
| 67 | |
| 68 | <h2 id="methods">Methods</h2> |
| 69 | |
| 70 | <p>There are basically four ways to set up a Fossil server:</p> |
| 71 | |
| 72 | <ol> |
| 73 | <li><a id="cgi" href="any/cgi.md">CGI</a> |
| 74 | <li>Socket listener |
| 75 | <li><a id="standalone" href="any/none.md">Stand-alone HTTP server</a> |
| 76 | <li><a id="scgi" href="any/scgi.md">SCGI</a> |
| 77 | </ol> |
| 78 | |
| 79 | <p>All of these methods can serve either a single repository or a |
| 80 | directory containing repositories named "<tt>*.fossil</tt>".</p> |
| @@ -87,30 +91,20 @@ | |
| 91 | <p>Most ordinary web servers can <a href="any/cgi.md">run Fossil as a |
| 92 | CGI script</a>. This method is known to work with Apache, |
| 93 | <tt>lighttpd</tt>, and <a |
| 94 | href="any/althttpd.md"><tt>althttpd</tt></a>. The Fossil server |
| 95 | administrator places a <a href="/help?cmd=cgi">short CGI script</a> in |
| 96 | the web server's document hierarchy, and when a client requests the URL |
| 97 | that corresponds to that script, the script runs Fossil to generate the |
| 98 | response.</p> |
| 99 | |
| 100 | <p>CGI is a good choice for merging Fossil into an existing web site, |
| 101 | particularly on hosts that have CGI set up for you already and won't let |
| 102 | you modify the web server configuration further. The Fossil <a |
| 103 | href="../selfhost.wiki">self-hosting repositories</a> are implemented |
| 104 | with CGI underneath <tt>althttpd</tt>.</p> |
| 105 | |
| 106 | <h3>Socket Listener</h3> |
| 107 | |
| 108 | <p>Only slightly more complicated is the socket listener method. |
| 109 | Instead of letting Fossil run in the background continuously to handle |
| 110 | HTTP requests from clients, you configure a socket listener daemon to |
| @@ -122,10 +116,21 @@ | |
| 116 | href="any/xinetd.md"><tt>xinetd</tt></a>, <a id="stunnel" |
| 117 | href="any/stunnel.md"><tt>stunnel</tt></a>, <a |
| 118 | href="macos/service.md"><tt>launchd</tt></a>, and <a |
| 119 | href="debian/service.md"><tt>systemd</tt></a>.</p> |
| 120 | |
| 121 | <h3>Stand-alone HTTP Server</h3> |
| 122 | |
| 123 | <p>This is the <a href="any/none.md">easiest method</a>. |
| 124 | A stand-alone server uses the <a |
| 125 | href="/help?cmd=server"><tt>fossil server</tt></a> command to run a |
| 126 | process that listens for incoming HTTP requests on a socket and then |
| 127 | dispatches a copy of itself to deal with each incoming request. You can |
| 128 | expose Fossil directly to the clients in this way or you can interpose a |
| 129 | <a href="https://en.wikipedia.org/wiki/Reverse_proxy">reverse proxy</a> |
| 130 | layer between the clients and Fossil.</p> |
| 131 | |
| 132 | <h3>SCGI</h3> |
| 133 | |
| 134 | <p>The Fossil standalone server can also run <a href="any/scgi.md">in |
| 135 | SCGI mode</a> — <a href="/help/server"><tt>fossil server --scgi</tt></a> |
| 136 | — instead of <a href="any/none.md">HTTP mode</a>, which allows it to |
| 137 |
+13
-10
| --- www/server/whyuseaserver.wiki | ||
| +++ www/server/whyuseaserver.wiki | ||
| @@ -1,10 +1,10 @@ | ||
| 1 | 1 | <title>Benefits Of A Fossil Server</title> |
| 2 | 2 | |
| 3 | 3 | <h2>No Server Required</h2> |
| 4 | 4 | |
| 5 | -Fossil does <em>not</em> require a central server. | |
| 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,27 +11,30 @@ | ||
| 11 | 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 | - 1. <b>A server gives developers a common point of rendezvous for | |
| 16 | + 1. <b>A server works as a complete project website.</b><p> | |
| 17 | + Fossil does more than just version control. It also supports | |
| 18 | + [../tickets.wiki|trouble-tickets], | |
| 19 | + [../wikitheory.wiki|wiki], and a [../forum.wiki|forum]. | |
| 20 | + The [../embeddeddoc.wiki|embedded documentation] | |
| 21 | + feature provides a great mechanism for providing project documentation. | |
| 22 | + The [../unvers.wiki|unversioned files] feature is a convenient way | |
| 23 | + to host builds and downloads on the project website. | |
| 24 | + | |
| 25 | + 2. <b>A server gives developers a common point of rendezvous for | |
| 17 | 26 | syncing their work.</b><p> |
| 18 | - It is possible for developers to synchronous peer-to-peer but | |
| 27 | + It is possible for developers to synchronize peer-to-peer but | |
| 19 | 28 | that requires the developers coordinate the sync, which in turn |
| 20 | 29 | requires that the developers both want to sync at the same moment. |
| 21 | 30 | A server aleviates this time dependency by allowing each developer |
| 22 | 31 | to sync whenever it is convenient (for example, automatically syncing |
| 23 | 32 | after each commit and before each update). Developers all stay |
| 24 | 33 | in sync with each other, without having to interrupt each other |
| 25 | 34 | constantly to set up a peer-to-peer sync. |
| 26 | 35 | |
| 27 | - 2. <b>A server works as a project website for non-developers.</b><p> | |
| 28 | - Fossil does more than just version control. It also supports | |
| 29 | - trouble-tickets, and wiki, and a forum. It shows the status | |
| 30 | - of the project. And the embedded documentation feature provides | |
| 31 | - a great mechanism for providing only instructions. | |
| 32 | - | |
| 33 | 36 | 3. <b>A server provides project leaders with up-to-date status.</b><p> |
| 34 | 37 | Project coordinators and BDFLs can click on a link or two at the |
| 35 | 38 | central Fossil server for a project, and quickly tell what is |
| 36 | 39 | going on. They can do this from anywhere, even from their phones, |
| 37 | 40 | without needing to actually sync to the device they are using. |
| @@ -39,6 +42,6 @@ | ||
| 39 | 42 | 4. <b>A server provides automatic off-site backups.</b><p> |
| 40 | 43 | A Fossil server is an automatic remote backup for all the work |
| 41 | 44 | going into a project. You can even set up multiple servers, at |
| 42 | 45 | multiple sites, with automatic synchronization between them, for |
| 43 | 46 | added redundancy. Such a set up means that no work is lost due |
| 44 | - to a single machine failure. | |
| 47 | + to a single machine failur | |
| 45 | 48 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -1,10 +1,10 @@ | |
| 1 | <title>Benefits Of A Fossil Server</title> |
| 2 | |
| 3 | <h2>No Server Required</h2> |
| 4 | |
| 5 | Fossil does <em>not</em> 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,27 +11,30 @@ | |
| 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 gives developers a common point of rendezvous for |
| 17 | syncing their work.</b><p> |
| 18 | It is possible for developers to synchronous peer-to-peer but |
| 19 | that requires the developers coordinate the sync, which in turn |
| 20 | requires that the developers both want to sync at the same moment. |
| 21 | A server aleviates this time dependency by allowing each developer |
| 22 | to sync whenever it is convenient (for example, automatically syncing |
| 23 | after each commit and before each update). Developers all stay |
| 24 | in sync with each other, without having to interrupt each other |
| 25 | constantly to set up a peer-to-peer sync. |
| 26 | |
| 27 | 2. <b>A server works as a project website for non-developers.</b><p> |
| 28 | Fossil does more than just version control. It also supports |
| 29 | trouble-tickets, and wiki, and a forum. It shows the status |
| 30 | of the project. And the embedded documentation feature provides |
| 31 | a great mechanism for providing only instructions. |
| 32 | |
| 33 | 3. <b>A server provides project leaders with up-to-date status.</b><p> |
| 34 | Project coordinators and BDFLs can click on a link or two at the |
| 35 | central Fossil server for a project, and quickly tell what is |
| 36 | going on. They can do this from anywhere, even from their phones, |
| 37 | without needing to actually sync to the device they are using. |
| @@ -39,6 +42,6 @@ | |
| 39 | 4. <b>A server provides automatic off-site backups.</b><p> |
| 40 | A Fossil server is an automatic remote backup for all the work |
| 41 | going into a project. You can even set up multiple servers, at |
| 42 | multiple sites, with automatic synchronization between them, for |
| 43 | added redundancy. Such a set up means that no work is lost due |
| 44 | to a single machine failure. |
| 45 |
| --- www/server/whyuseaserver.wiki | |
| +++ www/server/whyuseaserver.wiki | |
| @@ -1,10 +1,10 @@ | |
| 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,27 +11,30 @@ | |
| 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> |
| 17 | Fossil does more than just version control. It also supports |
| 18 | [../tickets.wiki|trouble-tickets], |
| 19 | [../wikitheory.wiki|wiki], and a [../forum.wiki|forum]. |
| 20 | The [../embeddeddoc.wiki|embedded documentation] |
| 21 | feature provides a great mechanism for providing project documentation. |
| 22 | The [../unvers.wiki|unversioned files] feature is a convenient way |
| 23 | to host builds and downloads on the project website. |
| 24 | |
| 25 | 2. <b>A server gives developers a common point of rendezvous for |
| 26 | syncing their work.</b><p> |
| 27 | It is possible for developers to synchronize peer-to-peer but |
| 28 | that requires the developers coordinate the sync, which in turn |
| 29 | requires that the developers both want to sync at the same moment. |
| 30 | A server aleviates this time dependency by allowing each developer |
| 31 | to sync whenever it is convenient (for example, automatically syncing |
| 32 | after each commit and before each update). Developers all stay |
| 33 | in sync with each other, without having to interrupt each other |
| 34 | constantly to set up a peer-to-peer sync. |
| 35 | |
| 36 | 3. <b>A server provides project leaders with up-to-date status.</b><p> |
| 37 | Project coordinators and BDFLs can click on a link or two at the |
| 38 | central Fossil server for a project, and quickly tell what is |
| 39 | going on. They can do this from anywhere, even from their phones, |
| 40 | without needing to actually sync to the device they are using. |
| @@ -39,6 +42,6 @@ | |
| 42 | 4. <b>A server provides automatic off-site backups.</b><p> |
| 43 | A Fossil server is an automatic remote backup for all the work |
| 44 | going into a project. You can even set up multiple servers, at |
| 45 | multiple sites, with automatic synchronization between them, for |
| 46 | added redundancy. Such a set up means that no work is lost due |
| 47 | to a single machine failur |
| 48 |