Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch bsd-vs-gpl Excluding Merge-Ins
This is equivalent to a diff from 69e7827d26 to a52e68459f
2019-07-17
| ||
02:37 | Reworked several sections of the fossil-v-git.wiki doc as sub-sections of "Linux vs. SQLite", which now acts as a frame for those sections. Some of these sections are expanded while others disappear entirely, most especially the "BSD vs GPL" argument that we started off on the now-merged branch to try and refine. We replace a discussion of licensing with one of community structure and our approach to patch acceptance, which is more of what the old licensing discussion was trying to get at without getting into the details of software licensing per se. ... (check-in: 69ec89b591 user: wyoung tags: trunk) | |
2019-07-16
| ||
15:44 | Reduced redundancy in the new feature set size vs ease of use discussion in fossil-v-git. ... (Closed-Leaf check-in: a52e68459f user: wyoung tags: bsd-vs-gpl) | |
15:05 | Rewrote the "Accepting Contributions" section of the fossil-v-git doc to focus on the size of each tool in terms of SLOC and features, rather than on licensing details. ... (check-in: 5fe84e7011 user: wyoung tags: bsd-vs-gpl) | |
2019-07-12
| ||
13:58 | Improved error messages when a commit fails due to a lock conflict: Show the age of the lock in addition to the user. Suggest using the new --override-lock option instead of --allow-fork. Expire locks after any successful check-in from the same check-out. ... (check-in: 3a5caa86db user: drh tags: trunk) | |
13:25 | Merged in Linux vs SQLite stuff from trunk ... (check-in: f5321731f9 user: wyoung tags: bsd-vs-gpl) | |
13:24 | Clarified the scale of the Linux vs SQLite projects in the same-named section of the Git vs Fossil doc, tightened up the discussion a bit, and added hard SLOC stats to ground it all. Most controversially, added the rattle wrench analogy. ... (check-in: 69e7827d26 user: wyoung tags: trunk) | |
12:37 | Fix a typo in the fossil-v-git.wiki document, as reported on the forum. "fossil all status" should be "fossil all changes". ... (check-in: 9b51c42a8b user: drh tags: trunk) | |
Changes to www/fossil-v-git.wiki.
︙ | ︙ | |||
32 33 34 35 36 37 38 39 40 41 42 43 44 45 | <tr><td>File versioning only</td> <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> <tr><td>Ad-hoc pile-of-files key/value database</td> <td>Relational SQL database</td></tr> <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> <tr><td>Designed for Linux kernel development</td> <td>Designed for SQLite development</td></tr> <tr><td>Focus on individual branches</td> <td>Focus on the entire tree of changes</td></tr> <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> <tr><td>One check-out per repository</td> <td>Many check-outs per repository</td></tr> <tr><td>Remembers what you should have done</td> <td>Remembers what you actually did</td></tr> | > > < | | 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 | <tr><td>File versioning only</td> <td>Versioning, Tickets, Wiki, Technotes, Forum</td></tr> <tr><td>Ad-hoc pile-of-files key/value database</td> <td>Relational SQL database</td></tr> <tr><td>Bazaar-style development</td><td>Cathedral-style development</td></tr> <tr><td>Designed for Linux kernel development</td> <td>Designed for SQLite development</td></tr> <tr><td>Many contributors</td> <td>Select contributors</td></tr> <tr><td>Focus on individual branches</td> <td>Focus on the entire tree of changes</td></tr> <tr><td>Lots of little tools</td><td>Stand-alone executable</td></tr> <tr><td>One check-out per repository</td> <td>Many check-outs per repository</td></tr> <tr><td>Remembers what you should have done</td> <td>Remembers what you actually did</td></tr> </table></blockquote> <h3 id="features">2.1 Feature Set</h3> Git provides file versioning services only, whereas Fossil adds integrated [./wikitheory.wiki | wiki], [./bugtheory.wiki | ticketing & bug tracking], [./embeddeddoc.wiki | embedded documentation], [./event.wiki | technical notes], and a [./forum.wiki | forum]. These additional capabilities are available for Git as 3rd-party |
︙ | ︙ | |||
70 71 72 73 74 75 76 | the stand-alone Fossil executable together with a [./server.wiki#cgi|2-line CGI script] suffice to instantiate a full-featured developer website. To accomplish the same using Git requires locating, installing, configuring, integrating, and managing a wide assortment of separate tools. Standing up a developer website using Fossil can be done in minutes, whereas doing the same using Git requires hours or days. | | | 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 | the stand-alone Fossil executable together with a [./server.wiki#cgi|2-line CGI script] suffice to instantiate a full-featured developer website. To accomplish the same using Git requires locating, installing, configuring, integrating, and managing a wide assortment of separate tools. Standing up a developer website using Fossil can be done in minutes, whereas doing the same using Git requires hours or days. <h3 id="database">2.2 Database</h3> The baseline data structures for Fossil and Git are the same, modulo formatting details. Both systems store check-ins as immutable objects referencing their immediate ancestors and named by a cryptographic hash of the check-in content. The difference is that Git stores its objects as individual files |
︙ | ︙ | |||
114 115 116 117 118 119 120 | The ease with which check-ins can be located and queried in Fossil has resulted in a huge variety of reports and status screens ([./webpage-ex.md|examples]) that show project state in ways that help developers maintain enhanced awareness and comprehension and avoid errors. | | > | < < < < < < | < < < < | < < < < < < | < < < < < < < < | < | < | < | | | > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > | > > | > > > | > > > | > > > > > > > > > | > | > > > > > > > | > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > | > > > > > > > > > > > > > > > > | | | > > > > > > > > > > > > > > > > > > | > > > > > > > > > | > > > > > | > > > > > > > > > > > | > > > > | > > > | | | 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 | The ease with which check-ins can be located and queried in Fossil has resulted in a huge variety of reports and status screens ([./webpage-ex.md|examples]) that show project state in ways that help developers maintain enhanced awareness and comprehension and avoid errors. <h3 id="vs-linux">2.3 Linux vs. SQLite</h3> Fossil and Git promote different development styles because each one was specifically designed to support the primary authors' main software development project: [https://en.wikipedia.org/wiki/Linus_Torvalds|Linus Torvalds] designed Git to support development of [https://www.kernel.org/|the Linux kernel], and [https://en.wikipedia.org/wiki/D._Richard_Hipp|D. Richard Hipp] designed Fossil to support the development of [https://sqlite.org/|SQLite]. SQLite is much more widely deployed than the Linux kernel, but for Linux-based systems, the kernel is the more fundamental component. Both projects must rank high on any objective list of "most important FOSS projects," yet these two projects are almost entirely unlike one another. In the following sections, we will explain how three key differences between Linux and SQLite dictated the design of each DVCS's low-friction usage path. When deciding between these two DVCSes, you should ask yourself, "Is my project more like Linux or more like SQLite?" <h4 id="devorg">2.3.1 Development Organization</h4> Eric S. Raymond's seminal essay-turned-book "[https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar|The Cathedral and the Bazaar]" details the two major development organization styles found in [https://en.wikipedia.org/wiki/Free_and_open-source_software|FOSS] projects. As it happens, Linux and SQLite fall on opposite sides of this dichotomy. Differing development organization styles dictate a different design and low-friction usage path in the tools created to support each project. Git promotes the Linux kernel's bazaar development style, in which a loosely-associated mass of developers contribute their work through [https://git-scm.com/book/en/v2/Distributed-Git-Distributed-Workflows#_dictator_and_lieutenants_workflow|a hierarchy of lieutenants] who manage and clean up these contributions for consideration by Linus Torvalds, who has the power to cherrypick individual contributions into his version of the Linux kernel. Git allows an anonymous developer to rebase and push specific locally-named private branches, so that a Git repo clone often isn't really a clone at all: it may have an arbitrary number of differences relative to the repository it originally cloned from. Git encourages siloed development. Select work in a developer's local repository may remain private indefinitely. All of this is exactly what one wants when doing bazaar-style development. Fossil's normal mode of operation differs on every one of these points, with the specific designed-in goal of promoting SQLite's cathedral development model: <ul> <li><p><b>Personal engagement:</b> SQLite's developers know each other by name and work together daily on the project.</p></li> <li><p><b>Trust over hierarchy:</b> Fossil supports developers given direct commit capability on the repository rather than support a hierarchical "dictator and lieutenants" contribution style. D. Richard Hipp rarely overrides decisions made by those he has trusted with commit access on his repositories. [/doc/trunk/www/admin-v-setup.md|Some users] have more power over what they can do with the repository, but Fossil does not otherwise directly support the enforcement of a development organization's social hierarchy. Fossil is a great fit for [https://en.wikipedia.org/wiki/Flat_organization|flat organizations].</p></li> <li><p><b>Anonymous contribution discouraged:</b> Anonymous contribution is possible in a Fossil project, but there is no low-friction path to it, as in Git. Fossil's closest equivalent to Git pull requests is the [/help?cmd=bundle|bundle], which requires higher engagement than firing off a PR. Both Fossil and Git also support <tt>patch(1)</tt> files, but that's a lossy contribution path in both systems.</p></li> <li><p><b>No rebasing:</b> When a remote clone syncs changes up to its parent repository, the changes are sent exactly as they were committed to the local repository. [#history|There is no rebasing mechanism, on purpose.]</p></li> <li><p><b>Sync over push:</b> Explicit pushes are uncommon in Fossil-based projects; the default is to rely on [/help?cmd=autosync|autosync mode] instead, in which each commit normally syncs immediately to its parent repository, so that explicit pushes are not needed.</p></li> <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not purely local labels. They sync along with everything else, so everyone everyone sees the same set of branch names.</p></li> <li><p><b>Private branches are rare:</b> [/doc/trunk/www/private.wiki|Private branches exist in Fossil], but they're normally used to handle rare exception cases, whereas in many Git projects, they're part of the straight-line development process.</p></li> <li><p><b>Identical clones:</b> Fossil's autosync system tries to keep local clones identical to the repository it cloned from.</p></li> </ul> Where Git encourages siloed development, Fossil fights against it. [https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] put it well in his book on software project management, [https://www.amazon.com/dp/0735623198/|Dynamics of Software Development]: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware of a guy in a room]." Fossil places a lot of emphasis on synchronizing everyone's work and on reporting on the state of the project and the work of its developers, so that everyone — especially the project leader — can maintain a better mental picture of what is happening, leading to better situational awareness. Each DVCS can be used in the opposite style, but doing so works against their low-friction paths. <h4 id="scale">2.3.2 Scale</h4> The Linux kernel has a far bigger developer community than that of SQLite: there are thousands and thousands of contributors to Linux, most of whom do not know each others names. These thousands are responsible for producing roughly 89⨉ more code than is in SQLite. (10.7 [https://en.wikipedia.org/wiki/Source_lines_of_code|MLOC] vs. 0.12 MLOC according to [https://dwheeler.com/sloccount/|SLOCCount].) The Linux kernel and its development process were already uncommonly large back in 2005 when Git was designed, specifically to support the consequences of having such a large set of developers working on such a large code base. 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model. As well, we think the fact of Fossil's birth a year later than Git allowed it to learn from some of the key design mistakes in Git. We think you should ask yourself whether you have Linus Torvalds scale software configuration management problems or D. Richard Hipp scale problems when choosing your DVCS. An [https://en.wikipedia.org/wiki/Impact_wrench|automotive air impact wrench] running at 8000 RPM driving an M8 socket-cap bolt at 16 cm/s is not the best way to hang a picture on the living room wall. <h4 id="contrib">2.3.3 Accepting Contributions</h4> As of this writing, Git has received about 4.5⨉ as many commits as Fossil resulting in about 2.5⨉ as many lines of source code. The line count excludes tests and in-tree third-party dependencies. It does not exclude the default GUI for each, since it's integral for Fossil, so we count the size of <tt>gitk</tt> in this. It is obvious that Git is bigger in part because of its first-mover advantage, which resulted in a larger user community, which results in more contributions. But is that the <i>only</i> reason? We believe there are other relevant differences that also play into this which fall out of the "Linux vs. SQLite" framing: licensing, community structure, and how we react to [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by contributions]. In brief, it's harder to get a new feature into Fossil than into Git. A larger feature set size is not necessarily a good thing. Git's command line interface is famously arcane. Masters of the arcane are able to do wizardly things, but only by studying their art deeply for years. This strikes us as a good thing only in cases where use of the tool itself is the primary point of that user's work. Most DVCS users are not using a DVCS for its own sake, so we do not want the DVCS with the most features, we want the one with a more easily internalized behavior set, which we can pick up, use quickly, and then set aside in order to get back to our actual job as quickly as possible. There is some minimal set of features required to achieve that, but there is a level beyond which more features only slow us down while we're learning about the DVCS, as we must plow through documentation on features we're not likely to ever use. When the number of features grows to the point where people of normal motivation cannot spend the time to master them all, you make the tool <i>less</i> productive to use. We achieve this balance between feature set size and ease of use by carefully choosing which users to give commit bits to, then in being choosy about which of the contributed feature branches to merge down to trunk. The end result is that Fossil more closely adheres to [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the principle of least astonishment] than Git does. <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> Both Fossil and Git store history as a directed acyclic graph (DAG) of changes, but Git tends to focus more on individual branches of the DAG, whereas Fossil puts more emphasis on the entire DAG. For example, the default "sync" behavior in Git is to only sync a single branch, whereas with Fossil the only sync option it to |
︙ | ︙ | |||
205 206 207 208 209 210 211 | by every contributor to Linux, as such extreme visibility does not scale well. But Fossil was written for the cathedral-style SQLite project with just a handful of active committers. Seeing all changes on all branches all at once helps keep the whole team up-to-date with what everybody else is doing, resulting in a more tightly focused and cohesive implementation. | > | > | | 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 | by every contributor to Linux, as such extreme visibility does not scale well. But Fossil was written for the cathedral-style SQLite project with just a handful of active committers. Seeing all changes on all branches all at once helps keep the whole team up-to-date with what everybody else is doing, resulting in a more tightly focused and cohesive implementation. <h3 id="executables">2.5 Lots of little tools vs. Self-contained system</h3> Git consists of many small tools, each doing one small part of the job, which can be recombined (by experts) to perform powerful operations. Git has a lot of complexity and many dependencies and requires an "installer" script or program to get it running. Fossil is a single self-contained stand-alone executable with hardly any dependencies. Fossil can be (and often is) run inside a minimally configured chroot jail. To install Fossil, one merely puts the executable somewhere in the $PATH. The designer of Git says that the Unix philosophy is to have lots of small tools that collaborate to get the job done. The designer of Fossil says that the Unix philosophy is "It just works." Both individuals have written their DVCSes to reflect their own view of the "Unix philosophy." <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> A "repository" in Git is a pile-of-files in the ".git" subdirectory of a single check-out. The check-out and the repository are located together in the filesystem. With Fossil, a "repository" is a single SQLite database file that can be stored anywhere. There |
︙ | ︙ | |||
254 255 256 257 258 259 260 | With Fossil, the complete decoupling of repository and check-out tree means every working check-out tree is treated equally. It's common in Fossil to have a check-out tree for each major working branch so that you can switch branches with a "cd" command rather than replace the current working file set with a different file set by updating in place, as Git prefers. | > | < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < < | > | | 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 | With Fossil, the complete decoupling of repository and check-out tree means every working check-out tree is treated equally. It's common in Fossil to have a check-out tree for each major working branch so that you can switch branches with a "cd" command rather than replace the current working file set with a different file set by updating in place, as Git prefers. <h3 id="history">2.7 What you should have done vs. What you actually did</h3> Git puts a lot of emphasis on maintaining a "clean" check-in history. Extraneous and experimental branches by individual developers often never make it into the main repository. And branches are often rebased before being pushed, to make it appear as if development had been linear. Git strives to record what the development of a project should have looked like had there been no mistakes. Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. One might argue that this makes the history of a Fossil project "messy." But another point of view is that this makes the history "accurate." In actual practice, the superior reporting tools available in Fossil mean that the added "mess" is not a factor. One commentator has mused that Git records history according to the victors, whereas Fossil records history as it actually happened. <h2 id="missing">3.0 Missing Features</h2> Most of the capabilities found in Git are also available in Fossil and the other way around. For example, both systems have local check-outs, remote repositories, push/pull/sync, bisect capabilities, and a "stash." Both systems store project history as a directed acyclic graph (DAG) of immutable check-in objects. But there are a few capabilities in one system that are missing from the other. <h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3> * <b>The ability to show descendents of a check-in.</b> Both Git and Fossil can easily find the ancestors of a check-in. But only Fossil shows the descendents. (It is possible to find the descendents of a check-in in Git using the log, but that is sufficiently difficult that nobody ever actually does it.) |
︙ | ︙ | |||
362 363 364 365 366 367 368 | * <b>The [/help?cmd=ui|fossil ui] command</b> Fossil supports an integrated web interface. Some of the same features are available using third-party add-ons for Git, but they do not provide nearly as many features and they are not nearly as convenient to use. | | | 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 | * <b>The [/help?cmd=ui|fossil ui] command</b> Fossil supports an integrated web interface. Some of the same features are available using third-party add-ons for Git, but they do not provide nearly as many features and they are not nearly as convenient to use. <h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3> * <b>Rebase</b> Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it is not something that can be done with |
︙ | ︙ |