Fossil Quick Start
This is a guide to get you started using fossil quickly and painlessly.
General Work Flow
Fossil works with repository files (a database with the project's complete history) and with checked-out local trees (the working directory you use to do your work). The workflow looks like this:
The following sections will give you a brief overview of these operations.
Starting A New Project
To start a new project with fossil, create a new empty repository this way: (more info)
fossil init repository-filename
Cloning An Existing Repository
Most fossil operations interact with a repository that is on the local disk drive, not on a remote system. Hence, before accessing a remote repository it is necessary to make a local copy of that repository. Making a local copy of a remote repository is called "cloning".
Clone a remote repository as follows: (more info)
fossil clone URL repository-filename
The URL above is the http URL for the fossil repository you want to clone, and it may include a "user:password" part, e.g. http://user:email@example.com/fossil. You can call the new repository anything you want - there are no naming restrictions. As an example, you can clone the fossil repository this way:
fossil clone http://www.fossil-scm.org/ myclone.fossil
The new local copy of the repository is stored in a single file, which in the example above is named "myclone.fossil". You can name your repositories anything you want. The ".fossil" suffix is not required.
Note: If you are behind a restrictive firewall, you might need to specify an HTTP proxy.
A Fossil repository is a single disk file. Instead of cloning, you can just make a copy of the repository file (for example, using "scp"). Note, however, that the repository file contains auxiliary information above and beyond the versioned files, including some sensitive information such as password hashs and email addresses. If you want to share Fossil repositories directly, consider running the fossil scrub command to remove sensitive information before transmitting the file.
Importing From Another Version Control System
Checking Out A Local Tree
To work on a project in fossil, you need to check out a local copy of the source tree. Create the directory you want to be the root of your tree and cd into that directory. Then do this: (more info)
fossil open repository-filename
This leaves you with the newest version of the tree checked out. From anywhere underneath the root of your local tree, you can type commands like the following to find out the status of your local tree:
Note that Fossil allows you to make multiple check-outs in separate directories from the same repository. This enables you, for example, to do builds from multiple branches or versions at the same time without having to generate extra clones.
To switch a checkout between different versions and branches, use:
update honors the "autosync" option and does a "soft" switch, merging any local changes into the target version, whereas checkout does not automatically sync and does a "hard" switch, overwriting local changes if told to do so.
Configuring Your Local Repository
When you create a new repository, either by cloning an existing project or create a new project of your own, you usually want to do some local configuration. This is easily accomplished using the web-server that is built into fossil. Start the fossil webserver like this: (more info)
fossil ui repository-filename
You can omit the repository-filename from the command above if you are inside a checked-out local tree.
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:
fossil setting web-browser path-to-web-browser
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.
When you are finished configuring, just press Control-C or use the kill command to shut down the mini-server.
To add new files to your project, or remove old files, use these commands:
fossil add file...
fossil rm file...
fossil addremove file...
You can also edit files freely. Once you are ready to commit your changes, type:
You will be prompted for check-in comments using whatever editor is specified by your VISUAL or EDITOR environment variable.
In the default configuration, the commit command will also automatically push your changes, but that feature can be disabled. (More information about autosync and how to disable it.) Remember that your coworkers can not see your changes until you commit and push them.
fossil push URL
Where URL is the http: URL of the server repository you want to share your changes with. If you omit the URL argument, fossil will use whatever server you most recently synced with.
fossil pull URL
fossil sync URL
When you pull in changes from others, they go into your repository, not into your checked-out local tree. To get the changes into your local tree, use update:
fossil update VERSION
The VERSION can be the name of a branch or tag or any abbreviation to the 40-character artifact identifier for a particular check-in, or it can be a date/time stamp. (more info) If you omit the VERSION, then fossil moves you to the latest version of the branch your are currently on.
The default behavior is for autosync to be turned on. That means that a pull automatically occurs when you run update and a push happens automatically after you commit. So in normal practice, the push, pull, and sync commands are rarely used. But it is important to know about them, all the same.
fossil checkout VERSION
Is similar to update except that it does not honor the autosync setting, nor does it merge in local changes - it prefers to overwrite them and fails if local changes exist unless the --force flag is used.
Branching And Merging
Use the --branch option to the commit command to start a new branch. Note that in Fossil, branches are normally created when you commit, not before you start editing. You can use the branch new command to create a new branch before you start editing, if you want, but most people just wait until they are ready to commit.
To merge two branches back together, first update to the branch you want to merge into. Then do a merge another branch that you want to incorporate the changes from. For example, to merge "featureX" changes into "trunk" do this:
The argument to the merge command can be any of the version identifier forms that work for update. (more info.) The merge command has options to cherrypick individual changes, or to back out individual changes, if you don't want to do a full merge.
The merge command puts all changes in your working check-out. No changes are made to the repository. You must run commit separately to add the merge changes into your repository to make them persistent and so that your coworkers can see them. But before you do that, you will normally want to run a few tests to verify that the merge didn't cause logic breaks in your code.
The same branch can be merged multiple times without trouble. Fossil automatically keeps up with things and avoids conflicts when doing multiple merges. So even if you have merged the featureX branch into trunk previously, you can do so again and Fossil will automatically know to pull in only those changes that have occurred since the previous merge.
If a merge or update doesn't work out (perhaps something breaks or there are many merge conflicts) then you back up using:
This will back out the changes that the merge or update made to the working checkout. There is also a redo command if you undo by mistake. Undo and redo only work for changes that have not yet been checked in using commit and there is only a single level of undo/redo.
Setting Up A Server
Fossil can act as a stand-alone web server using one of these commands:
fossil server repository-filename
fossil ui repository-filename
The repository-filename can be omitted when these commands are run from within an open check-out, which a particularly useful shortcut for the fossil ui command.
The ui command is intended for accessing the web interface from a local desktop. The ui command binds to the loopback IP address only (and thus makes the web interface visible only on the local machine) and it automatically start your web browser pointing at the server. For cross-machine collaboration, use the server command, which binds on all IP addresses and does not try to start a web browser.
Servers are also easily configured as:
The the self-hosting fossil repositories use CGI.
If you are behind a restrictive firewall that requires you to use an HTTP proxy to reach the internet, then you can configure the proxy in three different ways. You can tell fossil about your proxy using a command-line option on commands that use the network, sync, clone, push, and pull.
fossil clone URL --proxy Proxy-URL
It is annoying to have to type in the proxy URL every time you sync your project, though, so you can make the proxy configuration persistent using the setting command:
fossil setting proxy Proxy-URL
Or, you can set the "http_proxy" environment variable:
To stop using the proxy, do:
fossil setting proxy off
Or unset the environment variable. The fossil setting for the HTTP proxy takes precedence over the environment variable and the command-line option overrides both. If you have an persistent proxy setting that you want to override for a one-time sync, that is easily done on the command-line. For example, to sync with a co-workers repository on your LAN, you might type:
fossil sync http://192.168.1.36:8080/ --proxy off
Explore and have fun!