Fossil

<a href="fileformat.wiki">file format document</a> for details.)
Some artifacts have a special format, and among those are
<a href="fileformat.wiki#tktchng">Ticket Change Artifacts</a>.
One or more ticket change artifacts are associated with each 
ticket.  A ticket is created by a ticket change artifact.
Each subsequent modification of the ticket is a separate artifact.

The "push", "pull", and "sync" algorithms share ticket change artifacts
between repositories in the same way as every other artifact.  In fact,
the sync algorithm has no knowledge of the meaning of the artifacts it
is syncing.  As far as the sync algorithm is concerned, all artifacts are
alike.  After the sync has occurs, the individual repositories must
make sense of the meaning of the various artifacts for themselves.

<h2>Interpretation Of Ticket Change Artifacts</h2>

Every ticket change artifact contains (among other things)

  *  a timestamp,
  *  a ticket UUID, and
  *  one or more name/value pairs.

The current state of a ticket is found by replaying all ticket
change artifacts with the same ticket UUID in timestamp order.
For a given ticket, all values are initially NULL.  As each
ticket change artifact is encountered, values are either replaced
or appended, according to a flag on the name/value pair.  The current
values for the fields of a ticket are the values that remain at the
end of the replay process.

To create a new ticket, one inserts a ticket change
artifact with a new UUID.  The ticket UUID
is a random 40-character lower-case hexadecimal number.  The "tktnew"
page in the fossil web interface creates new ticket UUIDs
using a good source of randomness to insure uniqueness.
The name/value pairs on the initial ticket change
artifact are the initial values for the fields in the ticket.

Amending a ticket means simply creating a new artifact with the
same ticket UUID and with name/value pairs for those fields which
are changing.  Fields of the ticket which are not being modified
should not appear as name/value pairs in the new artifact.

input formats and reporting rules according to its own particular needs.

Each repository defines its own TICKET table in its database.  There is
one row in the TICKET table for each unique ticket UUID.  The
names of columns in the TICKET table correspond to the names in
the name/value pairs of ticket change artifacts.  When running the replay
algorithm, if a name/value pair is seen which has no corresponding column
in the TICKET table, then that name/value pair is ignored.  Columns can
be added or removed from the TICKET table at any time.  Whenever the
TICKET table is modified, the replay algorithm automatically reruns
to repopulate the table using the new column names.  Note that the TICKET
table schema and content is part of the local state of a respository
and is not shared with other repositories during a sync, push, or pull.

Each repository also defines scripts used to generate web pages for
creating new tickets, viewing existing tickets, and modifying an
existing ticket.  These scripts consist of HTML with an embedded
scripts written an a TCL-like language called "TH1".  Every new fossil
repository is created with default scripts.  There is currently no
documentation on the TH1 langauage.  Administrators wishing to
customize their ticket entry, viewing, and editing screens should
modify the default scripts to suit their needs.  These screen generator
scripts are part of the local state of a repository and are not shared
with other repositories during a sync, push, or pull.

<i>To be continued...</i>

same artifact, the tag with the latest (most recent) date is
used.</p>

<p>Some tags have special meaning.  The "comment" tag when applied
to a baseline will override the check-in comment of that baseline
for display purposes.</p>

<a name="wikichng"></a>
<h2>4.0 Wiki Pages</h2>

<p>A wiki page is an artifact with a format similar to manifests,
clusters, and control artifacts.  The artifact is divided into
cards by newline characters.  The format of each card is as in
manifests, clusters, and control artifacts.  Wiki artifacts accept
the following card types:</p>

<h1>Fossil: Distributed Revision Control, Wiki, and Bug-Tracking</h1>

<p>
Fossil is a new 
<a href="http://en.wikipedia.org/wiki/Revision_control">
distributed software revision control system</a> that includes an integrated
<a href="wikitheory.wiki">wiki</a> and an integrated
<a href="bugtheory.wiki">bug-tracking system</a> all in a single, 
easy-to-use, stand-alone executable.
Fossil is
<a href="http://www.fossil-scm.org/fossil/timeline">self-hosting</a>
since 2007-07-21 on
<a href="http://www.hwaci.com/cgi-bin/fossil/timeline">two separate servers</a>.
You can download the <a href="../../../timeline">lastest sources</a> and

<a href="http://www.bitkeeper.com/">bitkeeper</a>)
or client/server operation (like 
<a href="http://www.nongnu.org/cvs/">CVS</a> or
<a href="http://subversion.tigris.org/">subversion</a>),
or operations on local repositories,
or all three at the same time</li>
<li>Integrated <a href="bugtheory.wiki">bug tracking</a> and 
<a href="wikitheory.wiki">wiki</a>, inspired by
<a href="http://www.cvstrac.org/">CVSTrac</a> and
<a href="http://www.edgewall.com/trac/">Trac</a> but enhanced to
support distributed, disconnected operation.</li>
<li>Built-in web interface that supports deep archaeological digs through
the project history.</li>
<li>All network communication via 
<a href="http://en.wikipedia.org/wiki/HTTP">HTTP</a> with 

<li>The <a href="concepts.wiki">concepts</b> behind fossil</li>
<li><a href="build.wiki">Building And Installing</a></li>
<li><a href="quickstart.wiki">Quick Start</a> guide to using fossil
<li>Fossil supports <a href="embeddeddoc.wiki">embedded documentation</a>
    that is versioned along with project source code.</li>
<li>The <a href="selfcheck.wiki">automatic self-check</a> mechanism
helps insure project integrity.</li>
<li>Fossil contains a <a href="wikitheory.wiki">built-in wiki</a>.</li>
<li>There is a
    <a href="http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users">
    mailing list</a> available for discussing fossil issues.</li>
</ul>

<p>Developer Links: </p>

<h1>Wiki In <a href="index.wiki">Fossil</a></h1>

Fossil uses <a href="../../../wiki_rules">wiki markup</a> for many
things:

   *  Stand-alone wiki pages.
   *  Description and comments in <a href="bugtheory.wiki">bug reports</a>.
   *  Check-in comments.
   *  <a href="embeddeddoc.wiki">Embedded documentation</a> files whose
      name ends in "wiki".

The <a href="../../../wiki_rules">formatting rules</a> for fossil wiki
are designed to be simple and intuitive.  The idea is that wiki provides
paragaph breaks, numbered and bulletted lists, and hyperlinking for
simple documents together with a safe subset of HTML for more complex
formatting tasks.

<h2>Stand-alone Wiki Pages</h2>

Each wiki page has its own revision history which is independent of
the sequence of baselines (check-ins).  Wiki pages can branch and merge
just like baselines, though as of this writing (2008-07-29) there is
no mechanism in the user interface to support branching and merging.
The currently implementation of the wiki shows the version of the wiki
pages that has the most recent timestamp.

In other words, if two users make unrelated changes to the same wiki
page on separate repositories, then those repositories are synced,
the wiki page will fork.  The web interface will display whichever edit
was checked in last.  The other edit can be found in the history.  The
file format will support merging the branches back together, but there
is no mechanism in the user interface (yet) to perform the merge.

Every change to a wiki page is a separate 
<a href="fileformat.wiki">control artifact</a> 
of type <a href="fileformat.wiki#wikichng">"Wiki Page"</a>.

<i>To be continued...</i>