<h1>Fossil Cookbook</h1>
The <cite>Fossil</cite> Cookbook is a collection of task-oriented instructions for intermediate users who wish to do more than basic operations with their <cite>Fossil</cite> repositories.  The [Tutorial|tutorial] is a more suitable place for newcomers trying to learn the basic concepts to go first before tackling these recipes.

<h2>Index</h2>
<ul>
  <li> Server recipes:
    <ul>
      <li>  <a href="#CGI">Using <cite>Fossil</cite>'s Built-In CGI</a>
    </ul>
  <li> <a href="#env">Using Environment variables</a>
  <li> <a href="#css">Example CSS</a>
  <li> <a href="#source-hilight">Source highlighting</a>
</ul>

<h2><a name="CGI">Using <cite>Fossil</cite>'s Built-In
<h3>Motivation</h3>
  *  You want to share a repository through your existing web infrastructure.
  *  You want to share more than one repository at the same time.

<h3>Problem</h3>
Unlike some other distributed SCMs, <cite>Fossil</cite> can only clone, push, pull and and otherwise interact through repositories over HTTP.  This can be simply and easily managed through use of the <code>fossil server</code> and/or <code>fossil ui</code> commands, of course, but this is really only adequate for ad-hoc repository sharing.  Consider, for example, sharing ten repositories.  Using the built-in server would require you to open ten ports in your firewall to permit access.  Any serious sharing will require something more robust and permanent.

<h3>Solution</h3>
<cite>Fossil</cite> supports three different ways to share repositories.  For ad-hoc sharing <code>fossil is more than adequate.  For more robust solutions, however, the use of <cite>(x)inetd</cite> or CGI support is indicated.

