Fossil SCM
All 101 reasons added. Still needs refinement and probably some better grouping and reordering of the elements on the list.
Commit
1379b85489110abc49be248d8242582581cad1b2d7ddd89b9a19aa83e07054bf
Parent
f15daa89a42f396…
1 file changed
+147
-48
+147
-48
| --- www/hundredandone.md | ||
| +++ www/hundredandone.md | ||
| @@ -1,14 +1,7 @@ | ||
| 1 | 1 | # 101 Reasons Why Fossil Is Better Than Git |
| 2 | 2 | |
| 3 | -*This is a work in progress. Only 91 reasons have been typed in so far, | |
| 4 | -but I have a separate text file of notes that lists 104 candidate reasons. | |
| 5 | -It's just taking me a while to compose and edit the rationale for each | |
| 6 | -one, and to arrange the reasons in a sensible order. I will merge this | |
| 7 | -document from its current branch onto trunk when it gets closer to being | |
| 8 | -ready to publish.* | |
| 9 | - | |
| 10 | 3 | 1. **Fossil comes as a single self-contained executable file**.<p> |
| 11 | 4 | Install Fossil by copying "fossil" (or "fossil.exe") to someplace |
| 12 | 5 | on your $PATH (or %PATH%). Upgrade (or downgrade) by overwriting |
| 13 | 6 | that one file. Uninstall by deleting that one file.<p> |
| 14 | 7 | A Git installation requires hundreds of files. You want to use |
| @@ -16,15 +9,15 @@ | ||
| 16 | 9 | tinker with individual files of a Git installation, you run a high |
| 17 | 10 | risk of messing things up. |
| 18 | 11 | |
| 19 | 12 | 1. **Fossil comes with a built-in full-featured web interface**.<p> |
| 20 | 13 | The Fossil web interface is on par with GitHub, GitLab, |
| 21 | - Gitea, and similar. Some people think of Fossil as | |
| 22 | - "Github-in-a-box". Git has "gitweb", but that CGI program | |
| 14 | + Gitea, Forgejo, and similar. Some people think of Fossil as | |
| 15 | + "GitHub-in-a-box". Git has "gitweb", but that CGI program | |
| 23 | 16 | is so limited and difficult to set up and use that few people |
| 24 | - even know it exists, so I do not count it as a built-in web | |
| 25 | - interface for the purposes of this point. | |
| 17 | + even know it exists, so I do not count it | |
| 18 | + for the purposes of this point. | |
| 26 | 19 | |
| 27 | 20 | 1. **You can run the Fossil web interface locally |
| 28 | 21 | using the "fossil ui" command.**<p> |
| 29 | 22 | Just type the command "fossil ui" from any Fossil checkout, |
| 30 | 23 | or add the name of a Fossil repository file as an argument, |
| @@ -40,12 +33,21 @@ | ||
| 40 | 33 | (for example using "gitk" or other third-party programs), but |
| 41 | 34 | nothing with anything close to the capabilities of the Fossil |
| 42 | 35 | timeline is available via a web interface, as far as I know.<p> |
| 43 | 36 | Using the web interface, one can easily check on the status |
| 44 | 37 | of a project when away from the office and without access to a clone |
| 45 | - of the repository, just by visiting a link using | |
| 46 | - any web browser, even from a phone. | |
| 38 | + of the repository. | |
| 39 | + | |
| 40 | + 1. **The Fossil web interface view of a single checkin shows a | |
| 41 | + context graph of all other directly connected checkins.**<p> | |
| 42 | + See the page for [checkin 59985724d71229bf](/info/59985724d71229bf) | |
| 43 | + for example. The context graph shows for other checkins, | |
| 44 | + two direct descendants, one merge descendant, and one ancestor. | |
| 45 | + This context graph is useful in understanding how a particular | |
| 46 | + checkin fits into the history of the project. The context graph | |
| 47 | + can also be used to step forwards or backwards in time, by | |
| 48 | + clicking on the "check-in:" hash links for nearby checkins. | |
| 47 | 49 | |
| 48 | 50 | 1. **The graphical timeline dynamically adjusts its layout as you resize |
| 49 | 51 | your browser window.**<p> |
| 50 | 52 | The server sends down JSON that gives the basic structure of the |
| 51 | 53 | timeline graph, then Javascript renders the graph. The JS code is |
| @@ -61,12 +63,13 @@ | ||
| 61 | 63 | to be able to see what is happening on a project |
| 62 | 64 | while away from the office and without access to a laptop. |
| 63 | 65 | |
| 64 | 66 | 1. **The graphical timeline is bandwidth efficient.**<p> |
| 65 | 67 | To display a timeline of recent activity on Fossil uses less |
| 66 | - than 5% of the bandwidth as does GitHub. In a typical example, | |
| 67 | - GitHub requires about 3.5MB of transfer compared to 150KB for | |
| 68 | + than 5% of the bandwidth as GitHub. In a typical example, | |
| 69 | + GitHub requires about 3.5MB of transfer across 56 different | |
| 70 | + resources compared to 150KB for just the HTML and CSS for | |
| 68 | 71 | Fossil. And for all that 3.5MB, GitHub just gives you a list |
| 69 | 72 | of recent check-ins without any indication of the branching |
| 70 | 73 | structure, whereas Fossil gives you an easy-to-read color-coded |
| 71 | 74 | graph. |
| 72 | 75 | |
| @@ -73,30 +76,31 @@ | ||
| 73 | 76 | 1. **The Fossil web interface makes it easy to see a diff between |
| 74 | 77 | any two checkins with just a couple of clicks.**<p> |
| 75 | 78 | On the timeline display, click on one node of the graph to |
| 76 | 79 | select it (a red dot will appear in the center of the node) and |
| 77 | 80 | then click on any other graph node, and Fossil will compute and |
| 78 | - display a diff between those two check-ins. | |
| 81 | + display a diff between those two check-ins. (Usage hint: | |
| 82 | + click the selected node a second time to deselect it.) | |
| 79 | 83 | |
| 80 | 84 | 1. **The Fossil web-based diff page shows the context of the two |
| 81 | 85 | checkins being diffed.**<p> |
| 82 | 86 | At the top of the web-based diff is a graph that shows |
| 83 | 87 | specifically the two checkins being diffed and the context |
| 84 | 88 | around them. |
| 85 | 89 | [Example](/vdiff?from=052390edaf04a5f5&to=9b686daeeda7b4ca). |
| 86 | - This helps to relieve any confusion about what you are looking at. | |
| 90 | + This helps to reduce any confusion about what you are looking at. | |
| 87 | 91 | |
| 88 | 92 | 1. **In Fossil, a repository is distinct from a working check-out.**<p> |
| 89 | 93 | A Fossil repository can be colocated with the working check-out, as |
| 90 | 94 | they are required to be in Git. But most people keep the repository |
| 91 | 95 | separate. One common pattern is to put all Fossil repositories in |
| 92 | - a single directory named $HOME/Fossils or $HOME/Museum, and then open | |
| 96 | + a single directory named $HOME/Fossils or $HOME/Museum and then open | |
| 93 | 97 | working check-outs against each repository whereever they are needed. |
| 94 | 98 | |
| 95 | 99 | 1. **A single Fossil repository can support multiple working check-outs.** |
| 96 | 100 | <p> |
| 97 | - Git has worktrees, but all worktrees checkouts must be on separate | |
| 101 | + Git has worktrees, but all worktrees check-outs must be on separate | |
| 98 | 102 | branches. Fossil allows multiple working check-outs on the same branch |
| 99 | 103 | or even on the same checkin. One common pattern is to have one |
| 100 | 104 | check-out that is being edited, and another than is a pristine, unedited |
| 101 | 105 | version of the same checkin. This allows both to be compiled |
| 102 | 106 | simultanteously for performance comparison, or to step through both |
| @@ -126,23 +130,26 @@ | ||
| 126 | 130 | Windows. Fossil creates and manages that file automatically. |
| 127 | 131 | The user never has know the file even exists. If you |
| 128 | 132 | move or rename repositories or check-outs, the database will get |
| 129 | 133 | temporarily out of sync with reality, but Fossil will automatically |
| 130 | 134 | fix the database the next time you do anything with the file or |
| 131 | - check-out that was moved or renamed.<p> | |
| 132 | - You can get a list of repositories using the "fossil all ls" command, | |
| 133 | - or a list of open check-outs using "fossil all ls --ckout". | |
| 135 | + check-out that was moved or renamed.<p> | |
| 136 | + You can get a list of repositories using the | |
| 137 | + "<tt>fossil all ls</tt>" command, or a list of open | |
| 138 | + check-outs using "<tt>fossil all ls --ckout</tt>". | |
| 134 | 139 | |
| 135 | - 1. **Fossil enables you to bring up a web-based UI that shows all of | |
| 140 | + 1. **Fossil lets you to bring up a web-based UI that shows all of | |
| 136 | 141 | your repositories at once.**<p> |
| 137 | - Run the command "fossil ui /" and your default web browser will pop | |
| 138 | - of a screen that lists all of your repositories together with the | |
| 142 | + Run the command "<tt>fossil ui /</tt>" and your | |
| 143 | + default web browser will pop up a new tab that lists all of your | |
| 144 | + repositories together with the | |
| 139 | 145 | associated project name and how recently that repository was modified. |
| 140 | 146 | Click on links to bring up repository-specific web-pages. Or click |
| 141 | 147 | on column headers to sort by that column.<p> |
| 142 | 148 | If you are like me and have hundreds of repositories on your desktop |
| 143 | - system, this feature makes it easier to keep track of them all. | |
| 149 | + system, this feature makes it easier to keep track of them all, or | |
| 150 | + just to remember what you called each one. | |
| 144 | 151 | Are you on an infrequently used travel laptop and forgot where you |
| 145 | 152 | put a particular repository, this feature helps you find it. |
| 146 | 153 | |
| 147 | 154 | 1. **Fossil lets you quickly find all of your local checkouts that have |
| 148 | 155 | uncommitted changes.**<p> |
| @@ -152,16 +159,17 @@ | ||
| 152 | 159 | 1. **Fossil lets you sync all of the changes in all of your local |
| 153 | 160 | repositories to their remotes, with a single command.**<p> |
| 154 | 161 | Run "<tt>fossil all sync</tt>" and all your local |
| 155 | 162 | repositories will sync up. This is useful, for example when |
| 156 | 163 | taking a laptop off-network. Before disconnecting, you sync |
| 157 | - all of your repositories (I typically have about a hundred) | |
| 158 | - with a single command, so there is no chance that you forget | |
| 159 | - one. While off-network, you might commit changes to one or | |
| 164 | + all of your repositories (I typically have about a hundred). | |
| 165 | + The command itself keeps track of them all and so you cannot forget | |
| 166 | + one by mistake.<p> | |
| 167 | + While off-network, you might commit changes to one or | |
| 160 | 168 | more of those repositories. Once you reconnect, you simply |
| 161 | - run "fossil all sync" again to push out your edits to the | |
| 162 | - rest of the community. | |
| 169 | + run "<tt>fossil all sync</tt>" again to push out your edits | |
| 170 | + to the community. | |
| 163 | 171 | |
| 164 | 172 | 1. **Fossil allows multiple checkins to have the same tag.**<p> |
| 165 | 173 | For example, on the SQLite project, every release is tagged with |
| 166 | 174 | "release". |
| 167 | 175 | |
| @@ -177,16 +185,16 @@ | ||
| 177 | 185 | |
| 178 | 186 | 1. **Fossil can associate a wiki page with a particular checkin.**<p> |
| 179 | 187 | Rather than including a massive and verbose checkin comment on an |
| 180 | 188 | important checkin (such as the merge of a big new feature), Fossil |
| 181 | 189 | allows you to assign a wiki page to that checkin. That wiki page |
| 182 | - is show as part of the checkin information in the web interface. | |
| 190 | + is shown as part of the checkin information in the web interface. | |
| 183 | 191 | See, for example, the "About" section of |
| 184 | 192 | [SQLite checkin 2019-11-21T18:28:44.463Z](https://sqlite.org/src/info/2019-11-21T18:28:44.463Z). |
| 185 | 193 | The wiki page associated with a checkin can be created and revised |
| 186 | - after the checkin is comimtted and pushed. So it can be used, for | |
| 187 | - example, to add notes or bug reports that occur long after the | |
| 194 | + after the checkin is comimtted and pushed. This feature can be used | |
| 195 | + to add notes or bug reports that occur long after the | |
| 188 | 196 | checkin itself has been inserted into the DAG. |
| 189 | 197 | |
| 190 | 198 | 1. **Fossil can associate a wiki page with a particular branch.**<p> |
| 191 | 199 | You can create a wiki page for a branch that documents the purpose |
| 192 | 200 | of the branch. The wiki page can be displayed separately (like any |
| @@ -209,44 +217,45 @@ | ||
| 209 | 217 | GitHub just shows us all ancestors of the leaf node labeled |
| 210 | 218 | "setlk-snapshot-fix", including ancestors that were in other branches |
| 211 | 219 | that got merged in, and ancestors that predate the founding of the |
| 212 | 220 | setlk-snapshot-fix branch. |
| 213 | 221 | <p> |
| 214 | - GitHub just cannot shows you the checkins of branch setlk-snapshot-fix | |
| 222 | + GitHub is unable to show you the checkins of branch setlk-snapshot-fix | |
| 215 | 223 | only. There are other third-party tools that will show you that, I am |
| 216 | 224 | told, but they all require a local clone of the repository. Apparently |
| 217 | - there is no way to see this information in a web browser running on | |
| 218 | - your phone. | |
| 225 | + there is no way to see this information in a web browser. | |
| 219 | 226 | |
| 220 | 227 | 1. **Fossil has a built-in bug tracking system.**.<p> |
| 221 | 228 | Tickets are stored in the repository together with source code and |
| 222 | 229 | push/pull/sync the same as the code. The ticket system is configurable |
| 223 | 230 | and distributed. Repository administrators can determine what |
| 224 | 231 | fields appear in tickets and what users are allowed to create, |
| 225 | 232 | edit, or moderate tickets. |
| 226 | 233 | |
| 227 | 234 | 1. **Fossil allows multiple branches with the same name.**<p> |
| 228 | - This is used, for example, to name a lot for branches "experimental" | |
| 229 | - or "mistake". See | |
| 230 | - <https://sqlite.org/src/timeline?r=experimental> and | |
| 231 | - <https://sqlite.org/src/timeline?r=mistake>. Or see | |
| 232 | - [the empty-table-optimizations branch(es)](https://sqlite.org/src/timeline?r=empty-table-optimizations) which was initially merged to trunk and closed | |
| 235 | + As an example, the SQLite project has multiple branches | |
| 236 | + named "experimental" | |
| 237 | + <https://sqlite.org/src/timeline?r=experimental> and many | |
| 238 | + others named "mistake" | |
| 239 | + <https://sqlite.org/src/timeline?r=mistake>. | |
| 240 | + [the empty-table-optimizations branch(es)](https://sqlite.org/src/timeline?r=empty-table-optimizations) | |
| 241 | + which was initially merged to trunk and closed | |
| 233 | 242 | on 2025-07-02, but then reopened and continued with more enhancements |
| 234 | 243 | until it was merged again on 2025-07-08. |
| 235 | 244 | |
| 236 | - 1. **Fossil allows legacy SHA1 hashes and newer SHA3-256 hashes in the | |
| 237 | - same repository.**<p> | |
| 245 | + 1. **Fossil allows both legacy SHA1 hashes and newer SHA3-256 hashes | |
| 246 | + in the same repository.**<p> | |
| 238 | 247 | Both Fossil and Git started out using SHA1 hashes. But when the |
| 239 | 248 | [SHAttered attack](https://www.marc-stevens.nl/research/shattered.io/) |
| 240 | 249 | against SHA1 was published on 2017-02-23, the need to migrate to a |
| 241 | 250 | stronger hash algorithm was recognized. Fossil added the ability |
| 242 | 251 | to use SHA3-256 as an alternative on 2017-03-01 (six days after the |
| 243 | - SHAttered attack was first published), and to this day | |
| 244 | - it continues to support both. SHA3-256 is now the default for all | |
| 252 | + SHAttered attack was first published). | |
| 253 | + SHA3-256 is now the default for all | |
| 245 | 254 | new repositories and checkins, though older checkins that occurred |
| 246 | - prior to ShAttered can still use their original SHA1 hash and so no | |
| 247 | - repositories had to be rebuilt and no hyperlinks were broken.<p> | |
| 255 | + prior to ShAttered can still use their original SHA1 hash. Hence, | |
| 256 | + no repositories had to be rebuilt and no hyperlinks were broken.<p> | |
| 248 | 257 | In contrast, after nine years, a Git repository can still only |
| 249 | 258 | support only one hash algorithm at a time. |
| 250 | 259 | Newer Git repositories are able to use SHA2, though the default |
| 251 | 260 | is still SHA1. |
| 252 | 261 | |
| @@ -825,10 +834,43 @@ | ||
| 825 | 834 | committers can make changes to the checklist (such as marking items |
| 826 | 835 | as "done") and that the checklist is read-only for the general public. |
| 827 | 836 | <p> |
| 828 | 837 | Additional information about this advanced feature of Fossil |
| 829 | 838 | can be seen at <https://fossil-scm.org/home/doc/trunk/www/serverext.wiki>. |
| 839 | + | |
| 840 | + 1. **Fossil makes convenience commands available to run its | |
| 841 | + cryptographic hash algorithms (SHA1 and SHA3-256)**<p> | |
| 842 | + The "<tt>fossil sha1sum FILE ...</tt>" and | |
| 843 | + "<tt>fossil sha3sum FILE ...</tt>" commands will | |
| 844 | + compute SHA1 and SHA3-256 hashes on files. These commands are not | |
| 845 | + necessary to use Fossil, but they are still useful, and they are | |
| 846 | + not commonly installed on non-Linux platforms. Fossil ensures that | |
| 847 | + those hash functions are available whereever Fossil is available. | |
| 848 | + | |
| 849 | + 1. **Fossil exposes its 3-way-diff algorithm for external use.**<p> | |
| 850 | + The "<tt>fossil 3-way-merge ...</tt>" command works | |
| 851 | + like the classic unix "diff3" command in that it does a merge | |
| 852 | + of two variants of a file given a common ancestor. This is the | |
| 853 | + exact same algorithm that Fossil uses to compute merges internally, | |
| 854 | + simply exposed for external use. | |
| 855 | + | |
| 856 | + 1. **On a merge conflict, Fossil shows the conflicting inputs just | |
| 857 | + like other merge algorithms, but it also shows a suggested conflict | |
| 858 | + resolution.**<p> | |
| 859 | + The suggested conflict resolution is not always right, but it is | |
| 860 | + sometimes, and its presence often makes resolving merge conflicts | |
| 861 | + simpler. | |
| 862 | + | |
| 863 | + 1. **Fossil supports single sign-in when serving multiple repositories | |
| 864 | + from the same host computer.**<p> | |
| 865 | + If you have a server that is hosting Fossil web interfaces for | |
| 866 | + multiple repositories, those repositories can be interconnected | |
| 867 | + into a common "login group" such that when a user logs into one | |
| 868 | + repositories web interface, they are also automatically logged into | |
| 869 | + all other for which the have a login. Furthermore, if the user | |
| 870 | + changes his password on one repository, it is automatically changed | |
| 871 | + on all the others within that login group. | |
| 830 | 872 | |
| 831 | 873 | 1. **Experts can browse low-level details of a Fossil repository |
| 832 | 874 | using SQL.**<p> |
| 833 | 875 | A Fossil repository is just an SQLite database file. Low-level content |
| 834 | 876 | of that database file can be viewed and even changed using ordinary |
| @@ -950,5 +992,62 @@ | ||
| 950 | 992 | Adding the "<tt>-b</tt>" or "<tt>-by</tt>" option to any Fossil |
| 951 | 993 | diff command causes that diff to be rendered as a new page in |
| 952 | 994 | the users default web browser. Git does not have any such |
| 953 | 995 | capability, even with the aid of external programs, as far as |
| 954 | 996 | I am aware. |
| 997 | + | |
| 998 | + 1. **The Fossil web interface provides a captcha-gated method to download | |
| 999 | + tarballs and ZIP archives for any checkin.**<p> | |
| 1000 | + See, for example, <https://sqlite.org/src/rchvdwnld/20260704>. | |
| 1001 | + That link provides access to the last checkin for the day 2026-07-04. | |
| 1002 | + The last element of the patch can be any hash prefix, timestamp prefix, | |
| 1003 | + or tag that references a checkin.<p> | |
| 1004 | + Tarballs and ZIP archive are expensive to compute, not because Fossil | |
| 1005 | + has any difficulty assembly the content, | |
| 1006 | + but rather because the result must be run through zlib compression. | |
| 1007 | + When computing a new archive, almost all of the CPU time is spent | |
| 1008 | + inside of the zlib compression library. | |
| 1009 | + For an SQLite-size tarball, the zlib compression alone can take as | |
| 1010 | + much as 10 seconds of CPU time. If the tarball/ZIP-archive download | |
| 1011 | + link is not protected by a captcha, multiple spiders will attempt to | |
| 1012 | + download every possible tarball and ZIP archive, multiple times per | |
| 1013 | + day, bringing your server to its knees. | |
| 1014 | + | |
| 1015 | + 1. **Repository adminstrators can create a cache of recently downloaded | |
| 1016 | + tarballs and ZIP archives**<p> | |
| 1017 | + That way, if there are common downloads (like the most recent release) | |
| 1018 | + the archive does not get recomputed from scratch with each download. | |
| 1019 | + A download of an archive of a checkin is reasonably fast as long as | |
| 1020 | + the content can be served from cache. | |
| 1021 | + The size of the cache is configurable by the repository administrator. | |
| 1022 | + | |
| 1023 | + 1. **The Fossil web interface has a "Repository Status" page that shows | |
| 1024 | + interesting and useful facts about the repository being served.**<p> | |
| 1025 | + See the [stat page for Fossil](/stat) for example. | |
| 1026 | + | |
| 1027 | + 1. **The Fossil web interface easily shows all of the contributors to | |
| 1028 | + a project, and the number of changes they have committed.**<p> | |
| 1029 | + See <https://fossil-scm.org/home/reports> for that report about | |
| 1030 | + Fossil itself. | |
| 1031 | + Many other reports can be generated from the same page by selecting | |
| 1032 | + different options from the pull-down menus at the top. | |
| 1033 | + <p>The page is capcha-gated since it is a magnet for for spiders. | |
| 1034 | + | |
| 1035 | + 1. **The Fossil source code is easy to enhance with new web pages and | |
| 1036 | + commands.**<p> | |
| 1037 | + The design of the Fossil implementation makes it eash to extend with | |
| 1038 | + new capabilities as needs arise. | |
| 1039 | + <ul type="disk"> | |
| 1040 | + <li> The code is C-89 | |
| 1041 | + <li> Each command and each web page runs as a separate process which | |
| 1042 | + exits when the action completes, so minor memory leaks are not | |
| 1043 | + a concern. | |
| 1044 | + <li> Preprocessors that run before the code reaches the C compiler help | |
| 1045 | + to ensure that there are no SQL injections nor XSS vulnerabilities. | |
| 1046 | + <li> New commands and new web pages can be added simply adding a new | |
| 1047 | + procedure to do the necessary computation. The name, properties, | |
| 1048 | + and documentation for the command or webpage are extracted from | |
| 1049 | + specially formatted comments just prior to the procedure. | |
| 1050 | + </ul><p> | |
| 1051 | + The ease with which Fossil can be enhanced is part of the reason why | |
| 1052 | + it has picked up so many useful features and has become so useful | |
| 1053 | + and powerful over its 19-year lifetime. | |
| 955 | 1054 |
| --- www/hundredandone.md | |
| +++ www/hundredandone.md | |
| @@ -1,14 +1,7 @@ | |
| 1 | # 101 Reasons Why Fossil Is Better Than Git |
| 2 | |
| 3 | *This is a work in progress. Only 91 reasons have been typed in so far, |
| 4 | but I have a separate text file of notes that lists 104 candidate reasons. |
| 5 | It's just taking me a while to compose and edit the rationale for each |
| 6 | one, and to arrange the reasons in a sensible order. I will merge this |
| 7 | document from its current branch onto trunk when it gets closer to being |
| 8 | ready to publish.* |
| 9 | |
| 10 | 1. **Fossil comes as a single self-contained executable file**.<p> |
| 11 | Install Fossil by copying "fossil" (or "fossil.exe") to someplace |
| 12 | on your $PATH (or %PATH%). Upgrade (or downgrade) by overwriting |
| 13 | that one file. Uninstall by deleting that one file.<p> |
| 14 | A Git installation requires hundreds of files. You want to use |
| @@ -16,15 +9,15 @@ | |
| 16 | tinker with individual files of a Git installation, you run a high |
| 17 | risk of messing things up. |
| 18 | |
| 19 | 1. **Fossil comes with a built-in full-featured web interface**.<p> |
| 20 | The Fossil web interface is on par with GitHub, GitLab, |
| 21 | Gitea, and similar. Some people think of Fossil as |
| 22 | "Github-in-a-box". Git has "gitweb", but that CGI program |
| 23 | is so limited and difficult to set up and use that few people |
| 24 | even know it exists, so I do not count it as a built-in web |
| 25 | interface for the purposes of this point. |
| 26 | |
| 27 | 1. **You can run the Fossil web interface locally |
| 28 | using the "fossil ui" command.**<p> |
| 29 | Just type the command "fossil ui" from any Fossil checkout, |
| 30 | or add the name of a Fossil repository file as an argument, |
| @@ -40,12 +33,21 @@ | |
| 40 | (for example using "gitk" or other third-party programs), but |
| 41 | nothing with anything close to the capabilities of the Fossil |
| 42 | timeline is available via a web interface, as far as I know.<p> |
| 43 | Using the web interface, one can easily check on the status |
| 44 | of a project when away from the office and without access to a clone |
| 45 | of the repository, just by visiting a link using |
| 46 | any web browser, even from a phone. |
| 47 | |
| 48 | 1. **The graphical timeline dynamically adjusts its layout as you resize |
| 49 | your browser window.**<p> |
| 50 | The server sends down JSON that gives the basic structure of the |
| 51 | timeline graph, then Javascript renders the graph. The JS code is |
| @@ -61,12 +63,13 @@ | |
| 61 | to be able to see what is happening on a project |
| 62 | while away from the office and without access to a laptop. |
| 63 | |
| 64 | 1. **The graphical timeline is bandwidth efficient.**<p> |
| 65 | To display a timeline of recent activity on Fossil uses less |
| 66 | than 5% of the bandwidth as does GitHub. In a typical example, |
| 67 | GitHub requires about 3.5MB of transfer compared to 150KB for |
| 68 | Fossil. And for all that 3.5MB, GitHub just gives you a list |
| 69 | of recent check-ins without any indication of the branching |
| 70 | structure, whereas Fossil gives you an easy-to-read color-coded |
| 71 | graph. |
| 72 | |
| @@ -73,30 +76,31 @@ | |
| 73 | 1. **The Fossil web interface makes it easy to see a diff between |
| 74 | any two checkins with just a couple of clicks.**<p> |
| 75 | On the timeline display, click on one node of the graph to |
| 76 | select it (a red dot will appear in the center of the node) and |
| 77 | then click on any other graph node, and Fossil will compute and |
| 78 | display a diff between those two check-ins. |
| 79 | |
| 80 | 1. **The Fossil web-based diff page shows the context of the two |
| 81 | checkins being diffed.**<p> |
| 82 | At the top of the web-based diff is a graph that shows |
| 83 | specifically the two checkins being diffed and the context |
| 84 | around them. |
| 85 | [Example](/vdiff?from=052390edaf04a5f5&to=9b686daeeda7b4ca). |
| 86 | This helps to relieve any confusion about what you are looking at. |
| 87 | |
| 88 | 1. **In Fossil, a repository is distinct from a working check-out.**<p> |
| 89 | A Fossil repository can be colocated with the working check-out, as |
| 90 | they are required to be in Git. But most people keep the repository |
| 91 | separate. One common pattern is to put all Fossil repositories in |
| 92 | a single directory named $HOME/Fossils or $HOME/Museum, and then open |
| 93 | working check-outs against each repository whereever they are needed. |
| 94 | |
| 95 | 1. **A single Fossil repository can support multiple working check-outs.** |
| 96 | <p> |
| 97 | Git has worktrees, but all worktrees checkouts must be on separate |
| 98 | branches. Fossil allows multiple working check-outs on the same branch |
| 99 | or even on the same checkin. One common pattern is to have one |
| 100 | check-out that is being edited, and another than is a pristine, unedited |
| 101 | version of the same checkin. This allows both to be compiled |
| 102 | simultanteously for performance comparison, or to step through both |
| @@ -126,23 +130,26 @@ | |
| 126 | Windows. Fossil creates and manages that file automatically. |
| 127 | The user never has know the file even exists. If you |
| 128 | move or rename repositories or check-outs, the database will get |
| 129 | temporarily out of sync with reality, but Fossil will automatically |
| 130 | fix the database the next time you do anything with the file or |
| 131 | check-out that was moved or renamed.<p> |
| 132 | You can get a list of repositories using the "fossil all ls" command, |
| 133 | or a list of open check-outs using "fossil all ls --ckout". |
| 134 | |
| 135 | 1. **Fossil enables you to bring up a web-based UI that shows all of |
| 136 | your repositories at once.**<p> |
| 137 | Run the command "fossil ui /" and your default web browser will pop |
| 138 | of a screen that lists all of your repositories together with the |
| 139 | associated project name and how recently that repository was modified. |
| 140 | Click on links to bring up repository-specific web-pages. Or click |
| 141 | on column headers to sort by that column.<p> |
| 142 | If you are like me and have hundreds of repositories on your desktop |
| 143 | system, this feature makes it easier to keep track of them all. |
| 144 | Are you on an infrequently used travel laptop and forgot where you |
| 145 | put a particular repository, this feature helps you find it. |
| 146 | |
| 147 | 1. **Fossil lets you quickly find all of your local checkouts that have |
| 148 | uncommitted changes.**<p> |
| @@ -152,16 +159,17 @@ | |
| 152 | 1. **Fossil lets you sync all of the changes in all of your local |
| 153 | repositories to their remotes, with a single command.**<p> |
| 154 | Run "<tt>fossil all sync</tt>" and all your local |
| 155 | repositories will sync up. This is useful, for example when |
| 156 | taking a laptop off-network. Before disconnecting, you sync |
| 157 | all of your repositories (I typically have about a hundred) |
| 158 | with a single command, so there is no chance that you forget |
| 159 | one. While off-network, you might commit changes to one or |
| 160 | more of those repositories. Once you reconnect, you simply |
| 161 | run "fossil all sync" again to push out your edits to the |
| 162 | rest of the community. |
| 163 | |
| 164 | 1. **Fossil allows multiple checkins to have the same tag.**<p> |
| 165 | For example, on the SQLite project, every release is tagged with |
| 166 | "release". |
| 167 | |
| @@ -177,16 +185,16 @@ | |
| 177 | |
| 178 | 1. **Fossil can associate a wiki page with a particular checkin.**<p> |
| 179 | Rather than including a massive and verbose checkin comment on an |
| 180 | important checkin (such as the merge of a big new feature), Fossil |
| 181 | allows you to assign a wiki page to that checkin. That wiki page |
| 182 | is show as part of the checkin information in the web interface. |
| 183 | See, for example, the "About" section of |
| 184 | [SQLite checkin 2019-11-21T18:28:44.463Z](https://sqlite.org/src/info/2019-11-21T18:28:44.463Z). |
| 185 | The wiki page associated with a checkin can be created and revised |
| 186 | after the checkin is comimtted and pushed. So it can be used, for |
| 187 | example, to add notes or bug reports that occur long after the |
| 188 | checkin itself has been inserted into the DAG. |
| 189 | |
| 190 | 1. **Fossil can associate a wiki page with a particular branch.**<p> |
| 191 | You can create a wiki page for a branch that documents the purpose |
| 192 | of the branch. The wiki page can be displayed separately (like any |
| @@ -209,44 +217,45 @@ | |
| 209 | GitHub just shows us all ancestors of the leaf node labeled |
| 210 | "setlk-snapshot-fix", including ancestors that were in other branches |
| 211 | that got merged in, and ancestors that predate the founding of the |
| 212 | setlk-snapshot-fix branch. |
| 213 | <p> |
| 214 | GitHub just cannot shows you the checkins of branch setlk-snapshot-fix |
| 215 | only. There are other third-party tools that will show you that, I am |
| 216 | told, but they all require a local clone of the repository. Apparently |
| 217 | there is no way to see this information in a web browser running on |
| 218 | your phone. |
| 219 | |
| 220 | 1. **Fossil has a built-in bug tracking system.**.<p> |
| 221 | Tickets are stored in the repository together with source code and |
| 222 | push/pull/sync the same as the code. The ticket system is configurable |
| 223 | and distributed. Repository administrators can determine what |
| 224 | fields appear in tickets and what users are allowed to create, |
| 225 | edit, or moderate tickets. |
| 226 | |
| 227 | 1. **Fossil allows multiple branches with the same name.**<p> |
| 228 | This is used, for example, to name a lot for branches "experimental" |
| 229 | or "mistake". See |
| 230 | <https://sqlite.org/src/timeline?r=experimental> and |
| 231 | <https://sqlite.org/src/timeline?r=mistake>. Or see |
| 232 | [the empty-table-optimizations branch(es)](https://sqlite.org/src/timeline?r=empty-table-optimizations) which was initially merged to trunk and closed |
| 233 | on 2025-07-02, but then reopened and continued with more enhancements |
| 234 | until it was merged again on 2025-07-08. |
| 235 | |
| 236 | 1. **Fossil allows legacy SHA1 hashes and newer SHA3-256 hashes in the |
| 237 | same repository.**<p> |
| 238 | Both Fossil and Git started out using SHA1 hashes. But when the |
| 239 | [SHAttered attack](https://www.marc-stevens.nl/research/shattered.io/) |
| 240 | against SHA1 was published on 2017-02-23, the need to migrate to a |
| 241 | stronger hash algorithm was recognized. Fossil added the ability |
| 242 | to use SHA3-256 as an alternative on 2017-03-01 (six days after the |
| 243 | SHAttered attack was first published), and to this day |
| 244 | it continues to support both. SHA3-256 is now the default for all |
| 245 | new repositories and checkins, though older checkins that occurred |
| 246 | prior to ShAttered can still use their original SHA1 hash and so no |
| 247 | repositories had to be rebuilt and no hyperlinks were broken.<p> |
| 248 | In contrast, after nine years, a Git repository can still only |
| 249 | support only one hash algorithm at a time. |
| 250 | Newer Git repositories are able to use SHA2, though the default |
| 251 | is still SHA1. |
| 252 | |
| @@ -825,10 +834,43 @@ | |
| 825 | committers can make changes to the checklist (such as marking items |
| 826 | as "done") and that the checklist is read-only for the general public. |
| 827 | <p> |
| 828 | Additional information about this advanced feature of Fossil |
| 829 | can be seen at <https://fossil-scm.org/home/doc/trunk/www/serverext.wiki>. |
| 830 | |
| 831 | 1. **Experts can browse low-level details of a Fossil repository |
| 832 | using SQL.**<p> |
| 833 | A Fossil repository is just an SQLite database file. Low-level content |
| 834 | of that database file can be viewed and even changed using ordinary |
| @@ -950,5 +992,62 @@ | |
| 950 | Adding the "<tt>-b</tt>" or "<tt>-by</tt>" option to any Fossil |
| 951 | diff command causes that diff to be rendered as a new page in |
| 952 | the users default web browser. Git does not have any such |
| 953 | capability, even with the aid of external programs, as far as |
| 954 | I am aware. |
| 955 |
| --- www/hundredandone.md | |
| +++ www/hundredandone.md | |
| @@ -1,14 +1,7 @@ | |
| 1 | # 101 Reasons Why Fossil Is Better Than Git |
| 2 | |
| 3 | 1. **Fossil comes as a single self-contained executable file**.<p> |
| 4 | Install Fossil by copying "fossil" (or "fossil.exe") to someplace |
| 5 | on your $PATH (or %PATH%). Upgrade (or downgrade) by overwriting |
| 6 | that one file. Uninstall by deleting that one file.<p> |
| 7 | A Git installation requires hundreds of files. You want to use |
| @@ -16,15 +9,15 @@ | |
| 9 | tinker with individual files of a Git installation, you run a high |
| 10 | risk of messing things up. |
| 11 | |
| 12 | 1. **Fossil comes with a built-in full-featured web interface**.<p> |
| 13 | The Fossil web interface is on par with GitHub, GitLab, |
| 14 | Gitea, Forgejo, and similar. Some people think of Fossil as |
| 15 | "GitHub-in-a-box". Git has "gitweb", but that CGI program |
| 16 | is so limited and difficult to set up and use that few people |
| 17 | even know it exists, so I do not count it |
| 18 | for the purposes of this point. |
| 19 | |
| 20 | 1. **You can run the Fossil web interface locally |
| 21 | using the "fossil ui" command.**<p> |
| 22 | Just type the command "fossil ui" from any Fossil checkout, |
| 23 | or add the name of a Fossil repository file as an argument, |
| @@ -40,12 +33,21 @@ | |
| 33 | (for example using "gitk" or other third-party programs), but |
| 34 | nothing with anything close to the capabilities of the Fossil |
| 35 | timeline is available via a web interface, as far as I know.<p> |
| 36 | Using the web interface, one can easily check on the status |
| 37 | of a project when away from the office and without access to a clone |
| 38 | of the repository. |
| 39 | |
| 40 | 1. **The Fossil web interface view of a single checkin shows a |
| 41 | context graph of all other directly connected checkins.**<p> |
| 42 | See the page for [checkin 59985724d71229bf](/info/59985724d71229bf) |
| 43 | for example. The context graph shows for other checkins, |
| 44 | two direct descendants, one merge descendant, and one ancestor. |
| 45 | This context graph is useful in understanding how a particular |
| 46 | checkin fits into the history of the project. The context graph |
| 47 | can also be used to step forwards or backwards in time, by |
| 48 | clicking on the "check-in:" hash links for nearby checkins. |
| 49 | |
| 50 | 1. **The graphical timeline dynamically adjusts its layout as you resize |
| 51 | your browser window.**<p> |
| 52 | The server sends down JSON that gives the basic structure of the |
| 53 | timeline graph, then Javascript renders the graph. The JS code is |
| @@ -61,12 +63,13 @@ | |
| 63 | to be able to see what is happening on a project |
| 64 | while away from the office and without access to a laptop. |
| 65 | |
| 66 | 1. **The graphical timeline is bandwidth efficient.**<p> |
| 67 | To display a timeline of recent activity on Fossil uses less |
| 68 | than 5% of the bandwidth as GitHub. In a typical example, |
| 69 | GitHub requires about 3.5MB of transfer across 56 different |
| 70 | resources compared to 150KB for just the HTML and CSS for |
| 71 | Fossil. And for all that 3.5MB, GitHub just gives you a list |
| 72 | of recent check-ins without any indication of the branching |
| 73 | structure, whereas Fossil gives you an easy-to-read color-coded |
| 74 | graph. |
| 75 | |
| @@ -73,30 +76,31 @@ | |
| 76 | 1. **The Fossil web interface makes it easy to see a diff between |
| 77 | any two checkins with just a couple of clicks.**<p> |
| 78 | On the timeline display, click on one node of the graph to |
| 79 | select it (a red dot will appear in the center of the node) and |
| 80 | then click on any other graph node, and Fossil will compute and |
| 81 | display a diff between those two check-ins. (Usage hint: |
| 82 | click the selected node a second time to deselect it.) |
| 83 | |
| 84 | 1. **The Fossil web-based diff page shows the context of the two |
| 85 | checkins being diffed.**<p> |
| 86 | At the top of the web-based diff is a graph that shows |
| 87 | specifically the two checkins being diffed and the context |
| 88 | around them. |
| 89 | [Example](/vdiff?from=052390edaf04a5f5&to=9b686daeeda7b4ca). |
| 90 | This helps to reduce any confusion about what you are looking at. |
| 91 | |
| 92 | 1. **In Fossil, a repository is distinct from a working check-out.**<p> |
| 93 | A Fossil repository can be colocated with the working check-out, as |
| 94 | they are required to be in Git. But most people keep the repository |
| 95 | separate. One common pattern is to put all Fossil repositories in |
| 96 | a single directory named $HOME/Fossils or $HOME/Museum and then open |
| 97 | working check-outs against each repository whereever they are needed. |
| 98 | |
| 99 | 1. **A single Fossil repository can support multiple working check-outs.** |
| 100 | <p> |
| 101 | Git has worktrees, but all worktrees check-outs must be on separate |
| 102 | branches. Fossil allows multiple working check-outs on the same branch |
| 103 | or even on the same checkin. One common pattern is to have one |
| 104 | check-out that is being edited, and another than is a pristine, unedited |
| 105 | version of the same checkin. This allows both to be compiled |
| 106 | simultanteously for performance comparison, or to step through both |
| @@ -126,23 +130,26 @@ | |
| 130 | Windows. Fossil creates and manages that file automatically. |
| 131 | The user never has know the file even exists. If you |
| 132 | move or rename repositories or check-outs, the database will get |
| 133 | temporarily out of sync with reality, but Fossil will automatically |
| 134 | fix the database the next time you do anything with the file or |
| 135 | check-out that was moved or renamed.<p> |
| 136 | You can get a list of repositories using the |
| 137 | "<tt>fossil all ls</tt>" command, or a list of open |
| 138 | check-outs using "<tt>fossil all ls --ckout</tt>". |
| 139 | |
| 140 | 1. **Fossil lets you to bring up a web-based UI that shows all of |
| 141 | your repositories at once.**<p> |
| 142 | Run the command "<tt>fossil ui /</tt>" and your |
| 143 | default web browser will pop up a new tab that lists all of your |
| 144 | repositories together with the |
| 145 | associated project name and how recently that repository was modified. |
| 146 | Click on links to bring up repository-specific web-pages. Or click |
| 147 | on column headers to sort by that column.<p> |
| 148 | If you are like me and have hundreds of repositories on your desktop |
| 149 | system, this feature makes it easier to keep track of them all, or |
| 150 | just to remember what you called each one. |
| 151 | Are you on an infrequently used travel laptop and forgot where you |
| 152 | put a particular repository, this feature helps you find it. |
| 153 | |
| 154 | 1. **Fossil lets you quickly find all of your local checkouts that have |
| 155 | uncommitted changes.**<p> |
| @@ -152,16 +159,17 @@ | |
| 159 | 1. **Fossil lets you sync all of the changes in all of your local |
| 160 | repositories to their remotes, with a single command.**<p> |
| 161 | Run "<tt>fossil all sync</tt>" and all your local |
| 162 | repositories will sync up. This is useful, for example when |
| 163 | taking a laptop off-network. Before disconnecting, you sync |
| 164 | all of your repositories (I typically have about a hundred). |
| 165 | The command itself keeps track of them all and so you cannot forget |
| 166 | one by mistake.<p> |
| 167 | While off-network, you might commit changes to one or |
| 168 | more of those repositories. Once you reconnect, you simply |
| 169 | run "<tt>fossil all sync</tt>" again to push out your edits |
| 170 | to the community. |
| 171 | |
| 172 | 1. **Fossil allows multiple checkins to have the same tag.**<p> |
| 173 | For example, on the SQLite project, every release is tagged with |
| 174 | "release". |
| 175 | |
| @@ -177,16 +185,16 @@ | |
| 185 | |
| 186 | 1. **Fossil can associate a wiki page with a particular checkin.**<p> |
| 187 | Rather than including a massive and verbose checkin comment on an |
| 188 | important checkin (such as the merge of a big new feature), Fossil |
| 189 | allows you to assign a wiki page to that checkin. That wiki page |
| 190 | is shown as part of the checkin information in the web interface. |
| 191 | See, for example, the "About" section of |
| 192 | [SQLite checkin 2019-11-21T18:28:44.463Z](https://sqlite.org/src/info/2019-11-21T18:28:44.463Z). |
| 193 | The wiki page associated with a checkin can be created and revised |
| 194 | after the checkin is comimtted and pushed. This feature can be used |
| 195 | to add notes or bug reports that occur long after the |
| 196 | checkin itself has been inserted into the DAG. |
| 197 | |
| 198 | 1. **Fossil can associate a wiki page with a particular branch.**<p> |
| 199 | You can create a wiki page for a branch that documents the purpose |
| 200 | of the branch. The wiki page can be displayed separately (like any |
| @@ -209,44 +217,45 @@ | |
| 217 | GitHub just shows us all ancestors of the leaf node labeled |
| 218 | "setlk-snapshot-fix", including ancestors that were in other branches |
| 219 | that got merged in, and ancestors that predate the founding of the |
| 220 | setlk-snapshot-fix branch. |
| 221 | <p> |
| 222 | GitHub is unable to show you the checkins of branch setlk-snapshot-fix |
| 223 | only. There are other third-party tools that will show you that, I am |
| 224 | told, but they all require a local clone of the repository. Apparently |
| 225 | there is no way to see this information in a web browser. |
| 226 | |
| 227 | 1. **Fossil has a built-in bug tracking system.**.<p> |
| 228 | Tickets are stored in the repository together with source code and |
| 229 | push/pull/sync the same as the code. The ticket system is configurable |
| 230 | and distributed. Repository administrators can determine what |
| 231 | fields appear in tickets and what users are allowed to create, |
| 232 | edit, or moderate tickets. |
| 233 | |
| 234 | 1. **Fossil allows multiple branches with the same name.**<p> |
| 235 | As an example, the SQLite project has multiple branches |
| 236 | named "experimental" |
| 237 | <https://sqlite.org/src/timeline?r=experimental> and many |
| 238 | others named "mistake" |
| 239 | <https://sqlite.org/src/timeline?r=mistake>. |
| 240 | [the empty-table-optimizations branch(es)](https://sqlite.org/src/timeline?r=empty-table-optimizations) |
| 241 | which was initially merged to trunk and closed |
| 242 | on 2025-07-02, but then reopened and continued with more enhancements |
| 243 | until it was merged again on 2025-07-08. |
| 244 | |
| 245 | 1. **Fossil allows both legacy SHA1 hashes and newer SHA3-256 hashes |
| 246 | in the same repository.**<p> |
| 247 | Both Fossil and Git started out using SHA1 hashes. But when the |
| 248 | [SHAttered attack](https://www.marc-stevens.nl/research/shattered.io/) |
| 249 | against SHA1 was published on 2017-02-23, the need to migrate to a |
| 250 | stronger hash algorithm was recognized. Fossil added the ability |
| 251 | to use SHA3-256 as an alternative on 2017-03-01 (six days after the |
| 252 | SHAttered attack was first published). |
| 253 | SHA3-256 is now the default for all |
| 254 | new repositories and checkins, though older checkins that occurred |
| 255 | prior to ShAttered can still use their original SHA1 hash. Hence, |
| 256 | no repositories had to be rebuilt and no hyperlinks were broken.<p> |
| 257 | In contrast, after nine years, a Git repository can still only |
| 258 | support only one hash algorithm at a time. |
| 259 | Newer Git repositories are able to use SHA2, though the default |
| 260 | is still SHA1. |
| 261 | |
| @@ -825,10 +834,43 @@ | |
| 834 | committers can make changes to the checklist (such as marking items |
| 835 | as "done") and that the checklist is read-only for the general public. |
| 836 | <p> |
| 837 | Additional information about this advanced feature of Fossil |
| 838 | can be seen at <https://fossil-scm.org/home/doc/trunk/www/serverext.wiki>. |
| 839 | |
| 840 | 1. **Fossil makes convenience commands available to run its |
| 841 | cryptographic hash algorithms (SHA1 and SHA3-256)**<p> |
| 842 | The "<tt>fossil sha1sum FILE ...</tt>" and |
| 843 | "<tt>fossil sha3sum FILE ...</tt>" commands will |
| 844 | compute SHA1 and SHA3-256 hashes on files. These commands are not |
| 845 | necessary to use Fossil, but they are still useful, and they are |
| 846 | not commonly installed on non-Linux platforms. Fossil ensures that |
| 847 | those hash functions are available whereever Fossil is available. |
| 848 | |
| 849 | 1. **Fossil exposes its 3-way-diff algorithm for external use.**<p> |
| 850 | The "<tt>fossil 3-way-merge ...</tt>" command works |
| 851 | like the classic unix "diff3" command in that it does a merge |
| 852 | of two variants of a file given a common ancestor. This is the |
| 853 | exact same algorithm that Fossil uses to compute merges internally, |
| 854 | simply exposed for external use. |
| 855 | |
| 856 | 1. **On a merge conflict, Fossil shows the conflicting inputs just |
| 857 | like other merge algorithms, but it also shows a suggested conflict |
| 858 | resolution.**<p> |
| 859 | The suggested conflict resolution is not always right, but it is |
| 860 | sometimes, and its presence often makes resolving merge conflicts |
| 861 | simpler. |
| 862 | |
| 863 | 1. **Fossil supports single sign-in when serving multiple repositories |
| 864 | from the same host computer.**<p> |
| 865 | If you have a server that is hosting Fossil web interfaces for |
| 866 | multiple repositories, those repositories can be interconnected |
| 867 | into a common "login group" such that when a user logs into one |
| 868 | repositories web interface, they are also automatically logged into |
| 869 | all other for which the have a login. Furthermore, if the user |
| 870 | changes his password on one repository, it is automatically changed |
| 871 | on all the others within that login group. |
| 872 | |
| 873 | 1. **Experts can browse low-level details of a Fossil repository |
| 874 | using SQL.**<p> |
| 875 | A Fossil repository is just an SQLite database file. Low-level content |
| 876 | of that database file can be viewed and even changed using ordinary |
| @@ -950,5 +992,62 @@ | |
| 992 | Adding the "<tt>-b</tt>" or "<tt>-by</tt>" option to any Fossil |
| 993 | diff command causes that diff to be rendered as a new page in |
| 994 | the users default web browser. Git does not have any such |
| 995 | capability, even with the aid of external programs, as far as |
| 996 | I am aware. |
| 997 | |
| 998 | 1. **The Fossil web interface provides a captcha-gated method to download |
| 999 | tarballs and ZIP archives for any checkin.**<p> |
| 1000 | See, for example, <https://sqlite.org/src/rchvdwnld/20260704>. |
| 1001 | That link provides access to the last checkin for the day 2026-07-04. |
| 1002 | The last element of the patch can be any hash prefix, timestamp prefix, |
| 1003 | or tag that references a checkin.<p> |
| 1004 | Tarballs and ZIP archive are expensive to compute, not because Fossil |
| 1005 | has any difficulty assembly the content, |
| 1006 | but rather because the result must be run through zlib compression. |
| 1007 | When computing a new archive, almost all of the CPU time is spent |
| 1008 | inside of the zlib compression library. |
| 1009 | For an SQLite-size tarball, the zlib compression alone can take as |
| 1010 | much as 10 seconds of CPU time. If the tarball/ZIP-archive download |
| 1011 | link is not protected by a captcha, multiple spiders will attempt to |
| 1012 | download every possible tarball and ZIP archive, multiple times per |
| 1013 | day, bringing your server to its knees. |
| 1014 | |
| 1015 | 1. **Repository adminstrators can create a cache of recently downloaded |
| 1016 | tarballs and ZIP archives**<p> |
| 1017 | That way, if there are common downloads (like the most recent release) |
| 1018 | the archive does not get recomputed from scratch with each download. |
| 1019 | A download of an archive of a checkin is reasonably fast as long as |
| 1020 | the content can be served from cache. |
| 1021 | The size of the cache is configurable by the repository administrator. |
| 1022 | |
| 1023 | 1. **The Fossil web interface has a "Repository Status" page that shows |
| 1024 | interesting and useful facts about the repository being served.**<p> |
| 1025 | See the [stat page for Fossil](/stat) for example. |
| 1026 | |
| 1027 | 1. **The Fossil web interface easily shows all of the contributors to |
| 1028 | a project, and the number of changes they have committed.**<p> |
| 1029 | See <https://fossil-scm.org/home/reports> for that report about |
| 1030 | Fossil itself. |
| 1031 | Many other reports can be generated from the same page by selecting |
| 1032 | different options from the pull-down menus at the top. |
| 1033 | <p>The page is capcha-gated since it is a magnet for for spiders. |
| 1034 | |
| 1035 | 1. **The Fossil source code is easy to enhance with new web pages and |
| 1036 | commands.**<p> |
| 1037 | The design of the Fossil implementation makes it eash to extend with |
| 1038 | new capabilities as needs arise. |
| 1039 | <ul type="disk"> |
| 1040 | <li> The code is C-89 |
| 1041 | <li> Each command and each web page runs as a separate process which |
| 1042 | exits when the action completes, so minor memory leaks are not |
| 1043 | a concern. |
| 1044 | <li> Preprocessors that run before the code reaches the C compiler help |
| 1045 | to ensure that there are no SQL injections nor XSS vulnerabilities. |
| 1046 | <li> New commands and new web pages can be added simply adding a new |
| 1047 | procedure to do the necessary computation. The name, properties, |
| 1048 | and documentation for the command or webpage are extracted from |
| 1049 | specially formatted comments just prior to the procedure. |
| 1050 | </ul><p> |
| 1051 | The ease with which Fossil can be enhanced is part of the reason why |
| 1052 | it has picked up so many useful features and has become so useful |
| 1053 | and powerful over its 19-year lifetime. |
| 1054 |