Fossil

<a href="http://www.fossil-scm.org/fossil/leaves">Leaves</a> link at
the top of the page.</p></li>

<li><p>Select a version of of fossil you want to download.  Click on its
link.  Note that you must successfully log in as "anonymous" in step 1
above in order to see the link to the detailed version information.</p></li>

<li><p>On the version information page, click on the "[details]" hyperlink
that appears right after the check-in comment at the top of the page.</p>

<li><p>Finally, click on the
"Zip Archive" link.  This link will build a ZIP archive of the 
complete source code and download it to your browser.
</ol>

<h2>2.0 Compiling</h2>

................................................................................
<li value="6">
<p>Create a directory to hold the source code.  Then unzip the
ZIP archive you downloaded into that directory.  You should be
in the top-level folder of that directory</p></li>

<li><p><b>(Optional:)</b>
Edit the Makefile to set it up like you want.  You probably do not
need to do anything.  Do not be intimidated:  There are only 5
variables in the makefile that can be changed.  The whole Makefile
is only a few dozen lines long and most of those lines are comments.</p>

<li><p>Type "<b>make</b>"
</ol>

<h2>3.0 Installing</h2>

<a href="http://www.fossil-scm.org/fossil/leaves">Leaves</a> link at
the top of the page.</p></li>

<li><p>Select a version of of fossil you want to download.  Click on its
link.  Note that you must successfully log in as "anonymous" in step 1
above in order to see the link to the detailed version information.</p></li>




<li><p>Finally, click on the
"Zip Archive" link.  This link will build a ZIP archive of the 
complete source code and download it to your browser.
</ol>

<h2>2.0 Compiling</h2>

................................................................................
<li value="6">
<p>Create a directory to hold the source code.  Then unzip the
ZIP archive you downloaded into that directory.  You should be
in the top-level folder of that directory</p></li>

<li><p><b>(Optional:)</b>
Edit the Makefile to set it up like you want.  You probably do not
need to do anything.  Do not be intimidated:  There are less than 10
variables in the makefile that can be changed.  The whole Makefile
is only a few dozen lines long and most of those lines are comments.</p>

<li><p>Type "<b>make</b>"
</ol>

<h2>3.0 Installing</h2>

pull the documentation file from the local source tree on disk, not
from the any check-in.  The "<b>ckout</b>" keyword normally
only works when you start your server using the "<b>fossil server</b>"
or "<b>fossil ui</b>"
command line and is intended to show what the documentation you are currently
editing looks like before you check it in.

Finally, the <i>&lt;filename&gt;</i> element of the URL is the full
pathname of the documentation file starting from the root of the source
tree.

The mimetype (and thus the rendering) of documentation files is 
determined by the file suffix.  Fossil currently understands 192
different file suffixes, including all the popular ones such as
".css", ".gif", ".htm", ".html", ".jpg", ".jpeg", ".png", and ".txt".

................................................................................
recently.  If you wanted to see an historical version of this document,
you could substitute the name of a check-in for "<b>/tip/</b>".
For example, to see the version of this document associated with
check-in [9be1b00392], simply replace the "<b>/tip/</b>" with
"<b>/9be1b00392/</b>".  You can also substitute the symbolic name
for a particular version or branch.  For example, you might
replace "<b>/tip/</b>" with "<b>/trunk/</b>" to get the latest
version of this document in the "trunk" branch.  (As of this writing,
the self-hosting fossil repository only has a single branch "trunk" and
so "trunk" and "tip" amount to the same thing, but they would be different

in a project with multiple branches.)
















The file that encodes this document is stored in the fossil source tree under
the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the
last part of the URL for this document.

As I sit writing this documentation file, I am testing my work by
running the "<b>fossil server</b>" command line and viewing
<b>http://localhost:8080/doc/ckout/www/embeddeddoc.wiki</b> in
Firefox.  I am doing this even though I have not yet checked in
the "<b>www/embeddeddoc.wiki</b>" file for the first time.  Using
the special "<b>ckout</b>" version identifier on the "<b>/doc</b>" page
it is easy to make multiple changes to multiple files and see how they all
look together before committing anything to the repository.

pull the documentation file from the local source tree on disk, not
from the any check-in.  The "<b>ckout</b>" keyword normally
only works when you start your server using the "<b>fossil server</b>"
or "<b>fossil ui</b>"
command line and is intended to show what the documentation you are currently
editing looks like before you check it in.

Finally, the <i>&lt;filename&gt;</i> element of the URL is the
pathname of the documentation file relative to the root of the source
tree.

The mimetype (and thus the rendering) of documentation files is 
determined by the file suffix.  Fossil currently understands 192
different file suffixes, including all the popular ones such as
".css", ".gif", ".htm", ".html", ".jpg", ".jpeg", ".png", and ".txt".

