Fossil

<title>How The Fossil Download Page Works</title>
<h1 align="center">How The Download Page Works</h1>

<h2>1.0 Overview</h2>

The [/uv/download.html|Download] page for the Fossil self-hosting
repository is implemented using [./unvers.wiki|unversioned files].
The "download.html" screen itself, and the various build products
are all stored as unversioned content.  The download.html page

<title>Fossil Concepts</title>
<h1 align="center">Fossil Concepts</h1>

<h2>1.0 Introduction</h2>

[./index.wiki | Fossil] is a
[http://en.wikipedia.org/wiki/Software_configuration_management | software configuration management] system.
Fossil is software that is designed to control and track the
development of a software project and to record the history

<title>Project Documentation</title>
<h1 align="center">Project Documentation</h1>

Fossil provides a built-in <a href="wikitheory.wiki">wiki</a>
that can be used to store the
documentation for a project.  This is sufficient for many projects.
If your project is well-served by wiki documentation, then you
need read no further.

<title>Fossil FAQ</title>
<h1 align="center">Frequently Asked Questions</h1>

Note: See also <a href="qandc.wiki">Questions and Criticisms</a>.

<ol>
<li><a href="#q1">What GUIs are available for fossil?</a></li>
<li><a href="#q2">What is the difference between a "branch" and a "fork"?</a></li>
<li><a href="#q3">How do I create a new branch?</a></li>

<title>Fossil File Formats</title>
<h1 align="center">
Fossil File Formats
</h1>

The global state of a fossil repository is kept simple so that it can
endure in useful form for decades or centuries.
A fossil repository is intended to be readable,
searchable, and extensible by people not yet born.

The global state of a fossil repository is an unordered

<title>Fossil Password Management</title>
<h1 align="center">Password Management</h1>

Fossil handles user authentication using passwords.
Passwords are unique to each repository.  Passwords are not part of the
persistent state of a project.  Passwords are not versioned and
are not transmitted from one repository to another during a sync.
Passwords are local configuration information that can (and usually does)
vary from one repository to the next within the same project.

<title>Principles Of Operation</title>
<h1 align="center">Principles Of Operation</h1>

This page attempts to define the foundational principals upon
which Fossil is built.

  *  A project consists of source files, wiki pages, and
     trouble tickets, and control files (collectively "artifacts").
     All historical copies of all artifacts

<title>Questions And Criticisms</title>
<nowiki>
<h1 align="center">Questions And Criticisms</h1>

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
</nowiki>[/finfo?name=www/qandc.wiki|change history of this page]<nowiki>.

<b>Fossil sounds like a lot of reinvention of the wheel.

<title>Fossil Quick Start Guide</title>
<h1 align="center">Fossil Quick Start</h1>

This is a guide to help you get started using the Fossil [https://en.wikipedia.org/wiki/Distributed_version_control|Distributed Version Control System] quickly
and painlessly.

<h2 id="install">Installing</h2>

Fossil is a single self-contained C program.  You need to

<title>Fossil Repository Integrity Self-Checks</title>

<h1 align="center">Fossil Repository Integrity Self-Checks</h1>

Fossil is designed with features to give it a high level
of integrity so that users can have confidence that content will
never be mangled or lost by Fossil.
This note describes the defensive measures that
Fossil uses to help prevent information loss due to bugs.

Fossil has been hosting itself and many other projects for

<title>Fossil Performance</title>
<h1 align="center">Performance Statistics</h1>

The questions will inevitably arise:  How does Fossil perform?
Does it use a lot of disk space or bandwidth?  Is it scalable?

In an attempt to answers these questions, this report looks at several
projects that use fossil for configuration management and examines how
well they are working.  The following table is a summary of the results.

<title>Thoughts On The Design Of The Fossil DVCS</title>
<h1 align="center">Thoughts On The Design Of The Fossil DVCS</h1>

Two questions (or criticisms) that arise frequently regarding Fossil
can be summarized as follows:

  1.  Why is Fossil based on SQLite instead of a distributed NoSQL database?

  2.  Why is Fossil written in C instead of a modern high-level language?

<title>Unversioned Content</title>
<h1 align="center">Unversioned Content</h1>

"Unversioned content" or "unversioned files" are
files stored in a Fossil repository without history, meaning
it retains the newest version of each such file, and that alone.

Though it omits history, Fossil does sync unversioned content between
repositories.  In the event of a conflict during a sync, it retains