Setting up fossil for CGI support is simple.  (Setting up your web server for CGI support may or may not be simple, but it is out of scope of this recipe.  Consult your web server/service provider's documentation for this.)

<h4>UNIX</h4>
  1.  Find your CGI scripts directory (if applicable).  This is commonly something like but does not have to be.
  2.  Inside that directory build a script file which looks like this:<br><code><pre>  #! fossil<br>  repository:
  3.  Ensure that the script file so generated is set executable for the CGI user account.
  4.  Ensure that every directory in the path leading to the repository is  browseable (chmod +x) to the CGI user account.
  5.  Ensure that the repository file is readable <em>and</em> writable to the CGI user account.

The following <cite>bash</cite> script can be run from within the directory containing the <cite>Fossil</cite> repositories to be shared (and, of course, altered for your setup) to set some of the constraints above up automatically:

<nowiki><font face="monospace">
<font color="#a52a2a">&nbsp;1 </font><font color="#0000ff">#! bash</font><br>
<font color="#a52a2a">&nbsp;2 </font><font
<font color="#a52a2a">&nbsp;3 </font><font color="#008b8b">REPOSITORY_OWNER</font>=michael<br>
<font color="#a52a2a">&nbsp;4 </font><font color="#008b8b">CGI_GROUP</font>=www-data<br>
<font color="#a52a2a">&nbsp;5 </font><font color="#6a5acd">`whoami`</font>&nbsp;<font color="#ff00ff">'root'</font>&nbsp;<font
<font color="#a52a2a">&nbsp;6 </font><font
<font color="#a52a2a">&nbsp;7 </font>&nbsp;&nbsp;<font <font
<font color="#a52a2a">&nbsp;8 </font>&nbsp;&nbsp;<font
<font color="#a52a2a">&nbsp;9 </font>&nbsp;&nbsp;&nbsp;&nbsp;<font color="#008b8b">SOURCE</font>=<font color="#6a5acd">`</font><font color="#a020f0">$repository</font><br>
<font color="#a52a2a">10 </font>&nbsp;&nbsp;&nbsp;&nbsp;<font color="#008b8b">DESTINATION</font>=<font color="#a020f0">${</font><font color="#a020f0">repository</font><font color="#a020f0">}</font><br>
<font color="#a52a2a">11 </font>&nbsp;&nbsp;&nbsp;&nbsp;<font color="#ff00ff">&nbsp;</font><font color="#ff00ff">#! fossil</font><font color="#ff00ff">&nbsp;</font><font color="#a020f0">$DESTINATION</font><br>
<font color="#a52a2a">12 </font>&nbsp;&nbsp;&nbsp;&nbsp;<font color="#ff00ff">&nbsp;</font><font color="#ff00ff">repository: </font><font color="#a020f0">$SOURCE</font><font color="#ff00ff">&nbsp;</font><font color="#a020f0">$DESTINATION</font><br>
<font color="#a52a2a">13 </font>&nbsp;&nbsp;&nbsp;&nbsp;chown <font color="#a020f0">$REPOSITORY_OWNER</font>:<font color="#a020f0">$CGI_GROUP</font>&nbsp;<font color="#a020f0">$SOURCE</font><br>
<font color="#a52a2a">14 </font>&nbsp;&nbsp;&nbsp;&nbsp;<font color="#ff00ff">664</font>&nbsp;<font color="#a020f0">$SOURCE</font><br>
<font color="#a52a2a">15 </font>&nbsp;&nbsp;&nbsp;&nbsp;chown root:root <font color="#a020f0">$DESTINATION</font><br>
<font color="#a52a2a">16 </font>&nbsp;&nbsp;&nbsp;&nbsp;<font color="#ff00ff">755</font>&nbsp;<font color="#a020f0">$DESTINATION</font><br>
<font color="#a52a2a">17 </font>&nbsp;&nbsp;<font
<font color="#a52a2a">18 </font><font
<font color="#a52a2a">19 </font>&nbsp;&nbsp;sudo <font color="#a020f0">$0</font>&nbsp;<font color="#a020f0">$*</font><br>
<font color="#a52a2a">20 </font><font


<h4>Windows</h4>
<p>While it is far from a perfect set of instructions.. here are some quick notes that should help windows users along the way...</p>
<ul>
<li>you need fossil.exe accessible by your web server or on your path.. easiest is to just chuck it in (usually </li>
<li>assuming you are running apache, you need to either add the ExecCGI to the options on your DocumentRoot, or make sure the ScriptAlias directive is set and put your .cgi files in that folder..</li>
<li>the contents of your cgi file needs to essentially the same as above.. however paths needs to be windows friendly.. i have made sure that all folders on my test box are free of spaces, and as such this file works for me (obviously your paths may differ)
<pre>
#! fossil.exe
repository:
</pre>
I suppose you could put fossil.exe somewhere more specific and set the path to it as well, but since you are probably using the same executable for cmdline and cgi it kind of just makes sense to put it somewhere more accessible</li>
<li>As with most Windows based web instructions, permission are not as important, however at the least, you need to make sure that your repository is not flagged read-only, as you will encounter database errors if it is.</li>
</ul>

<h3>Discussion</h3>
Using the CGI server is the best solution combining an existing web infrastructure and the sharing of many <cite>Fossil</cite> repositories.  Unlike the ad-hoc solution which requires, in effect, a separate port for each simultaneously-shared repository, and which requires several instances of fossil running -- one for each shared repository -- the CGI approach uses URLs to distinguish between repositories and only (briefly) runs a copy of fossil when the repository is actually accessed.

Sharing repositories with CGI is really only worth the effort if more than one repository is being shared, however.  With only one being shared, <code>fossil server</code> is likely more than adequate or the use of (x)inetd may be indicated.  If, however, there is already an existing web infrastructure in place, CGI still may be preferred if only for consistency and maintainability of the system as a whole.

<h2><a name="env">Using Environment
<h3>Motivation</h3>
  *  Want to use a different editor for checkins (Unix/Windows)
  *  Use a proxy if you are behind a firewall

<h3>Solution</h3>
Environment variables are used to customize some programme behaviour. On Linux/Unix they can be set in you ~/.bashrc or even on command line. On Windows they can be set in the system settings.

<cite>Fossil</cite> checks the following environment variables:
  *  VISUAL/EDITOR
  *  http_proxy
  *  TMP_DIR
  *  GATEWAY_INTERFACE
  *  SQLITE_FORCE_PROXY_LOCKING
  *  USER
  *  USERNAME

contain the editor of your choice that is used to write the commit file.

<b>TMP_DIR</b> specifies the directory for temporary files.

<b>GATEWAY_INTERFACE</b> ???

<b>SQLITE_FORCE_PROXY_LOCKING</b> ???

<b>USER</b>

<b>USERNAME</b>


<h2><a name="css"></a>Example CSS</h2>
<h3>Motivation</h3>
The default UI may not be stylish in everyones eyes.
It is up to you to change it. See the CSS code below from this site Horse]

<nowiki>
<pre>
/* General settings for the entire page */
body {
  margin: 0ex 1ex;
  padding: 0px;
  background-color: white;
  font-family: "sans serif";
}

/* Make the links in the footer less ugly... */
a { color: #000f6a; }
a:link { color: #000f6a; }
a:visited { color: #000f6a; }
a:hover { background-color: #e3e3e3; }


hr {
  height: 3px;
  border-top: none; /*1px dashed #005;*/
  border-bottom: 1px dashed #005;
  border-left: none;
  border-right: none;
}
/* The project logo in the upper left-hand corner of each page */
div.logo {
  display: table-cell;
  text-align: center;
  vertical-align: bottom;
  color: #000f6a;
}

/* The page title centered at the top of each page */
div.title {
  display: table-cell;
  font-size: 2em;
  font-weight: bold;
  text-align: center;
  color: #000f6a;
  vertical-align: bottom;
  width: 100%;
}

/* The login status message in the top right-hand corner */
div.status {
  display: table-cell;
  text-align: right;
  vertical-align: bottom;
  color: #000f6a;
  font-size: 0.8em;
}

/* The header across the top of the page */
div.header {
  display: table;
  width: 100%;
  text-align: center;
}

/* The main menu bar that appears at the top of the page beneath
** the header */
div.mainmenu {
  padding: 2px 5px 2px 5px;
  font-size: 0.9em;
  text-align: center;
  letter-spacing: 1px;
  background-color: #e3e3e3;
  color: #000f6a;
  border: 1px inset black;
}

/* The submenu bar that *sometimes* appears below the main menu */
div.submenu {
  padding: 2px 5px 2px 5px;
  font-size: 0.9em;
  text-align: center;
  background-color: #e3e3e3;
  color: #000f6a;
}
div.mainmenu a, div.mainmenu a:visited, div.submenu a, div.submenu a:visited {
  padding: 2px 10px 2px 10px;
  color: #000f6a;
  background-color: #e3e3e3;
  text-decoration: none;
}
div.mainmenu a:hover, div.submenu a:hover {
  color: #e3e3e3;
  background-color: #000f6a;
}

/* All page content from the bottom of the menu or submenu down to
** the footer */
div.content {
  padding: 0ex 1ex 0ex 2ex;
}

/* Some pages have section dividers */
div.section {
  margin-bottom: 0px;
  margin-top: 1em;
  padding: 1px 1px 1px 1px;
  font-size: 1.2em;
  font-weight: bold;
  background-color: #e3e3e3;
  color: #000f6a;
}

/* The "Date" that occurs on the left hand side of timelines */
div.divider {
  background-color: #e3e3e3;
  color: #000f6a;
  border: 1px #bbbbff solid;
  font-size: 1em; font-weight: normal;
  padding: .25em;
  margin: .2em 0 .2em 0;
  float: left;
  clear: left;
}

/* The footer at the very bottom of the page */
div.footer {
  font-size: 0.8em;
  padding: 2px 5px 2px 5px;
  text-align: center;
  letter-spacing: 1px;
  background-color: #e3e3e3;
  color: #000f6a;
  border: 1px inset black;
}

/* Make the links in the footer less ugly... */
div.footer a { color: #000f6a; }
div.footer a:link { color: #000f6a; }
div.footer a:visited { color: #000f6a; }
div.footer a:hover { background-color: #000f6a; color: #e3e3e3; }

/* verbatim blocks */
pre.verbatim {
   background-color: #f5f5f5;
   padding: 0.5em;
}

/* The label/value pairs on (for example) the vinfo page */
table.label-value th {
  vertical-align: top;
  text-align: right;
  padding: 0.2ex 2ex;
}

/* For marking important UI elements which shouldn't be
   lightly dismissed. I mainly use it to mark "not yet
   implemented" parts of a page. Whether or not to have
   a 'border' attribute set is arguable. */
.achtung {
  color: #ff0000;
  background: #ffff00;
  border: 1px solid #ff0000;
}

table.fossil_db_generic_query_view {
  border-spacing: 0px;
  border: 1px solid black;
}
table.fossil_db_generic_query_view td {
  padding: 2px 1em 2px 1em;
}
table.fossil_db_generic_query_view tr {
}
table.fossil_db_generic_query_view tr.even {
  background: #ffffff;
}
table.fossil_db_generic_query_view tr.odd {
  background: #e5e5e5;
}
table.fossil_db_generic_query_view tr.header {
  background: #558195;
  font-size: 1.5em;
  color: #ffffff;
}
</pre>
</nowiki>
<h2><a name="source-hilight">Source
<h3>Motivation</h3>
  *  You want to have source code highlighting for the files in your repository

<h3>Problem</h3>
The main purpose of Fossil is to do versioning the source code. Although it provides a standalone server and lets you navigate through the repository files additional features like source code highlighting from my perspective (I am not a developer of Fossil) is out of scope for an SCM. Just keep the Unix principle: small little programs that do their task and do it well.

However to have a source code highlighting in the presented web pages would still be desirable.

<h3>Solution</h3>
There are two scenarios how to implement such a feature:
   *  Fossil pipes the source code through a filter before sending it to the browser. The filter could be defined as a configuration option to Fossil. One solution for this might be the <a Source code Highlighting</a> program.
   *  Use a Javascript library that renders the code within your browser. One solution for this might be <a Syntax Highlighter</a>

I estimate that the <i>pipe</i> solution needs some more work/ code changes. Thus I am solely looking at the Javascript solution.

The SyntaxHighlighter is a library of some Javascript files, a little Flash application and a CSS file. The Flash application is for copying to clipboard, print and view source. You have the option to include all the files into your repository or use the files hosted at Google. The latter may only be an option if you are connected to internet all the time.

For syntax highlighting to work the Header and Footer templates need to be modified and a little code change has to be applied to the Fossil sources.
<p>
<b>Header</b>
<pre>
&lt;html&gt;
 &lt;head&gt;
 &lt;title&gt;$&lt;project_name&gt;: $&lt;title&gt;&lt;/title&gt;
 &lt;link rel="alternate" type="application/rss+xml" title="RSS Feed"
       href="$baseurl/timeline.rss"&gt;
 &lt;link rel="stylesheet" href="$baseurl/style.css" type="text/css"
       media="screen"&gt;
 &lt;link rel="stylesheet" type="text/css"
       media="screen"&gt;
 &lt;/head&gt;

. . .
</pre>
</p><p>
<b>Footer</b>
<pre>
&lt;/div&gt;
&lt;div class="footer"&gt;
Fossil version $manifest_version $manifest_date
&gt;/div&gt;
&lt;script language="javascript"
&lt;script language="javascript"
&lt;script language="javascript"&gt;
dp.SyntaxHighlighter.ClipboardSwf =
dp.SyntaxHighlighter.HighlightAll('code');
&lt;/script&gt;

</pre>
</p><p>
function artifact_page
<pre>
if( zMime==0 ){
    @ &lt;pre name="code" class="c"&gt;
    @ %h(blob_str(&content))
    @ &lt;/pre&gt;
</pre>
</p>
<h3>Discussion</h3>
The Javascript solution requires a minimum to be fully supported by Fossil. Of course my litte change only applies for C/C++ files. But only little more work needs to be done to get the extension of the file a guess the file type.

The pipe solution would also be nice but would probably need some more work than this little patch.