................................................................................
recently.  If you wanted to see an historical version of this document,
you could substitute the name of a check-in for "<b>/tip/</b>".
For example, to see the version of this document associated with
check-in [9be1b00392], simply replace the "<b>/tip/</b>" with
"<b>/9be1b00392/</b>".  You can also substitute the symbolic name
for a particular version or branch.  For example, you might
replace "<b>/tip/</b>" with "<b>/trunk/</b>" to get the latest
version of this document in the "trunk" branch.  The symbolic name
can also be a date and time string in any of the following formats:</p>


<ul>
<li> <i>YYYY-MM-DD</i>
<li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM</i>
<li> <i>YYYY-MM-DD</i><b>T</b><i>HH:MM:SS</i>
</ul>

When the symbolic name is a date and time, fossil shows the version 
of the document that was most recently checked in as of the date
and time specified.  So, for example, to see what the fossil website
looked like at the beginning of 2010, enter:

<blockquote>
<a href="http://www.fossil-scm.org/index.html/doc/2010-01-01/www/index.wiki">
http://www.fossil-scm.org/index.html/doc/<b>2010-01-01</b>/www/index.wiki
</a>
</blockquote>

The file that encodes this document is stored in the fossil source tree under
the name "<b>www/embeddeddoc.wiki</b>" and so that name forms the
last part of the URL for this document.

As I sit writing this documentation file, I am testing my work by
running the "<b>fossil server</b>" command line and viewing
<b>http://localhost:8080/doc/ckout/www/embeddeddoc.wiki</b> in
Firefox.  I am doing this even though I have not yet checked in
the "<b>www/embeddeddoc.wiki</b>" file for the first time.  Using
the special "<b>ckout</b>" version identifier on the "<b>/doc</b>" page
it is easy to make multiple changes to multiple files and see how they all
look together before committing anything to the repository.

    local configuration.  This is easily accomplished using the webserver
    that is built into fossil.  Start the fossil webserver like this:</p>
    
    <blockquote>
    <b>fossil ui </b><i> repository-filename</i>
    </blockquote>

    <p>This starts a webserver listening on port 8080.  You can
    specify a different port using the <b>-port</b> option on the command-line.
    After the server is running, fossil will then attempt to launch your
    web browser and make it point to this web server.  If your system
    has an unusual configuration, fossil might not be able to figure out
    how to start your web browser.  In that case, start the web browser


    yourself and point it at http://localhost:8080/.  Click on the
    "Admin" link on the menu bar to start configuring your repository.</p>

    
    <p>By default, fossil does not require a login for HTTP connections
    coming in from the IP loopback address 127.0.0.1.  You can, and perhaps
    should, change this after you create a few users.</p>
    
    <p>When you are finished configuring, just press Control-C or use
    the <b>kill</b> command to shut down the mini-server.</p>

    local configuration.  This is easily accomplished using the webserver
    that is built into fossil.  Start the fossil webserver like this:</p>
    
    <blockquote>
    <b>fossil ui </b><i> repository-filename</i>
    </blockquote>

    <p>This starts a web server then automatically launches your


    web browser and makes it point to this web server.  If your system
    has an unusual configuration, fossil might not be able to figure out
    how to start your web browser.  In that case, first tell fossil
    where to find your web browser using a command like this:</p>

    <blockquote>
    <b>fossil setting web-browser </b><i>  path-to-web-browser</i>
    </blockquote>
   
    <p>By default, fossil does not require a login for HTTP connections
    coming in from the IP loopback address 127.0.0.1.  You can, and perhaps
    should, change this after you create a few users.</p>
    
    <p>When you are finished configuring, just press Control-C or use
    the <b>kill</b> command to shut down the mini-server.</p>

  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.

Once you have your new repository running on the network server, delete
the original repository from your local machine, then clone the repository
off of the server:

  <b>fossil clone http://user:password@myserver.org/cgi-bin/my-project</b>

(As always, adjust the URL as appropriate for your installation.)
After copying a repository, it is important to reclone it onto new machines.
Each repository has a random "repository ID" and repositories will not
sync with another repository having the same ID (to avoid sync loops).
Cloning the repository will give you a new repository ID in your local
copy and allow you to sync with the server.

  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.

   *  Description and comments in [./bugtheory.wiki | bug reports].
   *  Check-in comments.
   *  [./embeddeddoc.wiki | Embedded documentation] files whose
      name ends in "wiki".

The [/wiki_rules | formatting rules] 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.

Some commentators feel that the use of HTML is a mistake and that
fossil should use the markup language of the
<i>fill-in-your-favorite</i> wiki engine instead.  That approach
was considered but was rejected for the following reasons:

   *  Description and comments in [./bugtheory.wiki | bug reports].
   *  Check-in comments.
   *  [./embeddeddoc.wiki | Embedded documentation] files whose
      name ends in "wiki".

The [/wiki_rules | formatting rules] for fossil wiki
are designed to be simple and intuitive.  The idea is that wiki provides
paragraph breaks, numbered and bulletted lists, and hyperlinking for
simple documents together with a safe subset of HTML for more complex
formatting tasks.

Some commentators feel that the use of HTML is a mistake and that
fossil should use the markup language of the
<i>fill-in-your-favorite</i> wiki engine instead.  That approach
was considered but was rejected for the following reasons: