Wiki Page Cookbook
Not logged in
HomeFilesLeavesTimelineBranchesTagsTicketsWikiLogin
Overview

Version:cf1f5f329147df989aae524efd9c0bcca190cb20
Date: 2009-10-18 15:16:17
Original User: anonymous
Commands: history | raw-text

Content

Fossil Cookbook

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

Index

Using Fossil's Built-In CGI

Motivation

Problem

Unlike some other distributed SCMs, Fossil can only clone, push, pull and and otherwise interact through repositories over HTTP. This can be simply and easily managed through use of the fossil server and/or fossil ui 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, and solutions for doing so are described below.

Solution

Fossil supports three different ways to share repositories. For ad-hoc sharing fossil server/ui is more than adequate. For more robust solutions, however, the use of (x)inetd 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.)

UNIX

  1. Find your CGI scripts directory (if applicable). This is commonly something like <base>/cgi-bin/, but does not have to be.
  2. Inside that directory build a script file which looks like this:
      #! /usr/bin/env fossil
      repository: /full/path/to/repository/file.fsl
  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 and writable to the CGI user account.

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

 1 #! /usr/bin/env bash
 2 CGI_ROOT=/usr/lib/fossil
 3 REPOSITORY_OWNER=michael
 4 CGI_GROUP=www-data
 5 if [ `whoami` = 'root' ]
 6 then
 7   for repository in *.fsl
 8   do
 9     SOURCE=`pwd`/$repository
10     DESTINATION=$CGI_ROOT/${repository%.fsl}
11     echo "#! /usr/bin/env fossil" > $DESTINATION
12     echo "repository: $SOURCE" >> $DESTINATION
13     chown $REPOSITORY_OWNER:$CGI_GROUP $SOURCE
14     chmod 664 $SOURCE
15     chown root:root $DESTINATION
16     chmod 755 $DESTINATION
17   done
18 else
19   sudo $0 $*
20 fi

Here is a little perl script to put in your cgi-bin to list all the fossils you are publishing: 

#!/usr/bin/perl -w
my $CGI_BIN = '/Library/WebServer/CGI-Executables';
my @files = `grep -l repository:  $CGI_BIN/* `;
print <<EOM;
Content-Type: text/html

Fossils for this server
<ul>
EOM

for (@files) {
  s{.*/}{};
  next if /~$/;
  print "<li><a href='$_'>$_</a></li>\n";
}
print "</ul>\n";

The following apache2 configuration can be used to run the root of a web site with fossil, but still allow other services / documents to be reached via specific URLs. Replace "code.autonomo.us" with your site's name and "dclark@pobox.com" with your email. 

NameVirtualHost *:80
<VirtualHost *:80>
    ServerName code.autonomo.us
    ServerAdmin dclark@pobox.com
    ErrorLog /var/log/apache2/code.autonomo.us-error.log
    LogLevel warn
    CustomLog /var/log/apache2/code.autonomo.us-access.log combined
    ServerSignature On

    DocumentRoot /var/www/

    ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
    <Directory "/usr/lib/cgi-bin">
        AllowOverride None
        Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
        Order allow,deny
        Allow from all
    </Directory>

    # Fossil SCM at root of web site (http://example.com) configuration...
    RewriteEngine On
    # RewriteCond - One for every URL we don't want Fossil SCM to serve. In the
    #               example, requests that go to the /var/www/tmp directory and 
    #               the /usr/lib/cgi-bin directoty are ignored by Fossil SCM.
    RewriteCond %{REQUEST_URI} !^/tmp/.*$
    RewriteCond %{REQUEST_URI} !^/cgi-bin/.*$
    RewriteRule ^(.*)$ /usr/lib/cgi-bin/code.autonomo.us/$1 [T=application/x-httpd-cgi]
</VirtualHost>

/usr/lib/cgi-bin/code.autonomo.us is just a standard fossil CGI file; it looks like this: 

#!/usr/bin/fossil
repository: /srv/fossil-scm/code.autonomo.us.fossil-scm

Another solution to automatically serve multiple repositories

With the following CGI script (I have named it p simply) it is possible to define a location where all the your repositories should be located (in this example: /home/repos/fossil). All the repositories are named according the scheme <project name>.fsl for sake of this example.

