1 files changed, 154 insertions, 0 deletions
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 @@
+<title>Questions And Criticisms</title>
+
+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].
+
+<b>Fossil sounds like a lot of reinvention of the wheel.
+Why create your own DVCS when you could have reused mercurial?</b>
+
+<div class="indent">
+  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:
+
+  <ol>
+  <li> Integrated <a href="wikitheory.wiki">wiki</a>. </li>
+  <li> Integrated <a href="bugtheory.wiki">bug tracking</a> </li>
+  <li> Immutable artifacts </li>
+  <li> Self-contained, stand-alone executable that can be run in
+       a <a href="http://en.wikipedia.org/wiki/Chroot">chroot jail</a> </li>
+  <li> Simple, well-defined,
+       <a href="fileformat.wiki">enduring file format</a> </li>
+  <li> Integrated <a href="webui.wiki">web interface</a> </li>
+  </ol>
+</div>
+
+<b>Why should I use this rather than Trac?</b>
+
+<div class="indent">
+  <ol>
+  <li> 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. </li>
+  <li> Fossil is lightweight and fully self-contained.  It is very easy
+       to setup on a low-resource machine. Fossil does not require an
+       administrator.</li>
+  <li> 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. </li>
+  </ol>
+</div>
+
+<b>Love the concept here. Anyone using this for real work yet?</b>
+
+<div class="indent">
+Fossil is <a href="https://fossil-scm.org/">self-hosting</a>.
+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 <a href="http://www.linode.com/">Linode 720</a>)
+also hosts 24 other fossil repositories for various small projects.
+The documentation files for
+<a href="http://www.sqlite.org/">SQLite</a> are hosted in a
+fossil repository <a href="http://www.sqlite.org/docsrc/">here</a>,
+for example.
+Other projects are also adopting fossil.  But fossil does not yet have
+the massive user base of git or mercurial.
+</div>
+
+<b>Fossil looks like the bug tracker that would be in your
+Linksys Router's administration screen.</b>
+
+<div class="indent">
+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.
+</div>
+
+<b>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.</b>
+
+<div class="indent">
+Fossil already <u>does</u> push and pull bugs along with the files
+in your repository.
+But fossil does <u>not</u> track bugs as files in the source tree.
+That approach to bug tracking was rejected for three reasons:
+
+<ol>
+<li>  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.
+
+<li>  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.
+
+<li>  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.
+</ol>
+
+These points are reiterated in the opening paragraphs of
+the <a href="bugtheory.wiki">Bug-Tracking In Fossil</a> document.
+</div>
+
+<b>Fossil is already the name of a plan9 versioned
+append-only filesystem.</b>
+
+<div class="indent">
+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.
+</div>
+
+<b>The idea of storing a repository in a binary blob like an
+SQLite database terrifies me.</b>
+
+<div class="indent">
+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
+<a href="selfcheck.wiki">self-checks</a> to insure that no information
+is ever lost.
+</div>
+
+
+<b>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.</b>
+
+<div class="indent">
+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.
+</div>