Fossil

 *
 * BEWARE: Fossil's MD and wiki to HTML processors wrap the content bodies
 * differently, and /doc on *.html files works yet a third way.  These
 * rules are carefully written to capture these docs and no other use of
 * MD/wiki/HTML.  Adjust with care!
 */

.markdown blockquote, .sidebar, p.blockquote {
  /* Style it as a proper blockquote for MD only.  Unlike the indent
   * rule, this applies everywhere, including the forum, tickets… */
  background-color: rgba(65, 131, 196, 0.1);
  border-left: 3px solid #4183c4;
  padding: 0.1em 1em;
}
.sidebar {
  float: right;
  font-size: 0.9em;
  max-width: 33%;
}
div.sidebar {
  margin-left: 1em; /* don't run wraparound text right up to our border */
  padding: 1em;     /* no p wrapper inside to get extra padding from */
}
div.sidebar:not(.no-label):before {
  content: "Sidebar: ";
  font-weight: bold;
}

.doc > .content dd, .content dt,
.doc > .content div,
.doc > .content li,
.doc > .content p,
.doc > .content table
{
  line-height: 1.4em;
}

   * paragraphs within tables, etc.  What this actually *says* is far
   * simpler than it looks; the equivalent SCSS is merely:
   *
   * .artifact, .dir, .doc {
   *   > .content,                // wiki docs have no inner container
   *   > .content > .fossil-doc,  // container for HTML embedded docs
   *   > .content > markdown {    // ditto for MD outside forum, tickets…
   *     > div, > p, > ol, > ul, > table {
   *       margin-left: 50pt; margin-right: 50pt;
   *     }
   *   }
   * }
   * 
   * Generated by Inskinerator; see its override/modern/media.scss file. */
  .artifact > .content > p,

    margin-right: 50pt;
  }
  div.pikchr-wrapper.center:not(.source) {
    margin-left: 0;
  }

  /* Special treatment for backward compatibility. */
  .indent,                /* clean alternative to misusing <blockquote> */
  .artifact > .content > blockquote:not(.file-content),
  .dir      > .content > blockquote,
  .doc      > .content > blockquote {
    /* We must apply extra indent relative to "p" since Fossil's wiki
     * generator misuses the blockquote tag against HTML and MD norms
     * to mean "indented paragraph."  Skip it for file content retrieved
     * by /dir URLs. */
    margin-left: 80pt;
  }
  .artifact > .content > .markdown > blockquote,
  .dir      > .content > .markdown > blockquote,
  .doc      > .content > .markdown > blockquote {
    /* Fossil MD didn't inherit that bug; its HTML generator emits
     * blockquote tags only for _block quotes_!  A moderate indent
     * suffices due to the visual styling applied above. */
    margin-left: 60pt;
  }

  /* Alternative to BLOCK.indent when wrapped in something that is
   * itself indented.  The value is the delta between p and blockquote
   * above, expressed as padding instead of margin so it adds to the
   * outer margin instead of forcing the browser into picking one. */
  .local-indent {
    padding-left: 30pt;
  }
}