If this script is called alone (like e.g.: http://your.server.here/cgi-bin/p), it will list all repositories located under $REPOSROOT, if there does not exist a corresponding file .<project name> (that mechanism is used to hide some repository in the listing).

If the script is called like e.g. http://your.server.here/cgi-bin/p/<project name>, then the corresponding repository will be selected to work with.

The lines 5 - 8 in the script below allow configuration for you needs. You have to chose, what fossil binary to use, what extension your repository databases have and where all your databases are located.

 1 #!/bin/sh
 2
 3 ### Configuration section ###
 4
 5 TITLE="<h2>Fossil repositories</h2>"
 6 FOSSIL=/usr/local/bin/fossil
 7 REPOSROOT=/home/repos/fossil
 8 REPOSEXT=".fsl"
 9
10 ### Processing section -- nothing to configure here! ###
11
12 set -f    ; # disable filename globbing
13
14 ## Some helper functions
15
16 HeaderText () {
17   if [ -z "$headerWritten" ]; then
18     echo "Content-type: text/plain; charset=iso-8859-1"
19     echo
20     headerWritten=1
21   fi
22 }
23
24 HeaderHTML () {
25   if [ -z "$headerWritten" ]; then
26     echo "Content-type: text/html; charset=iso-8859-1"
27     echo
28     headerWritten=1
29   fi
30 }
31
32 Error () {
33   HeaderHTML
34   echo "<p><font color="red">ERROR: $1</font></p>"
35   exit 1
36 }
37
38 P () {
39   HeaderText
40   for var in $*; do
41     eval echo $var = "\$$var"
42   done
43 }
44
45 ## Do the real work here ...
46
47 project=`echo $PATH_INFO | sed -e 's!/\([^/]*\).*!\1!'| tr "[A-Z]" "[a-z]"`
48 repos="$REPOSROOT/$project$REPOSEXT"
49
50 if [ -r "$repos" ]; then
51   PATH_INFO=`echo $REQUEST_URI | sed -e "s!^$SCRIPT_NAME/$project\\([^?]*\\).*!\\1!"`
52   : ${PATH_INFO:=/}
53   SCRIPT_NAME=$SCRIPT_NAME/$project
54   TEMPFILE=`mktemp /tmp/fossil-$project.XXXXXX` || Error "Couldn't create tempfile"
55   trap "rm -f $TEMPFILE" EXIT QUIT INT TERM
56   echo repository: $repos > $TEMPFILE
57   $FOSSIL cgi $TEMPFILE
58 elif [ -z "$project" ]; then
59   HeaderHTML
60   echo "$TITLE"
61   echo "<ul>"
62   find $REPOSROOT -name "*$REPOSEXT" | \
63   while read repos; do
64     project=`basename $repos $REPOSEXT`
65     if [ -f $repos -a ! -e $REPOSROOT/.$project ]; then
66       echo "<li><a href='${REQUEST_URI}/$project'>$project</a></li>"
67     fi
68   done
69   echo "</ul>"
70 else
71   Error "No such project: $project"
72 fi
73
74 exit 0

Windows

While it is far from a perfect set of instructions.. here are some quick notes that should help windows users along the way...

Discussion

Using the CGI server is the best solution combining an existing web infrastructure and the sharing of many Fossil 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, fossil server 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.

Using Environment variables

Motivation

Solution

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.

Fossil checks the following environment variables:

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

TMP_DIR specifies the directory for temporary files.

GATEWAY_INTERFACE ???

SQLITE_FORCE_PROXY_LOCKING ???

USER

USERNAME

Example CSS

Motivation

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 Wandering Horse 

/* 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;
}

Source highlighting

Motivation

Problem

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.

Solution

There are two scenarios how to implement such a feature:

I estimate that the pipe 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. The examples below assume you have added the syntax highlighting library to your repository into a directory www/scripts.

Header 

<html>
 <head>
 <title>$<project_name>: $<title></title>
 <link rel="alternate" type="application/rss+xml" title="RSS Feed"
       href="$baseurl/timeline.rss">
 <link rel="stylesheet" href="$baseurl/style.css" type="text/css"
       media="screen">
 <link rel="stylesheet" href="$baseurl/doc/tip/www/SyntaxHighlighter.css" type="text/css"
       media="screen">
 </head>

. . .

Footer 

</div>
<div class="footer">
Fossil version $manifest_version $manifest_date
</div>
<script language="javascript" src="$baseurl/doc/tip/www/scripts/shCore.js"></script>
<script language="javascript" src="$baseurl/doc/tip/www/scripts/shBrushCpp.js"></script>
<script language="javascript">
dp.SyntaxHighlighter.ClipboardSwf = '$baseurl/doc/tip/www/scripts/clipboard.swf';
dp.SyntaxHighlighter.HighlightAll('code');
</script>
</body></html>

Fossil/src/info.c function artifact_page 

if( zMime==0 ){
    @ <pre name="code" class="c">
    @ %h(blob_str(&content))
    @ </pre>

Discussion

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.

How to prepare your Windows XP Fossil development Environment

MinGW+NSIS/WiX

Setup TCL
Setup MinGW
Getting NSIS Windows packaging tool
Getting Fossil source code
Build the code with Makefile.win32

Visual Studio Express 2008+WiX

Setup TCL
Setup VS2008
Getting WiX Windows MSI tool
Getting Fossil source code
Build the code with Makefile.win32

Fossil version [c0211010a1] 2009-12-13 01:31:36