From 4f49b16079b27d7ce633619e4cddfdf2bffbc952 Mon Sep 17 00:00:00 2001 From: cashmere Date: Fri, 4 Sep 2026 09:05:24 +0200 Subject: initial commit --- www/qandc.wiki | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 154 insertions(+) create mode 100644 www/qandc.wiki (limited to 'www/qandc.wiki') diff --git a/www/qandc.wiki b/www/qandc.wiki new file mode 100644 index 0000000..ace5108 --- /dev/null +++ b/www/qandc.wiki @@ -0,0 +1,154 @@ +Questions And Criticisms + +This page is a collection of real questions and criticisms that were +raised against Fossil early in its history (circa 2008). +This page is old and has not been kept up-to-date. See the +[/finfo?name=www/qandc.wiki|change history of this page]. + +Fossil sounds like a lot of reinvention of the wheel. +Why create your own DVCS when you could have reused mercurial? + +
+ I wrote fossil because none of the + other available DVCSes met my needs. If the other DVCSes do + meet your needs, then you might not need fossil. But they + don't meet mine, and so fossil is necessary for me. + + Features provided by fossil that one does not get with other + DVCSes include: + +
    +
  1. Integrated wiki.
  2. +
  3. Integrated bug tracking
  4. +
  5. Immutable artifacts
  6. +
  7. Self-contained, stand-alone executable that can be run in + a chroot jail
  8. +
  9. Simple, well-defined, + enduring file format
  10. +
  11. Integrated web interface
  12. +
+
+ +Why should I use this rather than Trac? + +
+
    +
  1. Fossil is distributed. You can view and/or edit tickets, wiki, and + code while off network, then sync your changes later. With Trac, you + can only view and edit tickets and wiki while you are connected to + the server.
  2. +
  3. Fossil is lightweight and fully self-contained. It is very easy + to setup on a low-resource machine. Fossil does not require an + administrator.
  4. +
  5. Fossil integrates code versioning into the same repository with + wiki and tickets. There is nothing extra to add or install. + Fossil is an all-in-one turnkey solution.
  6. +
+
+ +Love the concept here. Anyone using this for real work yet? + +
+Fossil is self-hosting. +In fact, this page was probably delivered +to your web-browser via a working fossil instance. The same virtual +machine that hosts https://fossil-scm.org/ +(a Linode 720) +also hosts 24 other fossil repositories for various small projects. +The documentation files for +SQLite are hosted in a +fossil repository here, +for example. +Other projects are also adopting fossil. But fossil does not yet have +the massive user base of git or mercurial. +
+ +Fossil looks like the bug tracker that would be in your +Linksys Router's administration screen. + +
+I take a pragmatic approach to software: form follows function. +To me, it is more important to have a reliable, fast, efficient, +enduring, and simple DVCS than one that looks pretty. + +On the other hand, if you have patches that improve the appearance +of Fossil without seriously compromising its reliability, performance, +and/or maintainability, I will be happy to accept them. Fossil is +self-hosting. Send email to request a password that will let +you push to the main fossil repository. +
+ +It would be useful to have a separate application that +keeps the bug-tracking database in a versioned file. That file can +then be pushed and pulled along with the rest repository. + +
+Fossil already does push and pull bugs along with the files +in your repository. +But fossil does not track bugs as files in the source tree. +That approach to bug tracking was rejected for three reasons: + +
    +
  1. Check-ins in fossil are immutable. So if + tickets were part of the check-in, then there would be no way to add + new tickets to a check-in as new bugs are discovered. + +
  2. Any project of reasonable size and complexity will generate thousands + and thousands of tickets, and we do not want all those ticket files + cluttering the source tree. + +
  3. We want tickets to be managed from the web interface and to have a + permission system that is distinct from check-in permissions. + In other words, we do not want to restrict the creation and editing + of tickets to developers with check-in privileges and an installed + copy of the fossil executable. Casual passers-by on the internet should + be permitted to create tickets. +
+ +These points are reiterated in the opening paragraphs of +the Bug-Tracking In Fossil document. +
+ +Fossil is already the name of a plan9 versioned +append-only filesystem. + +
+I did not know that. Perhaps they selected the name for the same reason that +I did: because a repository with immutable artifacts preserves +an excellent fossil record of a long-running project. +
+ +The idea of storing a repository in a binary blob like an +SQLite database terrifies me. + +
+The use of SQLite to store the database is likely more stable and secure +than any other approach, due to the fact that SQLite is transactional. +Fossil also implements several internal +self-checks to insure that no information +is ever lost. +
+ + +I am dubious of the benefits of including wikis and bug trackers +directly in the VCS - either they are under-featured compared to full +software like Trac, or the VCS is massively bloated compared to +Subversion or Bazaar. + +
+I have no doubt that Trac has many features that fossil lacks. But that +is not the point. Fossil has several key features that Trac lacks and that +I need: most notably the fact that +fossil supports disconnected operation. + +As for bloat: Fossil is a single self-contained executable. +You do not need any other packages +(diff, patch, merge, cvs, svn, rcs, git, python, perl, tcl, apache, +SQLite, and so forth) +in order to run fossil. Fossil runs just fine in a chroot jail all +by itself. And the self-contained fossil +executable is much less than 1MB in size. (Update 2015-01-12: Fossil has +grown in the years since the previous sentence was written but is still +much less than 2MB according to "size" when compiled using -Os on x64 Linux.) +Fossil is the very opposite of bloat. +
-- cgit v1.3.1