Fossil SCM
Website edits, especially to the fossil-v-git document.
Commit
ae391ce62471fa59a2c8bea01ee6fcc361520ffd
Parent
3ee0046529c500d…
3 files changed
+56
-11
+5
-6
+1
-1
+56
-11
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -17,17 +17,20 @@ | ||
| 17 | 17 | <h2>2.0 Executive Summary:</h2> |
| 18 | 18 | |
| 19 | 19 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | 20 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | 21 | <tr><td>File versioning only</td> |
| 22 | - <td>Versioning, Tickets, Wiki, and Blog/News</td></tr> | |
| 22 | + <td>Versioning, Tickets, Wiki, and Technotes</td></tr> | |
| 23 | 23 | <tr><td>Sharding</td><td>Replicating</td></tr> |
| 24 | 24 | <tr><td>Developer branches</td><td>Feature branches</td></tr> |
| 25 | 25 | <tr><td>Complex</td><td>Intuitive</td></tr> |
| 26 | 26 | <tr><td>Separate web tools</td><td>Integrated Web interface</td></tr> |
| 27 | 27 | <tr><td>Lots of little tools</td><td>Single executable</td></tr> |
| 28 | -<tr><td>Pile-of-files repository</td><td>Single file repository</td></tr> | |
| 28 | +<tr><td>Pile-of-files repository</td> | |
| 29 | + <td>Single-file relational database</td></tr> | |
| 30 | +<tr><td>One check-out per repository</td> | |
| 31 | + <td>Many check-outs per repository</td></tr> | |
| 29 | 32 | <tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> |
| 30 | 33 | <tr><td>GPL</td><td>BSD</td></tr> |
| 31 | 34 | </table></center></blockquote> |
| 32 | 35 | |
| 33 | 36 | <h2>3.0 Discussion</h2> |
| @@ -36,11 +39,11 @@ | ||
| 36 | 39 | |
| 37 | 40 | Git provides file versioning services only, whereas Fossil adds an |
| 38 | 41 | integrated [./wikitheory.wiki | wiki], |
| 39 | 42 | [./bugtheory.wiki | ticketing & bug tracking], |
| 40 | 43 | [./embeddeddoc.wiki | embedded documentation], and |
| 41 | -[./event.wiki | News/Blog features]. | |
| 44 | +[./event.wiki | Technical notes]. | |
| 42 | 45 | These additional capabilities are available for Git as 3rd-party |
| 43 | 46 | user-installed add-ons, but with Fossil they are integrated into |
| 44 | 47 | the design. One way to describe Fossil is that it is |
| 45 | 48 | "[https://github.com/ | github]-in-a-box". |
| 46 | 49 | |
| @@ -148,10 +151,13 @@ | ||
| 148 | 151 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 149 | 152 | require little thinking about how to operating it. |
| 150 | 153 | [./quotes.wiki | Reports from the field] |
| 151 | 154 | indicate that Fossil is mostly successful at this effort. |
| 152 | 155 | |
| 156 | +Fossil will <u>never</u> get you into anything like the | |
| 157 | +"disconnected head state" which has frustrated so many Git users. | |
| 158 | + | |
| 153 | 159 | <h3>3.5 Web Interface</h3> |
| 154 | 160 | |
| 155 | 161 | Git has a web interface, but it requires a fair amount of setup and an |
| 156 | 162 | external web server. Fossil comes with a fully functional |
| 157 | 163 | [./webui.wiki | built-in web-server] |
| @@ -189,11 +195,27 @@ | ||
| 189 | 195 | repository can serve multiple simultaneous working checkouts. |
| 190 | 196 | A Fossil repository is an SQLite database, so it is highly resistant |
| 191 | 197 | to damage from a power-loss or system crash - incomplete transactions |
| 192 | 198 | are simply rolled back after the system reboots. |
| 193 | 199 | |
| 194 | -<h3>3.8 Audit Trail</h3> | |
| 200 | +<h3>3.8 Check-outs Per Repository</h3> | |
| 201 | + | |
| 202 | +In Git, a check-out and a repository are joined in a fundamental way | |
| 203 | +so that only a single version of the project history, or a single branch, | |
| 204 | +can be open at once. If you have a project with multiple branches and | |
| 205 | +you want to have two or more branches open at the same time (perhaps to | |
| 206 | +do performance comparisons, or maybe to run simultaneous builds using | |
| 207 | +different compile-time options) then in Git you actually have to create | |
| 208 | +a new clone of the repository for each open checkout. | |
| 209 | + | |
| 210 | +In Fossil, the repository and the check-out are distinct entities and | |
| 211 | +so a single repository can support multiple simultaneous checkouts. | |
| 212 | +This feature is <em>extensively</em> used by the Fossil developers | |
| 213 | +themselves. Perhaps we are biased, but we not understand how anyone | |
| 214 | +can work efficiently with just one check-out per repository. | |
| 215 | + | |
| 216 | +<h3>3.9 Audit Trail</h3> | |
| 195 | 217 | |
| 196 | 218 | Git features the "rebase" command which can be used to change the |
| 197 | 219 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 198 | 220 | a complex sequence of check-ins to make their intent easier for others |
| 199 | 221 | to understand. This is important if you view the history of a project |
| @@ -204,24 +226,47 @@ | ||
| 204 | 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 205 | 227 | can be revised, and check-ins can be moved onto new branches even after |
| 206 | 228 | the check-in has occurred) but the correction is an addition to the repository |
| 207 | 229 | and the original actions are preserved and displayed alongside |
| 208 | 230 | the corrections, thus preserving an historically accurate audit trail. |
| 209 | -This is analogous to an accountant marking through an incorrect | |
| 210 | -entry in a ledger and writing in a correction beside it, rather than | |
| 211 | -erasing and incorrect entry. | |
| 231 | +This is analogous to an accounting practice of marking through an incorrect | |
| 232 | +entry in a ledger and writing a correction beside it. | |
| 233 | + | |
| 212 | 234 | |
| 213 | 235 | To put it another way, Git remembers what you should have done whereas |
| 214 | 236 | Fossil remembers what you actually did. |
| 215 | 237 | |
| 216 | 238 | The lack of a "rebase" command and the inability to rewrite history |
| 217 | 239 | is considered a feature of Fossil, not an omission or bug. |
| 218 | 240 | |
| 219 | -<h3>3.9 License</h3> | |
| 241 | +<h3>3.10 License</h3> | |
| 220 | 242 | |
| 221 | 243 | Both Git and Fossil are open-source. Git is under |
| 222 | 244 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 223 | 245 | under the |
| 224 | 246 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 225 | -The difference should not be of a concern to most users. However, | |
| 226 | -some corporate lawyers have objections to using GPL products and | |
| 227 | -are more comfortable with a BSD-style license. | |
| 247 | +The different licenses parallel, to some extent, the different philosophies | |
| 248 | +of Git and Fossil. | |
| 249 | +There are exceptions on both sides, but to a first approximation, Git | |
| 250 | +works better for GPL projects and Fossil works better for BSD projects. | |
| 251 | + | |
| 252 | +The GPL is designed to provide a very contributor-friendly environment. | |
| 253 | +No legal paperwork is needed to contribute to a GPL project because | |
| 254 | +the GPL is cleverly designed so that the act of contributing | |
| 255 | +to the project (or even reading the code for the project) constitutes | |
| 256 | +an acceptance of the licensing terms. GPL encourages a bazaar-style | |
| 257 | +development model, with lots of anonymous programmers contributing | |
| 258 | +drive-by patches. The theory is that with many eyeballs, all bugs | |
| 259 | +are shallow. Surprisingly, this has actually been demonstrated to | |
| 260 | +work in many well-known projects. | |
| 261 | + | |
| 262 | +The BSD-style licenses are more user-friendly. BSD-style licenses | |
| 263 | +place fewer restrictions on the users of the software at the expense | |
| 264 | +of making it more difficult to contribute changes or enhancements. | |
| 265 | +To protect against IP claims, | |
| 266 | +every contributor to a BSD-style project must sign legal documents in | |
| 267 | +which they agree to release their contributions under the same license. | |
| 268 | +(Some BSD-licensed projects omit this formality, but do so at their peril.) | |
| 269 | +A BSD-style license encourages a more cathedral-style approach to development. | |
| 270 | +There is a small team of developers. Drive-by patches and anonymous | |
| 271 | +contributors are discouraged and/or prohibited. Contributors are expected | |
| 272 | +to be experts and be available to support their changes for the long-term. | |
| 228 | 273 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -17,17 +17,20 @@ | |
| 17 | <h2>2.0 Executive Summary:</h2> |
| 18 | |
| 19 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | <tr><td>File versioning only</td> |
| 22 | <td>Versioning, Tickets, Wiki, and Blog/News</td></tr> |
| 23 | <tr><td>Sharding</td><td>Replicating</td></tr> |
| 24 | <tr><td>Developer branches</td><td>Feature branches</td></tr> |
| 25 | <tr><td>Complex</td><td>Intuitive</td></tr> |
| 26 | <tr><td>Separate web tools</td><td>Integrated Web interface</td></tr> |
| 27 | <tr><td>Lots of little tools</td><td>Single executable</td></tr> |
| 28 | <tr><td>Pile-of-files repository</td><td>Single file repository</td></tr> |
| 29 | <tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> |
| 30 | <tr><td>GPL</td><td>BSD</td></tr> |
| 31 | </table></center></blockquote> |
| 32 | |
| 33 | <h2>3.0 Discussion</h2> |
| @@ -36,11 +39,11 @@ | |
| 36 | |
| 37 | Git provides file versioning services only, whereas Fossil adds an |
| 38 | integrated [./wikitheory.wiki | wiki], |
| 39 | [./bugtheory.wiki | ticketing & bug tracking], |
| 40 | [./embeddeddoc.wiki | embedded documentation], and |
| 41 | [./event.wiki | News/Blog features]. |
| 42 | These additional capabilities are available for Git as 3rd-party |
| 43 | user-installed add-ons, but with Fossil they are integrated into |
| 44 | the design. One way to describe Fossil is that it is |
| 45 | "[https://github.com/ | github]-in-a-box". |
| 46 | |
| @@ -148,10 +151,13 @@ | |
| 148 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 149 | require little thinking about how to operating it. |
| 150 | [./quotes.wiki | Reports from the field] |
| 151 | indicate that Fossil is mostly successful at this effort. |
| 152 | |
| 153 | <h3>3.5 Web Interface</h3> |
| 154 | |
| 155 | Git has a web interface, but it requires a fair amount of setup and an |
| 156 | external web server. Fossil comes with a fully functional |
| 157 | [./webui.wiki | built-in web-server] |
| @@ -189,11 +195,27 @@ | |
| 189 | repository can serve multiple simultaneous working checkouts. |
| 190 | A Fossil repository is an SQLite database, so it is highly resistant |
| 191 | to damage from a power-loss or system crash - incomplete transactions |
| 192 | are simply rolled back after the system reboots. |
| 193 | |
| 194 | <h3>3.8 Audit Trail</h3> |
| 195 | |
| 196 | Git features the "rebase" command which can be used to change the |
| 197 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 198 | a complex sequence of check-ins to make their intent easier for others |
| 199 | to understand. This is important if you view the history of a project |
| @@ -204,24 +226,47 @@ | |
| 204 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 205 | can be revised, and check-ins can be moved onto new branches even after |
| 206 | the check-in has occurred) but the correction is an addition to the repository |
| 207 | and the original actions are preserved and displayed alongside |
| 208 | the corrections, thus preserving an historically accurate audit trail. |
| 209 | This is analogous to an accountant marking through an incorrect |
| 210 | entry in a ledger and writing in a correction beside it, rather than |
| 211 | erasing and incorrect entry. |
| 212 | |
| 213 | To put it another way, Git remembers what you should have done whereas |
| 214 | Fossil remembers what you actually did. |
| 215 | |
| 216 | The lack of a "rebase" command and the inability to rewrite history |
| 217 | is considered a feature of Fossil, not an omission or bug. |
| 218 | |
| 219 | <h3>3.9 License</h3> |
| 220 | |
| 221 | Both Git and Fossil are open-source. Git is under |
| 222 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 223 | under the |
| 224 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 225 | The difference should not be of a concern to most users. However, |
| 226 | some corporate lawyers have objections to using GPL products and |
| 227 | are more comfortable with a BSD-style license. |
| 228 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -17,17 +17,20 @@ | |
| 17 | <h2>2.0 Executive Summary:</h2> |
| 18 | |
| 19 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | <tr><td>File versioning only</td> |
| 22 | <td>Versioning, Tickets, Wiki, and Technotes</td></tr> |
| 23 | <tr><td>Sharding</td><td>Replicating</td></tr> |
| 24 | <tr><td>Developer branches</td><td>Feature branches</td></tr> |
| 25 | <tr><td>Complex</td><td>Intuitive</td></tr> |
| 26 | <tr><td>Separate web tools</td><td>Integrated Web interface</td></tr> |
| 27 | <tr><td>Lots of little tools</td><td>Single executable</td></tr> |
| 28 | <tr><td>Pile-of-files repository</td> |
| 29 | <td>Single-file relational database</td></tr> |
| 30 | <tr><td>One check-out per repository</td> |
| 31 | <td>Many check-outs per repository</td></tr> |
| 32 | <tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> |
| 33 | <tr><td>GPL</td><td>BSD</td></tr> |
| 34 | </table></center></blockquote> |
| 35 | |
| 36 | <h2>3.0 Discussion</h2> |
| @@ -36,11 +39,11 @@ | |
| 39 | |
| 40 | Git provides file versioning services only, whereas Fossil adds an |
| 41 | integrated [./wikitheory.wiki | wiki], |
| 42 | [./bugtheory.wiki | ticketing & bug tracking], |
| 43 | [./embeddeddoc.wiki | embedded documentation], and |
| 44 | [./event.wiki | Technical notes]. |
| 45 | These additional capabilities are available for Git as 3rd-party |
| 46 | user-installed add-ons, but with Fossil they are integrated into |
| 47 | the design. One way to describe Fossil is that it is |
| 48 | "[https://github.com/ | github]-in-a-box". |
| 49 | |
| @@ -148,10 +151,13 @@ | |
| 151 | Fossil strives for simplicity. Fossil wants to be easy to learn and to |
| 152 | require little thinking about how to operating it. |
| 153 | [./quotes.wiki | Reports from the field] |
| 154 | indicate that Fossil is mostly successful at this effort. |
| 155 | |
| 156 | Fossil will <u>never</u> get you into anything like the |
| 157 | "disconnected head state" which has frustrated so many Git users. |
| 158 | |
| 159 | <h3>3.5 Web Interface</h3> |
| 160 | |
| 161 | Git has a web interface, but it requires a fair amount of setup and an |
| 162 | external web server. Fossil comes with a fully functional |
| 163 | [./webui.wiki | built-in web-server] |
| @@ -189,11 +195,27 @@ | |
| 195 | repository can serve multiple simultaneous working checkouts. |
| 196 | A Fossil repository is an SQLite database, so it is highly resistant |
| 197 | to damage from a power-loss or system crash - incomplete transactions |
| 198 | are simply rolled back after the system reboots. |
| 199 | |
| 200 | <h3>3.8 Check-outs Per Repository</h3> |
| 201 | |
| 202 | In Git, a check-out and a repository are joined in a fundamental way |
| 203 | so that only a single version of the project history, or a single branch, |
| 204 | can be open at once. If you have a project with multiple branches and |
| 205 | you want to have two or more branches open at the same time (perhaps to |
| 206 | do performance comparisons, or maybe to run simultaneous builds using |
| 207 | different compile-time options) then in Git you actually have to create |
| 208 | a new clone of the repository for each open checkout. |
| 209 | |
| 210 | In Fossil, the repository and the check-out are distinct entities and |
| 211 | so a single repository can support multiple simultaneous checkouts. |
| 212 | This feature is <em>extensively</em> used by the Fossil developers |
| 213 | themselves. Perhaps we are biased, but we not understand how anyone |
| 214 | can work efficiently with just one check-out per repository. |
| 215 | |
| 216 | <h3>3.9 Audit Trail</h3> |
| 217 | |
| 218 | Git features the "rebase" command which can be used to change the |
| 219 | sequence of check-ins in the repository. Rebase can be used to "clean up" |
| 220 | a complex sequence of check-ins to make their intent easier for others |
| 221 | to understand. This is important if you view the history of a project |
| @@ -204,24 +226,47 @@ | |
| 226 | Fossil allows mistakes to be corrected (for example, check-in comments |
| 227 | can be revised, and check-ins can be moved onto new branches even after |
| 228 | the check-in has occurred) but the correction is an addition to the repository |
| 229 | and the original actions are preserved and displayed alongside |
| 230 | the corrections, thus preserving an historically accurate audit trail. |
| 231 | This is analogous to an accounting practice of marking through an incorrect |
| 232 | entry in a ledger and writing a correction beside it. |
| 233 | |
| 234 | |
| 235 | To put it another way, Git remembers what you should have done whereas |
| 236 | Fossil remembers what you actually did. |
| 237 | |
| 238 | The lack of a "rebase" command and the inability to rewrite history |
| 239 | is considered a feature of Fossil, not an omission or bug. |
| 240 | |
| 241 | <h3>3.10 License</h3> |
| 242 | |
| 243 | Both Git and Fossil are open-source. Git is under |
| 244 | [http://www.gnu.org/licenses/gpl.html | GPL] whereas Fossil is |
| 245 | under the |
| 246 | [http://en.wikipedia.org/wiki/BSD_licenses | two-clause BSD license]. |
| 247 | The different licenses parallel, to some extent, the different philosophies |
| 248 | of Git and Fossil. |
| 249 | There are exceptions on both sides, but to a first approximation, Git |
| 250 | works better for GPL projects and Fossil works better for BSD projects. |
| 251 | |
| 252 | The GPL is designed to provide a very contributor-friendly environment. |
| 253 | No legal paperwork is needed to contribute to a GPL project because |
| 254 | the GPL is cleverly designed so that the act of contributing |
| 255 | to the project (or even reading the code for the project) constitutes |
| 256 | an acceptance of the licensing terms. GPL encourages a bazaar-style |
| 257 | development model, with lots of anonymous programmers contributing |
| 258 | drive-by patches. The theory is that with many eyeballs, all bugs |
| 259 | are shallow. Surprisingly, this has actually been demonstrated to |
| 260 | work in many well-known projects. |
| 261 | |
| 262 | The BSD-style licenses are more user-friendly. BSD-style licenses |
| 263 | place fewer restrictions on the users of the software at the expense |
| 264 | of making it more difficult to contribute changes or enhancements. |
| 265 | To protect against IP claims, |
| 266 | every contributor to a BSD-style project must sign legal documents in |
| 267 | which they agree to release their contributions under the same license. |
| 268 | (Some BSD-licensed projects omit this formality, but do so at their peril.) |
| 269 | A BSD-style license encourages a more cathedral-style approach to development. |
| 270 | There is a small team of developers. Drive-by patches and anonymous |
| 271 | contributors are discouraged and/or prohibited. Contributors are expected |
| 272 | to be experts and be available to support their changes for the long-term. |
| 273 |
+5
-6
| --- www/index.wiki | ||
| +++ www/index.wiki | ||
| @@ -45,32 +45,31 @@ | ||
| 45 | 45 | are all [./wikitheory.wiki | wiki] or |
| 46 | 46 | [./embeddeddoc.wiki | embedded documentation]. |
| 47 | 47 | When you clone Fossil from one of its |
| 48 | 48 | [./selfhost.wiki | self-hosting repositories], |
| 49 | 49 | you get more than just source code - you get this entire website. |
| 50 | - <small><i>([1] except the | |
| 51 | - [http://www.fossil-scm.org/download.html | download] page)</i></small> | |
| 50 | + <span style='font-size:75%;'>(¹except the | |
| 51 | + [http://www.fossil-scm.org/download.html | download] page)</span> | |
| 52 | 52 | |
| 53 | 53 | 3. <b>Self-Contained</b> - |
| 54 | 54 | Fossil is a single self-contained stand-alone executable. |
| 55 | 55 | To install, simply download a |
| 56 | 56 | <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> |
| 57 | 57 | for Linux, Mac, OpenBSD, or Windows and put it on your $PATH. |
| 58 | - [./build.wiki | Easy-to-compile source code] is available for | |
| 59 | - users on other platforms. | |
| 58 | + [./build.wiki | Easy-to-compile source code] is also available. | |
| 60 | 59 | |
| 61 | 60 | 4. <b>Simple Networking</b> - |
| 62 | 61 | No custom protocols or TCP ports. |
| 63 | 62 | Fossil uses ordinary HTTP (or HTTPS or SSH) |
| 64 | - for all network communications, so it works fine from behind | |
| 63 | + for network communications, so it works fine from behind | |
| 65 | 64 | restrictive firewalls, including [./quickstart.wiki#proxy|proxies]. |
| 66 | 65 | The protocol is |
| 67 | 66 | [./stats.wiki | bandwidth efficient] to the point that Fossil can be |
| 68 | 67 | used comfortably over dial-up. |
| 69 | 68 | |
| 70 | 69 | 5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to |
| 71 | - set one up, Fossil supports four simple | |
| 70 | + set one up, Fossil supports four easy | |
| 72 | 71 | [./server.wiki | server configurations]. |
| 73 | 72 | |
| 74 | 73 | 6. <b>Autosync</b> - |
| 75 | 74 | Fossil supports [./concepts.wiki#workflow | "autosync" mode] |
| 76 | 75 | which helps to keep projects moving |
| 77 | 76 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -45,32 +45,31 @@ | |
| 45 | are all [./wikitheory.wiki | wiki] or |
| 46 | [./embeddeddoc.wiki | embedded documentation]. |
| 47 | When you clone Fossil from one of its |
| 48 | [./selfhost.wiki | self-hosting repositories], |
| 49 | you get more than just source code - you get this entire website. |
| 50 | <small><i>([1] except the |
| 51 | [http://www.fossil-scm.org/download.html | download] page)</i></small> |
| 52 | |
| 53 | 3. <b>Self-Contained</b> - |
| 54 | Fossil is a single self-contained stand-alone executable. |
| 55 | To install, simply download a |
| 56 | <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> |
| 57 | for Linux, Mac, OpenBSD, or Windows and put it on your $PATH. |
| 58 | [./build.wiki | Easy-to-compile source code] is available for |
| 59 | users on other platforms. |
| 60 | |
| 61 | 4. <b>Simple Networking</b> - |
| 62 | No custom protocols or TCP ports. |
| 63 | Fossil uses ordinary HTTP (or HTTPS or SSH) |
| 64 | for all network communications, so it works fine from behind |
| 65 | restrictive firewalls, including [./quickstart.wiki#proxy|proxies]. |
| 66 | The protocol is |
| 67 | [./stats.wiki | bandwidth efficient] to the point that Fossil can be |
| 68 | used comfortably over dial-up. |
| 69 | |
| 70 | 5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to |
| 71 | set one up, Fossil supports four simple |
| 72 | [./server.wiki | server configurations]. |
| 73 | |
| 74 | 6. <b>Autosync</b> - |
| 75 | Fossil supports [./concepts.wiki#workflow | "autosync" mode] |
| 76 | which helps to keep projects moving |
| 77 |
| --- www/index.wiki | |
| +++ www/index.wiki | |
| @@ -45,32 +45,31 @@ | |
| 45 | are all [./wikitheory.wiki | wiki] or |
| 46 | [./embeddeddoc.wiki | embedded documentation]. |
| 47 | When you clone Fossil from one of its |
| 48 | [./selfhost.wiki | self-hosting repositories], |
| 49 | you get more than just source code - you get this entire website. |
| 50 | <span style='font-size:75%;'>(¹except the |
| 51 | [http://www.fossil-scm.org/download.html | download] page)</span> |
| 52 | |
| 53 | 3. <b>Self-Contained</b> - |
| 54 | Fossil is a single self-contained stand-alone executable. |
| 55 | To install, simply download a |
| 56 | <a href="http://www.fossil-scm.org/download.html">precompiled binary</a> |
| 57 | for Linux, Mac, OpenBSD, or Windows and put it on your $PATH. |
| 58 | [./build.wiki | Easy-to-compile source code] is also available. |
| 59 | |
| 60 | 4. <b>Simple Networking</b> - |
| 61 | No custom protocols or TCP ports. |
| 62 | Fossil uses ordinary HTTP (or HTTPS or SSH) |
| 63 | for network communications, so it works fine from behind |
| 64 | restrictive firewalls, including [./quickstart.wiki#proxy|proxies]. |
| 65 | The protocol is |
| 66 | [./stats.wiki | bandwidth efficient] to the point that Fossil can be |
| 67 | used comfortably over dial-up. |
| 68 | |
| 69 | 5. <b>CGI/SCGI Enabled</b> - No server is required, but if you want to |
| 70 | set one up, Fossil supports four easy |
| 71 | [./server.wiki | server configurations]. |
| 72 | |
| 73 | 6. <b>Autosync</b> - |
| 74 | Fossil supports [./concepts.wiki#workflow | "autosync" mode] |
| 75 | which helps to keep projects moving |
| 76 |
+1
-1
| --- www/selfcheck.wiki | ||
| +++ www/selfcheck.wiki | ||
| @@ -44,11 +44,11 @@ | ||
| 44 | 44 | new delta-encoding mechanism designed expressly for fossil. We want |
| 45 | 45 | to make sure that bugs in these encoding mechanisms do not lead to |
| 46 | 46 | loss of data. |
| 47 | 47 | |
| 48 | 48 | To increase our confidence that everything in the repository is |
| 49 | -recoverable, fossil makes sure it can extract an exact replicate | |
| 49 | +recoverable, fossil makes sure it can extract an exact replica | |
| 50 | 50 | of every content file that it changes just prior to transaction |
| 51 | 51 | commit. So during the course of check-in (or other repository |
| 52 | 52 | operation) many different files |
| 53 | 53 | in the repository might be modified. Some files are simply |
| 54 | 54 | compressed. Other files are delta encoded and then compressed. |
| 55 | 55 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -44,11 +44,11 @@ | |
| 44 | new delta-encoding mechanism designed expressly for fossil. We want |
| 45 | to make sure that bugs in these encoding mechanisms do not lead to |
| 46 | loss of data. |
| 47 | |
| 48 | To increase our confidence that everything in the repository is |
| 49 | recoverable, fossil makes sure it can extract an exact replicate |
| 50 | of every content file that it changes just prior to transaction |
| 51 | commit. So during the course of check-in (or other repository |
| 52 | operation) many different files |
| 53 | in the repository might be modified. Some files are simply |
| 54 | compressed. Other files are delta encoded and then compressed. |
| 55 |
| --- www/selfcheck.wiki | |
| +++ www/selfcheck.wiki | |
| @@ -44,11 +44,11 @@ | |
| 44 | new delta-encoding mechanism designed expressly for fossil. We want |
| 45 | to make sure that bugs in these encoding mechanisms do not lead to |
| 46 | loss of data. |
| 47 | |
| 48 | To increase our confidence that everything in the repository is |
| 49 | recoverable, fossil makes sure it can extract an exact replica |
| 50 | of every content file that it changes just prior to transaction |
| 51 | commit. So during the course of check-in (or other repository |
| 52 | operation) many different files |
| 53 | in the repository might be modified. Some files are simply |
| 54 | compressed. Other files are delta encoded and then compressed. |
| 55 |