Fossil's support for branching was revised in January 2009. Since then the best thing to do is:

  1. Read the embedded tutorial on branching.
  2. Read the FAQ entry on branching.

Some of what is below the line is now wrong or irrelevant.

We probably need some notes on branching.

For now, here is a response to ticket [f90265fc83]:

# create testing branch
fossil tag branch testing uuid1

# where uuid1 is the point at which you want to branch
# Note that the above command creates a new checkin which is a
# sibling of uuid1 and identical to it.

# You still need to tell fossil to use it in the working directory
fossil update testing

# do some experimental work

# back to main branch
fossil update uuid1
fossil update

# The second update is needed because the main branch may have
# moved on from uuid1.

Note that fossil has no concept of a default branch, and in the presence of multiple forks and branches you are usually safer to give an explicit argument to fossil update.

Because fossil supports distributed operation, forks which are not deliberate branches can be quite common, and there is probably no safe algorithm for "the latest non-branch UUID".

On 2008-10-19 14:52:08 UTC anonymous added:
Here is an example of branches work with mercurial

# switch to testing branch
hg branch testing
... do some commits

# switch to default branch
hg branch default
... do another commits

# continue testing work
hg branch testing

But with fossil i need to use UUID? How can i automate this work?

... commits

On 2008-10-19 15:44:45 UTC eric added:
But if you could say

fossil tag branch testing

what should the branch be based on? Your current checkout? The latest descendant of your current checkout? The latest checkin in the "main branch"? Which should it default to? Should fossil sync with the central repository first, if there is one and if your local fossil knows what it is?

If you want to start from the head of the "main branch", or any branch, what if there is an unintended fork there cause by someone syncing a local repository? If there is should you require a merge?

I think you can only answer these questions based on some single view of the change process that suits your situation. If you know what you will always do, you can write a wrapper for fossil in you favourite scripting language.

For instance (and only by way of example) branching based on the current checkout can be done by

fossil tag branch testing `fossil info|sed -n '/checkout: */s///p'`

As for going back to the main branch, there is nothing stopping you from tagging that with the name "default", though the best time to do it is when you create a new repository. And that doesn't solve the problem of which fork to choose, or does it mean going back to where you were on that branch?

On 2008-10-20 09:40:04 UTC anonymous added:
And after that fossil is "ridiculously easy to install and operate"?? Mercurial (and even git!) is much easier to use. (At least in branching and local sync)

On 2008-10-22 19:50:33 UTC eric added:
Yes, it is. Branching is complicated, books have been written about it (e.g. SCM Patterns). I think you have to ask similar questions whatever tool you use. If you find one that defaults to your answers, good - but how much work will it be next year when you have different answers?

I assume you are not falling into the trap of expecting all SCM tools to work in exactly the same way. The world doesn't need another clone, it needs a different approach.