[https://emscripten.org/docs/getting_started/downloads.html]

For instructions on keeping the SDK up to date, see:

[https://emscripten.org/docs/tools_reference/emsdk.html]

<div class="sidebar">Getting Emscripten up and running is trivial and
painless, at least on Linux systems, but the installer downloads
many hundreds of megabytes of tools and dependencies, all of which
will be installed under the single SDK directory (as opposed to
being installed at the system level). It does, however, require
that python3 be installed at the system level and it can
optionally make use of a system-level cmake for certain tasks
unrelated to how fossil uses the SDK.</div>

After installing the SDK, configure the fossil tree with emsdk
support:

<pre><code>$ ./configure --with-emsdk=/path/to/emsdk \
  --and-other-options...
</code></pre>

If the <tt>--with-emsdk</tt> flag is not provided, the configure
script will check for the environment variable <tt>EMSDK</tt>, which
is one of the standard variables the SDK environment uses. If that
variable is found, its value will implicitly be used in place of the
missing <tt>--with-emsdk</tt> flag. Thus, if the <tt>emsdk_env.sh</tt>

build cycle. They are instead explicitly built as described below.

From the top of the source tree, all WASM-related components can be
built with:

<pre><code>$ make wasm</code></pre>

<div class="sidebar">The file
<tt>[/file/extsrc/pikcher-worker.js|extsrc/pikcher-worker.js]</tt>
is hand-coded and intended to be loaded as a "Worker" in
JavaScript. That file loads the main module and provides an
interface via which a main JavaScript thread can communicate with
pikchr running in a Worker thread. The file
<tt>[/file/src/fossil.page.pikchrshowasm.js|src/fossil.page.pikchrshowasm.js]</tt>
implements the [/pikchrshow] app and demonstrates how
<tt>pikchr-worker.js</tt> is used.</div>

As of this writing, those parts include:

   *  <tt>extsrc/pikchr.wasm</tt> is a WASM-compiled form of
      <tt>extsrc/pikchr.c</tt>.
   *  <tt>extsrc/pikchr.js</tt> is JS/WASM glue code generated by Emscripten
      to give JS code access to the API exported by the WASM file.











When a new version of <tt>extsrc/pikchr.c</tt> is installed, the
files <tt>pikchr.{js,wasm}</tt> will need to be recompiled to account
for that. Running <tt>make wasm</tt> will, if the build is set up for
the emsdk, recompile those:

<pre><code>$ make wasm
./tools/emcc.sh -o extsrc/pikchr.js ...
$ ls -la extsrc/pikchr.{js,wasm}
-rw-rw-r-- 1 stephan stephan 17263 Jun  8 03:59 extsrc/pikchr.js
-rw-rw-r-- 1 stephan stephan 97578 Jun  8 03:59 extsrc/pikchr.wasm
</code></pre>

<div class="sidebar">If that fails with a message along the lines of

“<code>setting `EXPORTED_RUNTIME_METHODS` expects `<class 'list'>` but

got `<class 'str'>`</code>” then the emcc being invoked is too old: emcc
changed the format of list-type arguments at some point.  The required
minimum version is unknown, but any SDK version from May 2022 or later
"should" (as of this writing) suffice. Any older version may or may not
work.</div>

After that succeeds, we need to run the normal build so that those
generated files can be compiled in to the fossil binary, accessible
via the [/help?cmd=/builtin|/builtin page]:

<pre><code>$ make</code></pre>

well as information such as parent check-ins, the username of the
programmer who created the check-in, the date and time when
the check-in was created, and any check-in comments associated
with the check-in.

Allowed cards in the manifest are as follows:

<p class="indent">
<b>B</b> <i>baseline-manifest</i><br>
<b>C</b> <i>checkin-comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br>
<b>F</b> <i>filename</i> ?<i>hash</i>? ?<i>permissions</i>? ?<i>old-name</i>?<br>
<b>N</b> <i>mimetype</i><br>
<b>P</b> <i>artifact-hash</i>+<br>
<b>Q</b> (<b>+</b>|<b>-</b>)<i>artifact-hash</i> ?<i>artifact-hash</i>?<br>
<b>R</b> <i>repository-checksum</i><br>
<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <b>*</b> ?<i>value</i>?<br>
<b>U</b> <i>user-login</i><br>
<b>Z</b> <i>manifest-checksum</i>
</p>

A manifest may optionally have a single <b>B</b> card.  The <b>B</b> card specifies
another manifest that serves as the "baseline" for this manifest.  A
manifest that has a <b>B</b> card is called a delta-manifest and a manifest
that omits the <b>B</b> card is a baseline-manifest.  The other manifest
identified by the argument of the <b>B</b> card must be a baseline-manifest.
A baseline-manifest records the complete contents of a check-in.

in the comment.

A manifest must have exactly one <b>D</b> card.  The sole argument to
the <b>D</b> card is a date-time stamp in the ISO8601 format.  The
date and time should be in coordinated universal time (UTC).
The format one of:

<p class="indent">
<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><br>
<i>YYYY</i><b>-</b><i>MM</i><b>-</b><i>DD</i><b>T</b><i>HH</i><b>:</b><i>MM</i><b>:</b><i>SS</i><b>.</b><i>SSS</i>
</p>

A manifest has zero or more <b>F</b> cards.  Each <b>F</b> card identifies a file
that is part of the check-in.  There are one, two, three, or four
arguments.  The first argument is the pathname of the file in the
check-in relative to the root of the project file hierarchy.  No ".."
or "." directories are allowed within the filename.  Space characters
are escaped as in <b>C</b> card comment text.  Backslash characters and

Clusters are used during repository synchronization to help
reduce network traffic.  As such, clusters are an optimization and
may be removed from a repository without loss or damage to the
underlying project code.

Allowed cards in the cluster are as follows:

<p class="indent">
<b>M</b> <i>artifact-id</i><br />
<b>Z</b> <i>checksum</i>
</p>

A cluster contains one or more <b>M</b> cards followed by a single <b>Z</b> card.
Each <b>M</b> card has a single argument which is the artifact ID of
another artifact in the repository.  The <b>Z</b> card works exactly like
the <b>Z</b> card of a manifest.  The argument to the <b>Z</b> card is the
lower-case hexadecimal representation of the MD5 checksum of all
prior cards in the cluster.  The <b>Z</b> card is required.

An example cluster from Fossil can be seen
[/artifact/d03dbdd73a2a8 | here].

<h3 id="ctrl">2.3 Control Artifacts</h3>

Control artifacts are used to assign properties to other artifacts
within the repository.
Allowed cards in a control artifact are as follows:

<p class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>T</b> (<b>+</b>|<b>-</b>|<b>*</b>)<i>tag-name</i> <i>artifact-id</i> ?<i>value</i>?<br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i><br />
</p>

A control artifact must have one <b>D</b> card, one <b>U</b> card, one <b>Z</b> card and
one or more <b>T</b> cards.  No other cards or other text is
allowed in a control artifact.  Control artifacts might be PGP
clearsigned.

The <b>D</b> card and the <b>Z</b> card of a control artifact are the same

<h3 id="wikichng">2.4 Wiki Pages</h3>

A wiki artifact defines a single version of a
single wiki page.
Wiki artifacts accept
the following card types:

<p class="indent">
<b>C</b> <i>change-comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>L</b> <i>wiki-title</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i>+<br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>D</b> card is the date and time when the wiki page was edited.
The <b>P</b> card specifies the parent wiki pages, if any.  The <b>L</b> card
gives the name of the wiki page.  The optional <b>N</b> card specifies
the mimetype of the wiki text.  If the <b>N</b> card is omitted, the
mimetype is assumed to be text/x-fossil-wiki.
The <b>U</b> card specifies the login

[/artifact?name=7b2f5fd0e0&txt=1 | here].

<h3 id="tktchng">2.5 Ticket Changes</h3>

A ticket-change artifact represents a change to a trouble ticket.
The following cards are allowed on a ticket change artifact:

<p class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>J</b> ?<b>+</b>?<i>name</i> ?<i>value</i>?<br />
<b>K</b> <i>ticket-id</i><br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>D</b> card is the usual date and time stamp and represents the point
in time when the change was entered.  The <b>U</b> card is the login of the
programmer who entered this change.  The <b>Z</b> card is the required checksum over
the entire artifact.

Every ticket has a distinct ticket-id:

An attachment artifact associates some other artifact that is the
attachment (the source artifact) with a ticket or wiki page or
technical note to which
the attachment is connected (the target artifact).
The following cards are allowed on an attachment artifact:

<p class="indent">
<b>A</b> <i>filename target</i> ?<i>source</i>?<br />
<b>C</b> <i>comment</i><br />
<b>D</b> <i>time-and-date-stamp</i><br />
<b>N</b> <i>mimetype</i><br />
<b>U</b> <i>user-name</i><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>A</b> card specifies a filename for the attachment in its first argument.
The second argument to the <b>A</b> card is the name of the wiki page or
ticket or technical note to which the attachment is connected.  The
third argument is either missing or else it is the lower-case artifact
ID of the attachment itself.  A missing third argument means that the
attachment should be deleted.

A technical note or "technote" artifact (formerly known as an "event" artifact)
associates a timeline comment and a page of text
(similar to a wiki page) with a point in time.  Technotes can be used
to record project milestones, release notes, blog entries, process
checkpoints, or news articles.
The following cards are allowed on an technote artifact:

<p class="indent">
<b>C</b> <i>comment</i><br>
<b>D</b> <i>time-and-date-stamp</i><br />
<b>E</b> <i>technote-time</i> <i>technote-id</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i>+<br />
<b>T</b> <b>+</b><i>tag-name</i> <b>*</b> ?<i>value</i>?<br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</p>

The <b>C</b> card contains text that is displayed on the timeline for the
technote.  The <b>C</b> card is optional, but there can only be one.

A single <b>D</b> card is required to give the date and time when the
technote artifact was created.  This is different from the time at which
the technote appears on the timeline.

<h3 id="forum">2.8 Forum Posts</h3>

Forum posts are intended as a mechanism for users and developers to
discuss a project.  Forum posts are like messages on a mailing list.

The following cards are allowed on an forum post artifact:

<p class="indent">
<b>D</b> <i>time-and-date-stamp</i><br />
<b>G</b> <i>thread-root</i><br />
<b>H</b> <i>thread-title</i><br />
<b>I</b> <i>in-reply-to</i><br />
<b>N</b> <i>mimetype</i><br />
<b>P</b> <i>parent-artifact-id</i><br />
<b>U</b> <i>user-name</i><br />
<b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br />
<b>Z</b> <i>checksum</i>
</p>

Every forum post must have either one <b>I</b> card and one <b>G</b> card
or one <b>H</b> card.
Forum posts are organized into topic threads.  The initial
post for a thread (the root post) has an <b>H</b> card giving the title or
subject for that thread.  The argument to the <b>H</b> card is a string
in the same format as a comment string in a <b>C</b> card.

wrong order.

Both bugs have now been fixed.  However, to prevent historical
Technical Note artifacts that were inserted by users in good faith
from being rejected by newer Fossil builds, the card ordering
requirement is relaxed slightly.  The actual implementation is this:

<p class=blockquote>
"All cards must be in strict lexicographic order, except that the
N and P cards of a Technical Note artifact are allowed to be
interchanged."
</p>

Future versions of Fossil might strengthen this slightly to only allow
the out of order N and P cards for Technical Notes entered before
a certain date.

<h3>4.2 R-Card Hash Calculation</h3>

set your account name and password, and grant your account all access
privileges. (I also like to grant Clone access to the anonymous user,
but that's personal preference.)

Once you are done, kill the fossil server (with Ctrl-C or equivalent)
and close the browser window.

<div class="sidebar">
It is not strictly required to configure a repository
this way, but if you are going to share a repo over the net then it
is highly recommended. If you are only going to work with the repo
locally, you can skip the configuration step and do it later if
you decide you want to share your repo.
</div>

The next thing we need to do is <em>open</em> the repository. To do so
we create a working directory and then <tt>cd</tt> to it:

<verbatim>
stephan@ludo:~/fossil$ mkdir demo
stephan@ludo:~/fossil$ cd demo

<title>Private Branches</title>

By default, everything you check into a Fossil repository is shared
to all clones of that repository.  In Fossil, you don't push and pull
individual branches; you push and pull everything all at once.

But sometimes users want to keep some private work that is not
shared with others.  This might be a preliminary or experimental change
that needs further refinement before it is shared and which might never
be shared at all.  To do this in Fossil, simply commit the change with
the --private command-line option:

<pre>
fossil commit --private
</pre>

The --private option causes Fossil to put the check-in in a new branch
named "private".  That branch will not participate in subsequent clone,
sync, push, or pull operations.  The branch will remain on the one local
repository where it was created.  Note that you only use the --private
option for the first check-in that creates the private branch.
Additional checkins into the private branch remain private automatically.

<h2>Publishing Private Changes</h2>

After additional work, one might desire to publish the changes associated
with a private branch.  The usual way to do this is to merge those
changes into a public branch.  For example:

<pre>
fossil update trunk
fossil merge private
fossil commit
</pre>

The private branch remains private and is not recorded as a parent
in the merge manifest's P-card, but all of the changes associated with
the private branch are now folded into the public branch and are hence
visible to other users of the project.

A private branch created with Fossil version 1.30 or newer can also be
converted into a public branch using the <code>fossil publish</code>
command.  However, there is no way to convert a private branch created with
older versions of Fossil into a public branch.

<div class="sidebar">
To avoid generating a missing artifact
reference on peer repositories without the private branch, the merge parent
is not recorded when merging the private branch into a public branch.  As a
consequence, the web UI timeline does not draw a merge line from the private
merge parent to the public merge child.  Moreover, repeat private-to-public
merge operations (without the [/help?cmd=merge | --force option]) with files
added on the private branch may only work once, but later abort with
"WARNING: no common ancestor for FILE", as the parent-child relationship is
not recorded. (See the [/doc/trunk/www/branching.wiki | Branching, Forking,
Merging, and Tagging] document for more information.)
</div>

The <code>--integrate</code> option of <code>fossil merge</code> (to close
the merged branch when committing) is ignored for a private branch -- or the
check-in manifest of the resulting merge child would include a
<code>+close</code> tag referring to the leaf check-in on the private branch,
and generate a missing artifact reference on repository clones without that
private branch.  It's still possible to close the leaf of the private branch
(after committing the merge child) with the <code>fossil amend --close</code>
command.














<h2>Syncing Private Branches</h2>

A private branch normally stays on the one repository where it was
originally created.  But sometimes you want to share private branches
with another repository.  For example, you might be building a cross-platform
application and have separate repositories on your Windows laptop,
your Linux desktop, and your iMac.  You can transfer private branches
between these machines by using the --private option on the "sync",
"push", "pull", and "clone" commands.  For example, if you are running
"fossil server" on your Linux box and you want to clone that repository
to your Mac, including all private branches, use:

<verbatim>
fossil clone --private http://user@linux.localnetwork:8080/ mac-clone.fossil
</verbatim>

You'll have to supply a username and password in order for this to work.
Fossil will not clone (or sync) private branches anonymously.

By default, there are no users that can do private branch syncing.  You
will have to give a user
the "Private" capability ("x") if you want them to be able to do this.

again, this restriction is designed to make it hard to accidentally
push private branches beyond their intended audience.

<h2>Purging Private Branches</h2>

You can remove all private branches from a repository using this command:

<pre>
fossil scrub --private
</pre>

Note that the above is a permanent and irreversible change.  You will
be asked to confirm before continuing.  Once the private branches are
removed, they cannot be retrieved (unless you have synced them to another
repository.)  So be careful with the command.

<h2>Additional Notes</h2>

All of the features above apply to <u>all</u> private branches in a
single repository at once.  There is no mechanism in Fossil (currently)
that allows you to push, pull, clone, sync, or scrub an individual
private branch within a repository that contains multiple private
branches.

<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

      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>

<title>Reviews</title>
<b>External links:</b>

  *  [https://www.nixtu.info/2010/03/fossil-dvcs-on-go-first-impressions.html |
     Fossil DVCS on the Go - First Impressions]

<b>See Also:</b>

  *  [./quotes.wiki | Short Quotes on Fossil, Git, And DVCSes]

<b>Daniel writes on 2009-01-06:</b>

<div class="indent">
The reasons I use fossil are that it's the only version control I
have found that I can get working through the VERY annoying MS
firewalls at work.. (albeit through an ntlm proxy) and I just love
single .exe applications!
</div>


<b>Joshua Paine on 2010-10-22:</b>

<div class="indent">
With one of my several hats on, I'm in a small team using git. Another
team member just checked some stuff into trunk that should have been on
a branch. Nothing else had happened since, so in fossil I would have
just edited that commit and put it on a new branch. In git that can't
actually be done without danger once other people have pulled, so I had
to create a new commit rolling back the changes, then branch and cherry
pick the earlier changes, then figure out how to make my new branch
shared instead of private. Just want to say thanks for fossil making my
life easier on most of my projects, and being able to move commits to
another branch after the fact and shared-by-default branches are good
features. Also not having a misanthropic command line interface.
</div>

<b>Stephan Beal writes on 2009-01-11:</b>

<div class="indent">
Sometime in late 2007 I came across a link to fossil on
<a href="http://www.sqlite.org/">sqlite.org</a>. It
was a good thing I bookmarked it, because I was never able to find the
link again (it might have been in a bug report or something). The
reasons I first took a close look at it were (A) it stemmed from the
sqlite project, which I've held in high regards for years (e.g. I
wrote JavaScript bindings for it:

I remember my first reaction to fossil being, "this will be an
excellent solution for small projects (like the dozens we've all got
sitting on our hard drives but which don't justify the hassle of
version control)." A year of daily use in over 15 source trees has
confirmed that, and I continue to heartily recommend fossil to other
developers I know who also have their own collection of "unhosted" pet
projects.
</div>

As an example of how useful this web interface can be,
the entire [./index.wiki | Fossil website],
including the document you are now reading,
is rendered using the Fossil web interface, with no enhancements,
and little customization.

<p class="indent">
<b>Key point:</b> <i>The Fossil website is just a running instance
of Fossil!
</p>

Note also that because Fossil is a distributed system, you can run
the web interface on your local machine while off network (for example,
while on an airplane) including
making changes to wiki pages and/or trouble ticket, then synchronize with your
co-workers after you reconnect.  When you clone a Fossil repository, you
don't just get the project source code, you get the entire project
management website.

<h2>Very Simple Startup</h2>

To start using the built-in Fossil web interface on an existing Fossil
repository, simply type this:

<pre>fossil ui existing-repository.fossil</pre>

Substitute the name of your repository, of course.
The "ui" command will start a web server running (it figures out an
available TCP port to use on its own) and then automatically launches
your web browser to point at that server.  If you run the "ui" command
from within an open check-out, you can omit the repository name:

<pre>fossil ui</pre>

The latter case is a very useful short-cut when you are working on a
Fossil project and you want to quickly do some work with the web interface.
Notice that Fossil automatically finds an unused TCP port to run the
server on and automatically points your web browser to the correct
URL.  So there is never any fumbling around trying to find an open
port or to type arcane strings into your browser URL entry box.

available to a distributed team by simply copying the single
repository file up to a web server that supports CGI or SCGI.  To
run Fossil as CGI, just put the
<b>sample-project.fossil</b> file in a directory where CGI scripts
have both read and write permission on the file and the directory that
contains the file, then add a CGI script that looks something like this:


<verbatim>  #!/usr/local/bin/fossil
  repository: /home/www/sample-project.fossil</verbatim>


Adjust the script above so that the paths are correct for your system,
of course, and also make sure the Fossil binary is installed on the server.
But that is <u>all</u> you have to do.  You now have everything you need to host
a distributed software development project in less than five minutes using a
two-line CGI script.

Instructions for setting up an SCGI server are
[./scgi.wiki | available separately].

You don't have a CGI- or SCGI-capable web server running on your
server machine?
Not a problem.  The Fossil interface can also be launched via inetd or
xinetd.  An inetd configuration line sufficient to launch the Fossil
web interface looks like this:


<verbatim>  80 stream tcp nowait.1000 root /usr/local/bin/fossil \
  /usr/local/bin/fossil http /home/www/sample-project.fossil</verbatim>


As always, you'll want to adjust the pathnames to whatever is appropriate
for your system.  The xinetd setup uses a different syntax but follows
the same idea.