Fossil SCM
Rewrite the "fossil versus git" document.
Commit
ca891ab6c16e00aac70373461de8dc3143847acc
Parent
eba19952226b152…
1 file changed
+272
-234
+272
-234
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -3,12 +3,13 @@ | ||
| 3 | 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | 4 | |
| 5 | 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | 6 | it is [./inout.wiki | easy to change]. |
| 7 | 7 | |
| 8 | -But it also helps to be informed about the differences between | |
| 9 | -[http://git-scm.com | Git] and Fossil. See the table below for | |
| 8 | +Fossil and [http://git-scm.com | Git] are very similar in many respects, | |
| 9 | +but there are also important differences. | |
| 10 | +See the table below for | |
| 10 | 11 | a high-level summary and the text that follows for more details. |
| 11 | 12 | |
| 12 | 13 | Keep in mind that you are reading this on a Fossil website, |
| 13 | 14 | so the information here |
| 14 | 15 | might be biased in favor of Fossil. Ask around with people who have |
| @@ -18,20 +19,20 @@ | ||
| 18 | 19 | |
| 19 | 20 | <blockquote><center><table border=1 cellpadding=5> |
| 20 | 21 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 21 | 22 | <tr><td>File versioning only</td> |
| 22 | 23 | <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> | |
| 24 | +<tr><td>Ad-hoc, pile-of-files key/value database</td> | |
| 25 | + <td>Relational SQL database</td></tr> | |
| 26 | +<tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> | |
| 27 | +<tr><td>Designed for Linux development</td> | |
| 28 | + <td>Designed for SQLite development</td></tr> | |
| 29 | +<tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> | |
| 30 | 30 | <tr><td>One check-out per repository</td> |
| 31 | 31 | <td>Many check-outs per repository</td></tr> |
| 32 | -<tr><td>Uses "<tt>rebase</tt>"</td><td>Immutable</td></tr> | |
| 32 | +<tr><td>Remembers what you should have done</td> | |
| 33 | + <td>Remembers what you actually did</td></tr> | |
| 33 | 34 | <tr><td>GPL</td><td>BSD</td></tr> |
| 34 | 35 | </table></center></blockquote> |
| 35 | 36 | |
| 36 | 37 | <h2>3.0 Discussion</h2> |
| 37 | 38 | |
| @@ -40,233 +41,270 @@ | ||
| 40 | 41 | Git provides file versioning services only, whereas Fossil adds an |
| 41 | 42 | integrated [./wikitheory.wiki | wiki], |
| 42 | 43 | [./bugtheory.wiki | ticketing & bug tracking], |
| 43 | 44 | [./embeddeddoc.wiki | embedded documentation], and |
| 44 | 45 | [./event.wiki | Technical notes]. |
| 45 | -These additional capabilities are available for Git as 3rd-party | |
| 46 | +These additional capabilities are available for Git as 3rd-party and/or | |
| 46 | 47 | user-installed add-ons, but with Fossil they are integrated into |
| 47 | 48 | the design. One way to describe Fossil is that it is |
| 48 | 49 | "[https://github.com/ | github]-in-a-box". |
| 49 | 50 | |
| 50 | -<h3>3.2 Sharding versus Replicating</h3> | |
| 51 | - | |
| 52 | -Git makes it easy for each repository in a project to hold a subset of | |
| 53 | -the branches for that project. In fact, it is entirely possible and not | |
| 54 | -uncommon for no repository in the project to hold all the different code | |
| 55 | -versions for a project. Instead the information is distributed. | |
| 56 | -Individual developers have one or more private branches. A hierarchy | |
| 57 | -of integrators merge changes from individual developers into collaborative | |
| 58 | -branches, until all the changes are merged together at the top-level master | |
| 59 | -branch. And all of this can be accomplished without having to have all the | |
| 60 | -code in any one repository. Developers or groups of developers can share | |
| 61 | -only those branches that they want to share and keep other branches of the | |
| 62 | -project private. This is analogous to sharding a distributed database. | |
| 63 | - | |
| 64 | -Fossil allows private branches, but its default mode is to share everything. | |
| 65 | -And so in a Fossil project, all repositories tend to contain all of the | |
| 66 | -content at all times. This is analogous to replication in a | |
| 67 | -distributed database. | |
| 68 | - | |
| 69 | -The Git model works best for large projects, like the | |
| 70 | -Linux kernel for which Git was designed. | |
| 71 | -Linus Torvalds does not need or want to see a thousand | |
| 72 | -different branches, one for each contributor. Git allows intermediary | |
| 73 | -"gate-keepers" to merge changes from multiple lower-level developers | |
| 74 | -into a single branch and only present Linus with a handful of branches | |
| 75 | -at a time. Git encourages a programming model where each developer | |
| 76 | -works in his or her own branch and then merges changes up the hierarchy | |
| 77 | -until they reach the master branch. | |
| 78 | - | |
| 79 | -Fossil is designed for smaller and non-hierarchical teams where all | |
| 80 | -developers are operating directly on the master branch, or at most | |
| 81 | -a small number of well-defined branches. | |
| 82 | -The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy | |
| 83 | -for multiple developers to work on a single branch and maintain | |
| 84 | -linear development on that branch and avoid needless forking | |
| 85 | -and merging. | |
| 86 | - | |
| 87 | -<h3>3.3 Branches</h3> | |
| 88 | - | |
| 89 | -Git (and especially GitHub) encourages a workflow where each developer | |
| 90 | -has his or her own branch or branches. Developers then send "pull requests" | |
| 91 | -to have their changes be merged into "official" branches by integrators. | |
| 92 | -For example, the Linux kernel team has a hierarchy of integrators with | |
| 93 | -Linus Torvalds at the root. Individual developers each have their own | |
| 94 | -private branches of the source tree into which they make their own changes. | |
| 95 | -They then encourage first-tier integrators to pull those changes. The | |
| 96 | -first-tier integrators merge together changes from multiple contributors | |
| 97 | -then try to get second-tier integrators to pull their branches. The | |
| 98 | -changes merge up the hierarchy until (hopefully) they are pulled into | |
| 99 | -"Linus's branch", at which time they become part of the "official" Linux. | |
| 100 | - | |
| 101 | -In Git, each branch is "owned" by the person who creates it and works | |
| 102 | -on it. The owner might pull changes from others, but the owner is always | |
| 103 | -in control of the branch. Branches are developer-centric. | |
| 104 | - | |
| 105 | -Fossil, on the other hand, encourages a workflow where branches are | |
| 106 | -associated with features or releases, not individual developers. | |
| 107 | -All developers share all branches in common, and two | |
| 108 | -or more developers can and often do intersperse commits onto the same branch. | |
| 109 | -Branches do not belong to individuals. All branches are read/write | |
| 110 | -accessible to all developers at all times. There is no need | |
| 111 | -for integrators to merge together changes from various independent | |
| 112 | -developers. Instead, all of the developers work together cooperatively | |
| 113 | -and the changes stay integrated naturally. | |
| 114 | - | |
| 115 | -So to a first approximation, branches in Git are developer-centric whereas | |
| 116 | -branches in Fossil are feature-centric. | |
| 117 | - | |
| 118 | -The Git approach scales much better for large projects like the Linux | |
| 119 | -kernel with thousands of contributors who in many cases don't even know | |
| 120 | -each other's names. The integrators serve a gatekeeper role to help keep | |
| 121 | -undesirable code out of the official Linux source tree. On the other hand, | |
| 122 | -not many projects are as big or as loosely organized as the Linux kernel. | |
| 123 | -Most projects have a small team of developers who all know each other | |
| 124 | -well and trust each other, and who enjoy working together collaboratively | |
| 125 | -without the overhead and hierarchy of integrators. | |
| 126 | - | |
| 127 | -One consequence of the "everybody-sees-everything" focus of Fossil is that | |
| 128 | -branch names are global and are part of the distributed and synchronized | |
| 129 | -content of a Fossil repository, rather than being private and user-specific | |
| 130 | -as they are in Git. | |
| 131 | - | |
| 132 | -<h3>3.4 Complexity</h3> | |
| 133 | - | |
| 134 | -Git is a complex system. It can be tricky to use and requires a fair | |
| 135 | -amount of knowledge and experience to master. Fossil strives to be | |
| 136 | -a much simpler system that can be learned and mastered much more quickly. | |
| 137 | -Fossil strives to have fewer "gotchas" and quirks that can trip up a | |
| 138 | -developer. | |
| 139 | - | |
| 140 | -The ideal VCS should just get out of the way of the developer and allow | |
| 141 | -the developer to focus 100% of their thinking on the project under | |
| 142 | -development. One should not have to stop and think about how to operate | |
| 143 | -the VCS. Of course, no VCS is ideal. Every VCS requires the developer | |
| 144 | -to think about version control to some extent. But one wants to minimize | |
| 145 | -the thinking about version control. | |
| 146 | - | |
| 147 | -Git requires the developer to maintain a more complex mental model than | |
| 148 | -most other DVCSes. Git takes longer to learn. And you have to spend | |
| 149 | -more time thinking about what you are doing with Git. | |
| 150 | - | |
| 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] | |
| 164 | -and a really simple mechanism (the "[/help/ui|fossil ui]" command) to | |
| 165 | -automatically start the web server and bring up a web browser to navigate | |
| 166 | -it. The web interface for Fossil is not only easier to set up, it is also | |
| 167 | -more powerful and easier to use. The web interface to Fossil is a practical | |
| 168 | -replacement to the 3rd-party "GUI Tools" that users often employ to operate | |
| 169 | -Git. | |
| 170 | - | |
| 171 | -<h3>3.6 Implementation Strategy</h3> | |
| 172 | - | |
| 173 | -Git consists of a collection of many little programs. Git needs to be | |
| 174 | -"installed" using some kind of installer or package tool. Git can be | |
| 175 | -tricky to install and get working, especially for users without | |
| 176 | -administrative privileges. | |
| 177 | - | |
| 178 | -Fossil is a single self-contained executable. To "install" Fossil one | |
| 179 | -has merely to download a precompiled binary and place that binary | |
| 180 | -somewhere on $PATH. To uninstall Fossil, simply delete the binary. | |
| 181 | -To upgrade Fossil, replace the old binary with a new one. | |
| 182 | - | |
| 183 | -Fossil is designed to be trivial to install, uninstall, and upgrade so | |
| 184 | -that developers can spend more time working on their own projects and | |
| 185 | -much less time configuring their version control system. | |
| 186 | - | |
| 187 | -<h3>3.7 Repository Storage</h3> | |
| 188 | - | |
| 189 | -A Git repository is a "pile-of-files" in the ".git" directory at the | |
| 190 | -root of the working checkout. There is a one-to-one correspondence | |
| 191 | -between repositories and working checkouts. A power-loss or system crash | |
| 192 | -in the middle of Git operation can damage or corrupt the Git repository. | |
| 193 | - | |
| 194 | -A Fossil repository consists of a single disk file. A single Fossil | |
| 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 | |
| 222 | -as part of the documentation for the project. | |
| 223 | - | |
| 224 | -Fossil takes an opposing view. Fossil views history as sacrosanct and | |
| 225 | -stubbornly refuses to change it. | |
| 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. | |
| 51 | +If you clone Git's self-hosting repository you get just Git's source code. | |
| 52 | +If you clone Fossil's self-hosting repository, you get the entire | |
| 53 | +Fossil website - source code, documentation, ticket history, and so forth. | |
| 54 | + | |
| 55 | +For developers who choose to self-host projects (rather than using a | |
| 56 | +3rd-party service such as GitHub) Fossil is much easier to set up, since | |
| 57 | +the stand-alone Fossil executable together with a 2-line CGI script | |
| 58 | +suffice to instantiate a full-featured developer website. To accomplish | |
| 59 | +the same using Git requires locating, installed, configuring, integrating, | |
| 60 | +and managing a wide assortment of separate tools. Standing up a developer | |
| 61 | +website using Fossil can be done in minutes, whereas doing the same using | |
| 62 | +Git requires hours or days. | |
| 63 | + | |
| 64 | +<h3>3.2 Database</h3> | |
| 65 | + | |
| 66 | +The baseline data structures for Fossil and Git are the same (modulo | |
| 67 | +formatting details). Both systems store check-ins as immutable | |
| 68 | +objects referencing their immediate ancestors and named by their SHA1 hash. | |
| 69 | + | |
| 70 | +The difference is that Git stores its objects as individual files | |
| 71 | +in the ".git" folder or compressed into | |
| 72 | +a bespoke "pack-files", whereas Fossil stores its objects in a | |
| 73 | +relational ([https://www.sqlite.org/|SQLite]) database file. To put it | |
| 74 | +another way, Git uses an ad-hoc pile-of-files key/value database whereas | |
| 75 | +Fossil uses a proven, general-purpose SQL database. This | |
| 76 | +difference is more than an implementation detail. It | |
| 77 | +has important consequences. | |
| 78 | + | |
| 79 | +With Git, one can easily locate the ancestors of a particular check-in | |
| 80 | +by following the pointers embedded the check-in object, but it is very | |
| 81 | +difficult to go the other direction and locate the descendants of a | |
| 82 | +check-in. It is so difficult, in fact, that neither native Git nor | |
| 83 | +GitHub provide this capability. With Git, if you are looking at some | |
| 84 | +historical check-in then you cannot ask | |
| 85 | +"what came next" or "what are the children of this check-in". | |
| 86 | + | |
| 87 | +Fossil, on the other hand, parses essential information about check-ins | |
| 88 | +(such as parentage) into a relation database that can be easily | |
| 89 | +queried using concise SQL statements to find both ancestors and | |
| 90 | +descendents of a check-in. | |
| 91 | + | |
| 92 | +Leaf check-ins in Git that lack a "ref" become "detached", making them | |
| 93 | +difficult to locate and subject to garbage collection. This | |
| 94 | +"detached head" problem has caused untold grief for countless | |
| 95 | +Git users. With Fossil, all check-ins are easily located using | |
| 96 | +a variety of attributes (parents, children, committer, date, full-text | |
| 97 | +search of the check-in comment) and so detached heads are simply not possible. | |
| 98 | + | |
| 99 | +The ease with which check-ins can be located and queried in Fossil | |
| 100 | +has resulted in a huge variety of reports and status screens | |
| 101 | +([./webpage-ex.md|examples]) that show project state | |
| 102 | +in ways that help developers | |
| 103 | +maintain enhanced awareness and comprehension | |
| 104 | +and avoid errors. | |
| 105 | + | |
| 106 | +<h3>3.3 Cathedral vs. Bazaar</h3> | |
| 107 | + | |
| 108 | +Fossil and Git promote different development styles. Git promotes a | |
| 109 | +"bazaar" development style in which numerous anonymous developers make | |
| 110 | +small and sometimes haphazard contributions. Fossil | |
| 111 | +promotes a "cathedral" development model in which the project is | |
| 112 | +closely supervised by an highly engaged architect and implemented by | |
| 113 | +a clique of developers. | |
| 114 | + | |
| 115 | +Nota Bene: This is not to say that Git cannot be used for cathedral-style | |
| 116 | +development or that Fossil cannot be used for bazaar-style development. | |
| 117 | +They can be. But those modes are not their design intent nor the their | |
| 118 | +low-friction path. | |
| 119 | + | |
| 120 | +Git encourages a style in which individual developers work in relative | |
| 121 | +isolation, maintaining their | |
| 122 | +own branches and the occasionally rebasing and pushing selected changes up | |
| 123 | +to the main repository. Developers using Git often have their own | |
| 124 | +private branches that nobody else ever sees. Work becomes siloed. | |
| 125 | +This is exactly what one wants when doing bazaar-style development. | |
| 126 | + | |
| 127 | +Fossil, in contrast, strives to keep all changes from all contributors | |
| 128 | +mirrored in the main repository (in separate branches) at all times. | |
| 129 | +Work in progress from one developer is readily visible to all other | |
| 130 | +developers and to the project leader, well before the code is ready | |
| 131 | +to integrate. Fossil places a lot of emphasis on reporting the state | |
| 132 | +of the project, and the changes underway by all developers, so that | |
| 133 | +all developers and especially the project leader can maintain a better | |
| 134 | +mental picture of what is happening, and better situational awareness. | |
| 135 | + | |
| 136 | +<h3>3.4 Linux vs. SQLite</h3> | |
| 137 | + | |
| 138 | +Git was specifically designed to support the development of Linux. | |
| 139 | +Fossil was specifically designed to support the development of SQLite. | |
| 140 | + | |
| 141 | +Both SQLite and Linux are important pieces of software. | |
| 142 | +SQLite is found on far more systems than Linux. (Almost every Linux | |
| 143 | +system uses SQLite, but there are many non-Linux systems such as | |
| 144 | +iPhones, PlayStations, and Windows PC that use SQLite.) On the other | |
| 145 | +hand, for those systems that do use Linux, Linux is a far more important | |
| 146 | +component. | |
| 147 | + | |
| 148 | +Linux uses a bazaar-style development model. There are thousands and | |
| 149 | +thousands of contributors, most of whom do not know each others names. | |
| 150 | +Git is designed for this scenario. | |
| 151 | + | |
| 152 | +SQLite uses cathedral-style development. 95% of the code in SQLite | |
| 153 | +comes from just three programmers, 64% from just the lead developer. | |
| 154 | +And all SQLite developers know each other well and interact daily. | |
| 155 | +Fossil is designed for this development model. | |
| 156 | + | |
| 157 | +<h3>3.5 Lots of little tools vs. Self-contained system</h3> | |
| 158 | + | |
| 159 | +Git consists of many small tools, each doing one small part of the job, | |
| 160 | +which can be recombined (by experts) to perform powerful operations. | |
| 161 | +Git has a lot of complexity and many dependencies and requires an "installer" | |
| 162 | +script or program to get it running. | |
| 163 | + | |
| 164 | +Fossil is a single self-contained stand-alone executable with hardly | |
| 165 | +any dependencies. Fossil can be (and often is) run inside a | |
| 166 | +minimally configured chroot jail. To install Fossil, | |
| 167 | +one merely puts the executable on $PATH. | |
| 168 | + | |
| 169 | +The designer of Git says that the unix philosophy is to have lots of | |
| 170 | +small tools that collaborate to get the job done. The designer of | |
| 171 | +Fossil says that the unix philosophy is "it just works". Both | |
| 172 | +individuals have written their DVCSes to reflect their own view | |
| 173 | +of the "unix philosophy". | |
| 174 | + | |
| 175 | +<h3>3.6 One vs. Many Check-outs per Repository</h3> | |
| 176 | + | |
| 177 | +A "repository" in Git is a pile-of-files in the ".git" subdirectory | |
| 178 | +of a single check-out. The check-out and the repository are inseperable. | |
| 179 | + | |
| 180 | +With Fossil, a "repository" is a single SQLite database file | |
| 181 | +that can be stored anywhere. There | |
| 182 | +can be multiple active check-outs from the same repository, perhaps | |
| 183 | +open on different branches or on different snapshots of the same branch. | |
| 184 | +Long-running tests or builds can be running in one check-out while | |
| 185 | +changes are being committed in another. | |
| 186 | + | |
| 187 | +<h3>3.7 What you should have done vs. What you actually did</h3> | |
| 188 | + | |
| 189 | +Git puts a lot of emphasis on maintaining | |
| 190 | +a "clean" check-in history. Extraneous and experimental branches by | |
| 191 | +individual developers often never make it into the main repository. And | |
| 192 | +branches are often rebased before being pushed, to make | |
| 193 | +it appear as if development had been linear. Git strives to record what | |
| 194 | +the development of a project should have looked like had there been no | |
| 195 | +mistakes. | |
| 196 | + | |
| 197 | +Fossil, in contrast, puts more emphasis on recording exactly what happened, | |
| 198 | +including all of the messy errors, dead-ends, experimental branches, and | |
| 199 | +so forth. One might argue that this | |
| 200 | +makes the history of a Fossil project "messy". But another point of view | |
| 201 | +is that this makes the history "accurate". In actual practice, the | |
| 202 | +superior reporting tools available in Fossil mean that the added "mess" | |
| 203 | +is not a factor. | |
| 204 | + | |
| 205 | +One commentator has mused that Git records history according to | |
| 206 | +the victors, whereas Fossil records history as it actually happened. | |
| 207 | + | |
| 208 | +<h3>3.8 GPL vs. BSD</h3> | |
| 209 | + | |
| 210 | +Git is covered by the GPL license whereas Fossil is covered by | |
| 211 | +a two-clause BSD license. | |
| 212 | + | |
| 213 | +Consider the difference between GPL and BSD licenses: GPL is designed | |
| 214 | +to make writing easier at the expense of making reading harder. BSD is | |
| 215 | +designed to make reading easier and the expense of making writing harder. | |
| 216 | + | |
| 217 | +To a first approximation, the GPL license grants the right to read | |
| 218 | +source code to anyone who promises to give back enhancements. In other | |
| 219 | +words, the act of reading GPL source code (a prerequiste for making changes) | |
| 220 | +implies acceptance of the license which requires updates to be contributed | |
| 221 | +back under the same license. (The details are more complex, but the | |
| 222 | +foregoing captures the essence of the idea.) A big advantage of the GPL | |
| 223 | +is that anybody can contribute to the code without having to sign additional | |
| 224 | +legal documentation because they have implied their acceptance of the GPL | |
| 225 | +license by the very act of reading the source code. This means that a GPL | |
| 226 | +project can legally accept anonymous and drive-by patches. | |
| 227 | + | |
| 228 | +The BSD licenses, on the other hand, make reading much easier than the GPL, | |
| 229 | +because the reader need not surrender proprietary interest | |
| 230 | +in their own enhancements. On the flip side, BSD and similarly licensed | |
| 231 | +projects must obtain legal affidavits from authors before | |
| 232 | +new content can be added into the project. Anonymous and drive-by | |
| 233 | +patches cannot be accepted. This makes signing up new contributors for | |
| 234 | +BSD licensed projects harder. | |
| 235 | + | |
| 236 | +The licenses on the implementations of Git and Fossil only apply to the | |
| 237 | +implementations themselves, not to the projects which the systems store. | |
| 238 | +Nevertheless, one can see a more GPL-oriented world-view in Git and a | |
| 239 | +more BSD-oriented world-view in Fossil. Git encourages anonymous contributions | |
| 240 | +and siloed development, which are hallmarks of the GPL/bazaar approach to | |
| 241 | +software, whereas Fossil encourages a more tightly collaborative, | |
| 242 | +cliquish, cathedral-style approach more typical of BSD-licensed projects. | |
| 243 | + | |
| 244 | +<h2>4.0 Missing Features</h2> | |
| 245 | + | |
| 246 | +Most of the capabilities found in Git are also available in Fossil and | |
| 247 | +the other way around. For example, both systems have local check-outs, | |
| 248 | +remote repositories, push/pull/sync, bisect capabilities, and a "stash". | |
| 249 | +Both systems store project history as a directed acyclic graph (DAG) | |
| 250 | +of immutable check-in objects. | |
| 251 | + | |
| 252 | +But there are a few capabilities in one system that are missing from the | |
| 253 | +other. | |
| 254 | + | |
| 255 | +<h3>4.1 Features found in Fossil but missing from Git</h3> | |
| 256 | + | |
| 257 | + * <b>The ability to show descendents of a check-in.</b> | |
| 258 | + | |
| 259 | + Both Git and Fossil can easily find the ancestors of a check-in. But | |
| 260 | + only Fossil shows the descendents. (It is possible to find the | |
| 261 | + descendents of a check-in in Git using the log, but that is sufficiently | |
| 262 | + difficult that nobody ever actually does it.) | |
| 263 | + | |
| 264 | + * <b>Wiki, Embedded documentation, Trouble-tickets, and Tech-Notes</b> | |
| 265 | + | |
| 266 | + Git only provides versioning of source code. Fossil strives to provide | |
| 267 | + other related configuration management services as well. | |
| 268 | + | |
| 269 | + * <b>Named branches</b> | |
| 270 | + | |
| 271 | + Branches in Fossil have persistent names that are propagated | |
| 272 | + to collaborators via [/help?cmd=push|push] and [/help?cmd=pull|pull]. | |
| 273 | + All developers see the same name on the same branch. Git, in contrast, | |
| 274 | + uses only local branch names, so developers working on the | |
| 275 | + same project can (and frequently do) use a different name for the | |
| 276 | + same branch. | |
| 277 | + | |
| 278 | + * <b>The [/help?cmd=all|fossil all] command</b> | |
| 279 | + | |
| 280 | + Fossil keeps track of all repositories and check-outs and allows | |
| 281 | + operations over all of them with a single command. For example, in | |
| 282 | + Fossil is possible to request a pull of all repositories on a laptop | |
| 283 | + from their respective servers, prior to taking the laptop off network. | |
| 284 | + Or it is possible to do "fossil all status" to see if there are any | |
| 285 | + uncommitted changes that were overlooked prior to the end of the workday. | |
| 286 | + | |
| 287 | + * <b>The [/help?cmd=ui|fossil ui] command</b> | |
| 288 | + | |
| 289 | + Fossil supports an integrated web interface. Some of the same features | |
| 290 | + are available using third-party add-ons for Git, but they do not provide | |
| 291 | + nearly as many features and they are not nearly as convenient to use. | |
| 292 | + | |
| 293 | + | |
| 294 | +<h2>4.2 Features found in Git but missing from Fossil</h2> | |
| 295 | + | |
| 296 | + * <b>Rebase</b> | |
| 297 | + | |
| 298 | + Because of its emphasis on recording history exactly as it happened, | |
| 299 | + rather than as we would have liked it to happen, Fossil deliberately | |
| 300 | + does not provide a "rebase" command. One can rebase manually in Fossil, | |
| 301 | + with sufficient perserverence, but it not something that can be done with | |
| 302 | + a single command. | |
| 303 | + | |
| 304 | + * <b>Push or pull a single branch</b> | |
| 305 | + | |
| 306 | + The [/help?cmd=push|fossil push], [/help?cmd=pull|fossil pull], and | |
| 307 | + [/help?cmd=sync|fossil sync] commands do not provide the capability to | |
| 308 | + push or pull individual branches. Pushing and pulling in Fossil is | |
| 309 | + all or nothing. This is in keeping with Fossil's emphasis on maintaining | |
| 310 | + a complete record and on sharing everything between all developers. | |
| 273 | 311 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -3,12 +3,13 @@ | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | it is [./inout.wiki | easy to change]. |
| 7 | |
| 8 | But it also helps to be informed about the differences between |
| 9 | [http://git-scm.com | Git] and Fossil. See the table below for |
| 10 | a high-level summary and the text that follows for more details. |
| 11 | |
| 12 | Keep in mind that you are reading this on a Fossil website, |
| 13 | so the information here |
| 14 | might be biased in favor of Fossil. Ask around with people who have |
| @@ -18,20 +19,20 @@ | |
| 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> |
| 37 | |
| @@ -40,233 +41,270 @@ | |
| 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 | |
| 50 | <h3>3.2 Sharding versus Replicating</h3> |
| 51 | |
| 52 | Git makes it easy for each repository in a project to hold a subset of |
| 53 | the branches for that project. In fact, it is entirely possible and not |
| 54 | uncommon for no repository in the project to hold all the different code |
| 55 | versions for a project. Instead the information is distributed. |
| 56 | Individual developers have one or more private branches. A hierarchy |
| 57 | of integrators merge changes from individual developers into collaborative |
| 58 | branches, until all the changes are merged together at the top-level master |
| 59 | branch. And all of this can be accomplished without having to have all the |
| 60 | code in any one repository. Developers or groups of developers can share |
| 61 | only those branches that they want to share and keep other branches of the |
| 62 | project private. This is analogous to sharding a distributed database. |
| 63 | |
| 64 | Fossil allows private branches, but its default mode is to share everything. |
| 65 | And so in a Fossil project, all repositories tend to contain all of the |
| 66 | content at all times. This is analogous to replication in a |
| 67 | distributed database. |
| 68 | |
| 69 | The Git model works best for large projects, like the |
| 70 | Linux kernel for which Git was designed. |
| 71 | Linus Torvalds does not need or want to see a thousand |
| 72 | different branches, one for each contributor. Git allows intermediary |
| 73 | "gate-keepers" to merge changes from multiple lower-level developers |
| 74 | into a single branch and only present Linus with a handful of branches |
| 75 | at a time. Git encourages a programming model where each developer |
| 76 | works in his or her own branch and then merges changes up the hierarchy |
| 77 | until they reach the master branch. |
| 78 | |
| 79 | Fossil is designed for smaller and non-hierarchical teams where all |
| 80 | developers are operating directly on the master branch, or at most |
| 81 | a small number of well-defined branches. |
| 82 | The [./concepts.wiki#workflow | autosync] mode of Fossil makes it easy |
| 83 | for multiple developers to work on a single branch and maintain |
| 84 | linear development on that branch and avoid needless forking |
| 85 | and merging. |
| 86 | |
| 87 | <h3>3.3 Branches</h3> |
| 88 | |
| 89 | Git (and especially GitHub) encourages a workflow where each developer |
| 90 | has his or her own branch or branches. Developers then send "pull requests" |
| 91 | to have their changes be merged into "official" branches by integrators. |
| 92 | For example, the Linux kernel team has a hierarchy of integrators with |
| 93 | Linus Torvalds at the root. Individual developers each have their own |
| 94 | private branches of the source tree into which they make their own changes. |
| 95 | They then encourage first-tier integrators to pull those changes. The |
| 96 | first-tier integrators merge together changes from multiple contributors |
| 97 | then try to get second-tier integrators to pull their branches. The |
| 98 | changes merge up the hierarchy until (hopefully) they are pulled into |
| 99 | "Linus's branch", at which time they become part of the "official" Linux. |
| 100 | |
| 101 | In Git, each branch is "owned" by the person who creates it and works |
| 102 | on it. The owner might pull changes from others, but the owner is always |
| 103 | in control of the branch. Branches are developer-centric. |
| 104 | |
| 105 | Fossil, on the other hand, encourages a workflow where branches are |
| 106 | associated with features or releases, not individual developers. |
| 107 | All developers share all branches in common, and two |
| 108 | or more developers can and often do intersperse commits onto the same branch. |
| 109 | Branches do not belong to individuals. All branches are read/write |
| 110 | accessible to all developers at all times. There is no need |
| 111 | for integrators to merge together changes from various independent |
| 112 | developers. Instead, all of the developers work together cooperatively |
| 113 | and the changes stay integrated naturally. |
| 114 | |
| 115 | So to a first approximation, branches in Git are developer-centric whereas |
| 116 | branches in Fossil are feature-centric. |
| 117 | |
| 118 | The Git approach scales much better for large projects like the Linux |
| 119 | kernel with thousands of contributors who in many cases don't even know |
| 120 | each other's names. The integrators serve a gatekeeper role to help keep |
| 121 | undesirable code out of the official Linux source tree. On the other hand, |
| 122 | not many projects are as big or as loosely organized as the Linux kernel. |
| 123 | Most projects have a small team of developers who all know each other |
| 124 | well and trust each other, and who enjoy working together collaboratively |
| 125 | without the overhead and hierarchy of integrators. |
| 126 | |
| 127 | One consequence of the "everybody-sees-everything" focus of Fossil is that |
| 128 | branch names are global and are part of the distributed and synchronized |
| 129 | content of a Fossil repository, rather than being private and user-specific |
| 130 | as they are in Git. |
| 131 | |
| 132 | <h3>3.4 Complexity</h3> |
| 133 | |
| 134 | Git is a complex system. It can be tricky to use and requires a fair |
| 135 | amount of knowledge and experience to master. Fossil strives to be |
| 136 | a much simpler system that can be learned and mastered much more quickly. |
| 137 | Fossil strives to have fewer "gotchas" and quirks that can trip up a |
| 138 | developer. |
| 139 | |
| 140 | The ideal VCS should just get out of the way of the developer and allow |
| 141 | the developer to focus 100% of their thinking on the project under |
| 142 | development. One should not have to stop and think about how to operate |
| 143 | the VCS. Of course, no VCS is ideal. Every VCS requires the developer |
| 144 | to think about version control to some extent. But one wants to minimize |
| 145 | the thinking about version control. |
| 146 | |
| 147 | Git requires the developer to maintain a more complex mental model than |
| 148 | most other DVCSes. Git takes longer to learn. And you have to spend |
| 149 | more time thinking about what you are doing with Git. |
| 150 | |
| 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] |
| 164 | and a really simple mechanism (the "[/help/ui|fossil ui]" command) to |
| 165 | automatically start the web server and bring up a web browser to navigate |
| 166 | it. The web interface for Fossil is not only easier to set up, it is also |
| 167 | more powerful and easier to use. The web interface to Fossil is a practical |
| 168 | replacement to the 3rd-party "GUI Tools" that users often employ to operate |
| 169 | Git. |
| 170 | |
| 171 | <h3>3.6 Implementation Strategy</h3> |
| 172 | |
| 173 | Git consists of a collection of many little programs. Git needs to be |
| 174 | "installed" using some kind of installer or package tool. Git can be |
| 175 | tricky to install and get working, especially for users without |
| 176 | administrative privileges. |
| 177 | |
| 178 | Fossil is a single self-contained executable. To "install" Fossil one |
| 179 | has merely to download a precompiled binary and place that binary |
| 180 | somewhere on $PATH. To uninstall Fossil, simply delete the binary. |
| 181 | To upgrade Fossil, replace the old binary with a new one. |
| 182 | |
| 183 | Fossil is designed to be trivial to install, uninstall, and upgrade so |
| 184 | that developers can spend more time working on their own projects and |
| 185 | much less time configuring their version control system. |
| 186 | |
| 187 | <h3>3.7 Repository Storage</h3> |
| 188 | |
| 189 | A Git repository is a "pile-of-files" in the ".git" directory at the |
| 190 | root of the working checkout. There is a one-to-one correspondence |
| 191 | between repositories and working checkouts. A power-loss or system crash |
| 192 | in the middle of Git operation can damage or corrupt the Git repository. |
| 193 | |
| 194 | A Fossil repository consists of a single disk file. A single Fossil |
| 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 |
| 222 | as part of the documentation for the project. |
| 223 | |
| 224 | Fossil takes an opposing view. Fossil views history as sacrosanct and |
| 225 | stubbornly refuses to change it. |
| 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 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -3,12 +3,13 @@ | |
| 3 | <h2>1.0 Don't Stress!</h2> |
| 4 | |
| 5 | If you start out using one DVCS and later decide you like the other better, |
| 6 | it is [./inout.wiki | easy to change]. |
| 7 | |
| 8 | Fossil and [http://git-scm.com | Git] are very similar in many respects, |
| 9 | but there are also important differences. |
| 10 | See the table below for |
| 11 | a high-level summary and the text that follows for more details. |
| 12 | |
| 13 | Keep in mind that you are reading this on a Fossil website, |
| 14 | so the information here |
| 15 | might be biased in favor of Fossil. Ask around with people who have |
| @@ -18,20 +19,20 @@ | |
| 19 | |
| 20 | <blockquote><center><table border=1 cellpadding=5> |
| 21 | <tr><th width="50%">GIT</th><th width="50%">FOSSIL</th></tr> |
| 22 | <tr><td>File versioning only</td> |
| 23 | <td>Versioning, Tickets, Wiki, and Technotes</td></tr> |
| 24 | <tr><td>Ad-hoc, pile-of-files key/value database</td> |
| 25 | <td>Relational SQL database</td></tr> |
| 26 | <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> |
| 27 | <tr><td>Designed for Linux development</td> |
| 28 | <td>Designed for SQLite development</td></tr> |
| 29 | <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> |
| 30 | <tr><td>One check-out per repository</td> |
| 31 | <td>Many check-outs per repository</td></tr> |
| 32 | <tr><td>Remembers what you should have done</td> |
| 33 | <td>Remembers what you actually did</td></tr> |
| 34 | <tr><td>GPL</td><td>BSD</td></tr> |
| 35 | </table></center></blockquote> |
| 36 | |
| 37 | <h2>3.0 Discussion</h2> |
| 38 | |
| @@ -40,233 +41,270 @@ | |
| 41 | Git provides file versioning services only, whereas Fossil adds an |
| 42 | integrated [./wikitheory.wiki | wiki], |
| 43 | [./bugtheory.wiki | ticketing & bug tracking], |
| 44 | [./embeddeddoc.wiki | embedded documentation], and |
| 45 | [./event.wiki | Technical notes]. |
| 46 | These additional capabilities are available for Git as 3rd-party and/or |
| 47 | user-installed add-ons, but with Fossil they are integrated into |
| 48 | the design. One way to describe Fossil is that it is |
| 49 | "[https://github.com/ | github]-in-a-box". |
| 50 | |
| 51 | If you clone Git's self-hosting repository you get just Git's source code. |
| 52 | If you clone Fossil's self-hosting repository, you get the entire |
| 53 | Fossil website - source code, documentation, ticket history, and so forth. |
| 54 | |
| 55 | For developers who choose to self-host projects (rather than using a |
| 56 | 3rd-party service such as GitHub) Fossil is much easier to set up, since |
| 57 | the stand-alone Fossil executable together with a 2-line CGI script |
| 58 | suffice to instantiate a full-featured developer website. To accomplish |
| 59 | the same using Git requires locating, installed, configuring, integrating, |
| 60 | and managing a wide assortment of separate tools. Standing up a developer |
| 61 | website using Fossil can be done in minutes, whereas doing the same using |
| 62 | Git requires hours or days. |
| 63 | |
| 64 | <h3>3.2 Database</h3> |
| 65 | |
| 66 | The baseline data structures for Fossil and Git are the same (modulo |
| 67 | formatting details). Both systems store check-ins as immutable |
| 68 | objects referencing their immediate ancestors and named by their SHA1 hash. |
| 69 | |
| 70 | The difference is that Git stores its objects as individual files |
| 71 | in the ".git" folder or compressed into |
| 72 | a bespoke "pack-files", whereas Fossil stores its objects in a |
| 73 | relational ([https://www.sqlite.org/|SQLite]) database file. To put it |
| 74 | another way, Git uses an ad-hoc pile-of-files key/value database whereas |
| 75 | Fossil uses a proven, general-purpose SQL database. This |
| 76 | difference is more than an implementation detail. It |
| 77 | has important consequences. |
| 78 | |
| 79 | With Git, one can easily locate the ancestors of a particular check-in |
| 80 | by following the pointers embedded the check-in object, but it is very |
| 81 | difficult to go the other direction and locate the descendants of a |
| 82 | check-in. It is so difficult, in fact, that neither native Git nor |
| 83 | GitHub provide this capability. With Git, if you are looking at some |
| 84 | historical check-in then you cannot ask |
| 85 | "what came next" or "what are the children of this check-in". |
| 86 | |
| 87 | Fossil, on the other hand, parses essential information about check-ins |
| 88 | (such as parentage) into a relation database that can be easily |
| 89 | queried using concise SQL statements to find both ancestors and |
| 90 | descendents of a check-in. |
| 91 | |
| 92 | Leaf check-ins in Git that lack a "ref" become "detached", making them |
| 93 | difficult to locate and subject to garbage collection. This |
| 94 | "detached head" problem has caused untold grief for countless |
| 95 | Git users. With Fossil, all check-ins are easily located using |
| 96 | a variety of attributes (parents, children, committer, date, full-text |
| 97 | search of the check-in comment) and so detached heads are simply not possible. |
| 98 | |
| 99 | The ease with which check-ins can be located and queried in Fossil |
| 100 | has resulted in a huge variety of reports and status screens |
| 101 | ([./webpage-ex.md|examples]) that show project state |
| 102 | in ways that help developers |
| 103 | maintain enhanced awareness and comprehension |
| 104 | and avoid errors. |
| 105 | |
| 106 | <h3>3.3 Cathedral vs. Bazaar</h3> |
| 107 | |
| 108 | Fossil and Git promote different development styles. Git promotes a |
| 109 | "bazaar" development style in which numerous anonymous developers make |
| 110 | small and sometimes haphazard contributions. Fossil |
| 111 | promotes a "cathedral" development model in which the project is |
| 112 | closely supervised by an highly engaged architect and implemented by |
| 113 | a clique of developers. |
| 114 | |
| 115 | Nota Bene: This is not to say that Git cannot be used for cathedral-style |
| 116 | development or that Fossil cannot be used for bazaar-style development. |
| 117 | They can be. But those modes are not their design intent nor the their |
| 118 | low-friction path. |
| 119 | |
| 120 | Git encourages a style in which individual developers work in relative |
| 121 | isolation, maintaining their |
| 122 | own branches and the occasionally rebasing and pushing selected changes up |
| 123 | to the main repository. Developers using Git often have their own |
| 124 | private branches that nobody else ever sees. Work becomes siloed. |
| 125 | This is exactly what one wants when doing bazaar-style development. |
| 126 | |
| 127 | Fossil, in contrast, strives to keep all changes from all contributors |
| 128 | mirrored in the main repository (in separate branches) at all times. |
| 129 | Work in progress from one developer is readily visible to all other |
| 130 | developers and to the project leader, well before the code is ready |
| 131 | to integrate. Fossil places a lot of emphasis on reporting the state |
| 132 | of the project, and the changes underway by all developers, so that |
| 133 | all developers and especially the project leader can maintain a better |
| 134 | mental picture of what is happening, and better situational awareness. |
| 135 | |
| 136 | <h3>3.4 Linux vs. SQLite</h3> |
| 137 | |
| 138 | Git was specifically designed to support the development of Linux. |
| 139 | Fossil was specifically designed to support the development of SQLite. |
| 140 | |
| 141 | Both SQLite and Linux are important pieces of software. |
| 142 | SQLite is found on far more systems than Linux. (Almost every Linux |
| 143 | system uses SQLite, but there are many non-Linux systems such as |
| 144 | iPhones, PlayStations, and Windows PC that use SQLite.) On the other |
| 145 | hand, for those systems that do use Linux, Linux is a far more important |
| 146 | component. |
| 147 | |
| 148 | Linux uses a bazaar-style development model. There are thousands and |
| 149 | thousands of contributors, most of whom do not know each others names. |
| 150 | Git is designed for this scenario. |
| 151 | |
| 152 | SQLite uses cathedral-style development. 95% of the code in SQLite |
| 153 | comes from just three programmers, 64% from just the lead developer. |
| 154 | And all SQLite developers know each other well and interact daily. |
| 155 | Fossil is designed for this development model. |
| 156 | |
| 157 | <h3>3.5 Lots of little tools vs. Self-contained system</h3> |
| 158 | |
| 159 | Git consists of many small tools, each doing one small part of the job, |
| 160 | which can be recombined (by experts) to perform powerful operations. |
| 161 | Git has a lot of complexity and many dependencies and requires an "installer" |
| 162 | script or program to get it running. |
| 163 | |
| 164 | Fossil is a single self-contained stand-alone executable with hardly |
| 165 | any dependencies. Fossil can be (and often is) run inside a |
| 166 | minimally configured chroot jail. To install Fossil, |
| 167 | one merely puts the executable on $PATH. |
| 168 | |
| 169 | The designer of Git says that the unix philosophy is to have lots of |
| 170 | small tools that collaborate to get the job done. The designer of |
| 171 | Fossil says that the unix philosophy is "it just works". Both |
| 172 | individuals have written their DVCSes to reflect their own view |
| 173 | of the "unix philosophy". |
| 174 | |
| 175 | <h3>3.6 One vs. Many Check-outs per Repository</h3> |
| 176 | |
| 177 | A "repository" in Git is a pile-of-files in the ".git" subdirectory |
| 178 | of a single check-out. The check-out and the repository are inseperable. |
| 179 | |
| 180 | With Fossil, a "repository" is a single SQLite database file |
| 181 | that can be stored anywhere. There |
| 182 | can be multiple active check-outs from the same repository, perhaps |
| 183 | open on different branches or on different snapshots of the same branch. |
| 184 | Long-running tests or builds can be running in one check-out while |
| 185 | changes are being committed in another. |
| 186 | |
| 187 | <h3>3.7 What you should have done vs. What you actually did</h3> |
| 188 | |
| 189 | Git puts a lot of emphasis on maintaining |
| 190 | a "clean" check-in history. Extraneous and experimental branches by |
| 191 | individual developers often never make it into the main repository. And |
| 192 | branches are often rebased before being pushed, to make |
| 193 | it appear as if development had been linear. Git strives to record what |
| 194 | the development of a project should have looked like had there been no |
| 195 | mistakes. |
| 196 | |
| 197 | Fossil, in contrast, puts more emphasis on recording exactly what happened, |
| 198 | including all of the messy errors, dead-ends, experimental branches, and |
| 199 | so forth. One might argue that this |
| 200 | makes the history of a Fossil project "messy". But another point of view |
| 201 | is that this makes the history "accurate". In actual practice, the |
| 202 | superior reporting tools available in Fossil mean that the added "mess" |
| 203 | is not a factor. |
| 204 | |
| 205 | One commentator has mused that Git records history according to |
| 206 | the victors, whereas Fossil records history as it actually happened. |
| 207 | |
| 208 | <h3>3.8 GPL vs. BSD</h3> |
| 209 | |
| 210 | Git is covered by the GPL license whereas Fossil is covered by |
| 211 | a two-clause BSD license. |
| 212 | |
| 213 | Consider the difference between GPL and BSD licenses: GPL is designed |
| 214 | to make writing easier at the expense of making reading harder. BSD is |
| 215 | designed to make reading easier and the expense of making writing harder. |
| 216 | |
| 217 | To a first approximation, the GPL license grants the right to read |
| 218 | source code to anyone who promises to give back enhancements. In other |
| 219 | words, the act of reading GPL source code (a prerequiste for making changes) |
| 220 | implies acceptance of the license which requires updates to be contributed |
| 221 | back under the same license. (The details are more complex, but the |
| 222 | foregoing captures the essence of the idea.) A big advantage of the GPL |
| 223 | is that anybody can contribute to the code without having to sign additional |
| 224 | legal documentation because they have implied their acceptance of the GPL |
| 225 | license by the very act of reading the source code. This means that a GPL |
| 226 | project can legally accept anonymous and drive-by patches. |
| 227 | |
| 228 | The BSD licenses, on the other hand, make reading much easier than the GPL, |
| 229 | because the reader need not surrender proprietary interest |
| 230 | in their own enhancements. On the flip side, BSD and similarly licensed |
| 231 | projects must obtain legal affidavits from authors before |
| 232 | new content can be added into the project. Anonymous and drive-by |
| 233 | patches cannot be accepted. This makes signing up new contributors for |
| 234 | BSD licensed projects harder. |
| 235 | |
| 236 | The licenses on the implementations of Git and Fossil only apply to the |
| 237 | implementations themselves, not to the projects which the systems store. |
| 238 | Nevertheless, one can see a more GPL-oriented world-view in Git and a |
| 239 | more BSD-oriented world-view in Fossil. Git encourages anonymous contributions |
| 240 | and siloed development, which are hallmarks of the GPL/bazaar approach to |
| 241 | software, whereas Fossil encourages a more tightly collaborative, |
| 242 | cliquish, cathedral-style approach more typical of BSD-licensed projects. |
| 243 | |
| 244 | <h2>4.0 Missing Features</h2> |
| 245 | |
| 246 | Most of the capabilities found in Git are also available in Fossil and |
| 247 | the other way around. For example, both systems have local check-outs, |
| 248 | remote repositories, push/pull/sync, bisect capabilities, and a "stash". |
| 249 | Both systems store project history as a directed acyclic graph (DAG) |
| 250 | of immutable check-in objects. |
| 251 | |
| 252 | But there are a few capabilities in one system that are missing from the |
| 253 | other. |
| 254 | |
| 255 | <h3>4.1 Features found in Fossil but missing from Git</h3> |
| 256 | |
| 257 | * <b>The ability to show descendents of a check-in.</b> |
| 258 | |
| 259 | Both Git and Fossil can easily find the ancestors of a check-in. But |
| 260 | only Fossil shows the descendents. (It is possible to find the |
| 261 | descendents of a check-in in Git using the log, but that is sufficiently |
| 262 | difficult that nobody ever actually does it.) |
| 263 | |
| 264 | * <b>Wiki, Embedded documentation, Trouble-tickets, and Tech-Notes</b> |
| 265 | |
| 266 | Git only provides versioning of source code. Fossil strives to provide |
| 267 | other related configuration management services as well. |
| 268 | |
| 269 | * <b>Named branches</b> |
| 270 | |
| 271 | Branches in Fossil have persistent names that are propagated |
| 272 | to collaborators via [/help?cmd=push|push] and [/help?cmd=pull|pull]. |
| 273 | All developers see the same name on the same branch. Git, in contrast, |
| 274 | uses only local branch names, so developers working on the |
| 275 | same project can (and frequently do) use a different name for the |
| 276 | same branch. |
| 277 | |
| 278 | * <b>The [/help?cmd=all|fossil all] command</b> |
| 279 | |
| 280 | Fossil keeps track of all repositories and check-outs and allows |
| 281 | operations over all of them with a single command. For example, in |
| 282 | Fossil is possible to request a pull of all repositories on a laptop |
| 283 | from their respective servers, prior to taking the laptop off network. |
| 284 | Or it is possible to do "fossil all status" to see if there are any |
| 285 | uncommitted changes that were overlooked prior to the end of the workday. |
| 286 | |
| 287 | * <b>The [/help?cmd=ui|fossil ui] command</b> |
| 288 | |
| 289 | Fossil supports an integrated web interface. Some of the same features |
| 290 | are available using third-party add-ons for Git, but they do not provide |
| 291 | nearly as many features and they are not nearly as convenient to use. |
| 292 | |
| 293 | |
| 294 | <h2>4.2 Features found in Git but missing from Fossil</h2> |
| 295 | |
| 296 | * <b>Rebase</b> |
| 297 | |
| 298 | Because of its emphasis on recording history exactly as it happened, |
| 299 | rather than as we would have liked it to happen, Fossil deliberately |
| 300 | does not provide a "rebase" command. One can rebase manually in Fossil, |
| 301 | with sufficient perserverence, but it not something that can be done with |
| 302 | a single command. |
| 303 | |
| 304 | * <b>Push or pull a single branch</b> |
| 305 | |
| 306 | The [/help?cmd=push|fossil push], [/help?cmd=pull|fossil pull], and |
| 307 | [/help?cmd=sync|fossil sync] commands do not provide the capability to |
| 308 | push or pull individual branches. Pushing and pulling in Fossil is |
| 309 | all or nothing. This is in keeping with Fossil's emphasis on maintaining |
| 310 | a complete record and on sharing everything between all developers. |
| 311 |