The quickstart guide explains how
to get up and running with fossil. But once you're running, what can
you do with it? This document will walk you through the process of
creating a fossil repository, populating it with files, and then
sharing it over the web.

Now we have an empty repository file named demo.fossil.
There is nothing magical about the extension .fossil - it's
just a convention. You may name your files anything you like.

The first thing we normally want to do is to run fossil as a local server so
that you can configure the access rights to the repo:

stephan@ludo:~/fossil$ fossil ui demo.fossil

The ui command starts up a server (with an optional -port
NUMBER argument) and launches a web browser pointing at the
fossil server. From there it takes just a few moments to configure the
repo. Most importantly, go to the Admin menu, then the Users link, and
set your account name and password, and grant your account all access
privileges. (I also like to grant Clone access to the anonymous user,
but that's personal preference.)

Once you are done, kill the fossil server (with Ctrl-C or equivalent)
and close the browser window.

Tip: it is not strictly required to configure a repository
this way, but if you are going to share a repo over the net then it
is highly recommended. If you are only going to work with the repo
locally, you can skip the configuration step and do it later if
you decide you want to share your repo.

The next thing we need to do is open the repository. To do so
we create a working directory and then cd to it:

That creates a file called _FOSSIL_ in the current
directory, and this file contains all kinds of fossil-related
information about your local repository. You can ignore it
for all purposes, but be sure not to accidentally remove it
or otherwise damage it - it belongs to fossil, not you.

The next thing we need to do is add files to our repository. As it
happens, we have a few C source files lying around, which we'll
simply copy into our working directory.

Fossil doesn't know about those files yet. Telling fossil about
a new file is a two-step process. First we add the file
to the repository, then we commit the file. This is a familiar
process for anyone who's worked with SCM systems before:

You may modify the repository (e.g. add, remove, or commit files) from
both working directories, and doing so might be useful when working on
a branch or experimental code.

Making your repository available over the web is trivial to do. We
assume you have some web space where you can store your fossil file
and run a CGI script. If not, then this option is not for you. If
you do, then here's how...

Note that you should pass your fossil login name and password (as set
via local server mode) during the clone - that ensures that fossil
won't ask you for it on each commit!

A clone is a local copy of a remote repository, and can be opened just
like a local one (as shown above). It is treated identically to your
local repository, with one very important difference. When you commit
changes to a cloned remote repository, they will be pushed back to the
remote repository. If you have autosync on then this sync
happens automatically, otherwise you will need to use the
pull command to get remote changes and the push
command to push your local commits to the remote repository. You must
of course have authorization to commit changes (access is configured
via the Admin/Users page mentioned above).

You may always use the server or ui commands to
browse a cloned repository. You can even edit create or wiki entries,
etc., and they will be pushed to the remote side the next time you
push data to the remote.

This page was generated in about
0.042s by
Fossil version [9aa9ba8bd2] 2018-09-22 17:40:11