
Fossil: A decentralized version control, bug tracking, and wiki software - Rexxar
https://www.fossil-scm.org/
======
SQLite
Original author of Fossil here, with two comments:

(1) Fossil was created for the single purpose of supporting SQLite
development, a mission at which it has succeeded spectacularly. Fossil is
therefore a success story, irregardless of its mind-share relative to Git.
That thousands of other developers also find Fossil useful on their own
project is just gravy. I am not concerned that Fossil has not (yet) become the
"one true and great DVCS". My intent is to continue personally supporting and
maintaining Fossil for at least three more decades.

(2) Git people: Please steal ideas and code from Fossil. This is not about
winning and losing; it is about providing the best possible tools. Fossil has
a number features which are missing from Git but which could be easily added
to Git and would enhance the Git-user experience. I'm not talking about the
philosophical differences between Fossil and Git (which I recognize that Git
is unlikely to ever change) but rather specific UI features such as "fossil
all" or "fossil ui" or "fossil undo" or the ability to view the ancestors of
check-ins. Fossil is 2-clause BSD, so you do not even have to acknowledge
where you stole the code from. Do it for your users, please.

~~~
carterehsmith
The fact that you created both an SCM, and a RDBMS, kind of forces the
question:

Does Fossil have something like 'rollback'?

If not, would it not be good to have your standard SQL COMMIT/ROLLBACK
semantics in an SCM?

I mean, sometimes you do something with your SCM that you immediately regret.
Like, you do a 'pull' expecting that perhaps a couple files will be changed,
and instead you get a screenful of statuses, errors and whatnots.

Ooops! So you look at what you typed, and turns out you were in a wrong
branch, or you should have used 'pull x y' or whatever.

In any case, what you want to do now, is to 'roll back' ('undo') the last
command.

Now, in SQL, when you make a mistake, you say 'rollback' and everything is
good.

But in a typical SCM, either you cannot do it at all, or it is nontrivial.
E.g. in Git, the way to 'undo' depends on the command that you are undoing.
Sometimes it is 'revert', sometimes 'reset ^XX~xx' or 'abort', etc etc,
clearly not optimal.

Is there an SCM that does that?

~~~
petre
Fossil does have an undo command but that doesn't work on commits (checkin).
It works on update and revert. Also thete is no rebase to edit the history.
Once you commit it's there. You just mark the bad commit as a mistake or
commit changes in the following checkin. Stuff never gets deleted from the
repo but there is a scrub command. All of this encourages one to commit
responsibly.

~~~
jrapdx3
That's interesting an idea in Fossil that I've always assumed was borrowed
from database ideology. When data is committed to a database and other data
depends on it, deleting data risks damaging data integrity, let alone issues
of falsifying the record.

Fossil enforces the ethical principle that history, e.g., of a project, should
not be revised after the fact. If broken code is submitted to the repo, it can
be replaced, the prior code ignored, but it still is part of the project
history, perhaps serving as a reminder of how things can go wrong, often a
valuable lesson to pass along.

Projects are like people, we all have warts. We don't have to point them out
to casual acquaintances, but we shouldn't try to pretend we don't have them at
all.

------
gaxun
I'm reading the page on how the distributed bug tracking works. I've heard of
Fossil before but never dug too deeply.

> But if a timestamp on a ticket change artifact is off by months or years, it
> can seriously confuse the replay algorithm for determining the current
> ticket state.

I understand the simplicity of merging all the ticket comments by timestamp,
but couldn't they at least include a reference to one or more recent comments
to help establish order when clocks are off? Still wouldn't avoid intentional
bad actors, but there are bound to be people with misconfigured clocks.

If I'm working on a Fossil repository and I want to see what bugs everyone
else has reported, where do I go to get a list of other copies of the
repository so I can query them for new bug reports? Is there some kind of
tracker that lists all the people currently publishing the same Fossil
repository, so I can connect to each one and ask for updates?

I wrote a post [0] on my site about this concept recently. It's not really
polished, I think the thoughts were incomplete. It was written in the context
of git due to its ubiquity these days, but the concept should apply the same
to other DVCS. I know I'm full of a lot of questions and few answers, but
questions help me learn.

[0] [https://www.gaxun.net/ideas/git-
announce/](https://www.gaxun.net/ideas/git-announce/)

~~~
noobermin
>I've heard of Fossil before but never dug too deeply.

Pun not intended?

------
Karupan
I used Fossil for about 4 months on a project. Found it easier than git in
terms of CLI usability. The inbuilt UI, although not polished, is pretty
usable. And the entire project is pretty much a single SQLite file. It
definitely hasn't gotten the attention it deserves.

P.S: It's primary author is known for another piece of software that runs
pretty much everywhere - SQLite!

~~~
wyoung2
> The inbuilt UI, although not polished

If your experience was more than about half a year old, you might want to look
at it again. The default skin changed recently to one that is much more of a
modern web UI.

It is easy to switch the skin on an existing repository or to customize it to
behave the way you like. Fossil currently ships with 10 distinct skins, by my
count.

~~~
xwattt
> skin

The problem of fossil UI is not a skin. Why that annoying commit hashes are so
big? Do you really read them first? Take a look at github UI: every button and
label have meaningful place and polished. And that is the problem of most
github clones - they forgot to hire a designer.

~~~
wyoung2
> Why that annoying commit hashes are so big?

In most places, Fossil shows an abbreviated form of the hash, typically 8-10
characters since Fossil, like Git, will accept any unique prefix of an
artifact hash to refer to that artifact.

Here is a GitHub commit page:

    
    
      https://github.com/aioutecism/amVim-for-VSCode/commits/master
    

and here is a Fossil timeline page, which serves much the same purpose:

    
    
      http://fossil-scm.org/index.html/timeline
    

In the fossil case, the hashes are one character longer, and enclosed in
square brackets instead of a roundrect.

This is a serious complaint?

> Do you really read them first?

No, you ignore them completely until you need to refer to one, and then you
copy-paste it, just like with Git.

> every button and label have meaningful place and polished

Which button or label in the default Fossil skin is not in a meaningful place,
and which shows a lack of polish? Be specific.

> they forgot to hire a designer.

I'm pretty sure the differences between the two stem not from forgetfulness
but from the fact that GitHub, Inc. employs 608 people, is closed source, and
has a revenue model, whereas Fossil is a side project of a company that's
probably 1/100 that size and grows mainly by open source user code
contributions.

------
SwellJoe
Fossil has always seemed really cool, but I don't know if having everything in
one big dependency bundle is actually a good thing. For a variety of reasons,
there will never be a consensus on the right issue tracker and wiki for every
project (and Fossil's implementation is necessarily quite lightweight and
light on capabilities compared to the big guys), so having them all tied
together in an integrated whole is probably one reason Fossil as a revision
control system didn't take off. It caused bunch of people to select out
because they were thinking, "Well, we can't use this tracker or this wiki,
because we need X and Y from our tracker/wiki. This system isn't for us."

That said, I'd love to see these features built as add-ons to git; it wouldn't
be _particularly_ difficult (no more difficult than developing a ticket
tracker or a wiki independent of git). Then again, I'm uncomfortable with the
repository dragging in lots of big stuff like screenshots and diagrams and
such, which are very common for bug trackers and wikis and less common for
code repositories (and something git historically didn't do well, anyway).

Perhaps having a separate git repo for each piece (source, bugs, wiki) and a
convention of including links to them inside of special hidden file (like
.gitignore) would be the right thing. But, then we don't have the issues and
docs following the code around very closely, which gives up some of the
positives.

But, out of the box, Fossil is a really nice looking system. If I weren't
working with other people who already know git (which describes almost
everyone everywhere), I'd probably give it a go. But, I am, so I won't.

~~~
wyoung2
I hear what you're saying, but I don't think someone evaluating Fossil should
say things like, "We've always been a Bugzilla/MediaWiki/whatever shop, so we
won't use tools that don't integrate with that." Instead, they should evaluate
whether Fossil's version of those features provides what they need.

Specifically regarding the ticket tracker, someone evaluating Fossil should
realize that it is _really_ flexible:

    
    
      https://www.fossil-scm.org/index.html/doc/trunk/www/custom_ticket.wiki
      http://www.sqliteconcepts.org/THManual.pdf
    

If you don't like what Fossil's ticket system does out of the box, you can
probably make it do what you need with a small amount of customization.

I don't mean to be rude or cast aspersions on you, but there's a lot of FUD
like this surrounding Fossil. People look at multicolumn feature lists and see
this one weird feature in one of the non-Fossil columns that has a check where
Fossil doesn't and write Fossil off because they think they _might_ need that
feature. This kind of thinking is why there are so many 4x4 SUVs in the
grocery store parking lot.

The simple fact is that there are a whole lot more relatively small software
development teams than there are huge teams that really need a large fraction
of the features in the large competing software packages.

Realize that I'm saying this about a DVCS that was designed to fit the needs
of SQLite.org. If your team, code base, and community isn't larger than that
of SQLite.org, it's "small" in this context, and can probably work happily
within Fossil's limitations. Just as you won't be putting your Jeep Grand
Cherokee in 4-Lo to get out of the parking lot, you probably don't actually
need everything that, say, Bugzilla provides over Fossil's ticketing system.

Now, if you're comparing Fossil ticketing to Redmine + the Scrum dashboard
plugin, and your project management is currently based on that workflow,
that's a horse of a different color. But then, there's nothing preventing you
from ignoring Fossil's ticketing feature and continuing to use your existing
project management system.

~~~
SwellJoe
I agree with you, but I think a whole lot of people working with small teams
are tied up in the Github workflow, and the ancillary third party tools around
it, and would find migrating a chore not worth the effort (and they'd lose a
few things, as well). I'd like to be less tied to proprietary stuff, but the
ship seems to have sailed on that, at least for now, until Github turns evil
or starts to suck.

------
LVB
I like a lot about Fossil and moved many projects into it for a while. What I
eventually couldn't tolerate was the lack of rebase (and history rewriting in
general). There are _extensive_ debates going back years on the Fossil mailing
list about the topic, but ultimately the authors were pretty firm that
rebase/rewriting history is bad and they didn't want to support it.

My local workflow uses commit rewriting a lot in order to keep a useful
history. I commit like crazy and then squash/reorder/rebase to make a nice
logical history ([http://gitup.co](http://gitup.co) is awesome for this on
OSX, BTW). I couldn't do this, at least at the time, with Fossil, and ended up
with piles of not-very-useful commits.

~~~
cm3
Yeah, git doesn't restrict you in that regard and supports both workflows,
which may differ from project to project. Mercurial has a nice improved
version of this, where it's safe to rewrite locally but you're not allowed to
rewrite public history. I think that's a smart compromise, although if the
project you're working on has the concept of patch queues, like the linux
kernel and others, then mutable history to maintain patch queues is a feature,
which in fact had been supported by a few extensions before the new mercurial
rebase implementation landed.

~~~
petre
Fossil also has private branches.

~~~
cm3
Can you rewrite history in those?

~~~
petre
No, you cannot rewrite history at all in fossil. But you can commit repeatedly
to the private branch and when finished merge all the changes into a public
branch. It will look like a single commit.

[https://www.fossil-
scm.org/xfer/doc/trunk/www/private.wiki](https://www.fossil-
scm.org/xfer/doc/trunk/www/private.wiki)

------
starseeker
I'm quite intrigued by the libfossil project
([http://fossil.wanderinghorse.net/repos/libfossil](http://fossil.wanderinghorse.net/repos/libfossil))
which attempts to make the core fossil VCS abilities available as a library.
To the best of my understanding this is and will remain a "spin-off" project
of the main fossil project, but it looks like as of August 2016 there is still
active work on it.

The combination of the BSD license and a self-contained C library in the style
of sqlite that offers VCS capabilities app developers could build into their
applications is extremely enticing. libgit2
([https://libgit2.github.com/](https://libgit2.github.com/)) may have matured
enough to be viable for that use case if one is comfortable with GPLv2 plus
linking exception, but the sqlite-style include one header, build one C file
and you're done integration is really really nice.

------
qwertyuiop924
Fossil is really cool. It never really caught on, which is kind of a shame.

OTOH, it's competing with git, a very well-designed piece of software with
ungodly marketing (and a terrible UI, and it was so well designed because
McVoy's various projects had already made many of the mistakes that Git
didn't, although it avoided some of Git's mistakes, so Linus had something to
work off of. But that's not the point).

~~~
plq
IIRC people DID give fossil a chance but it turned out it could eat your data.
So adoption stopped abruptly. Losing data is very difficult for someone who
knows how to use git reflog.

~~~
dalke
I know about [https://www.mail-archive.com/fossil-users@lists.fossil-
scm.o...](https://www.mail-archive.com/fossil-users@lists.fossil-
scm.org/msg04689.html) where a bug in Fossil in trying to figure out what
check-in to update to, followed by a user attempt to recover, ended up
deleting edited/uncommitted files. Details in [http://www.mail-
archive.com/fossil-users@lists.fossil-scm.or...](http://www.mail-
archive.com/fossil-users@lists.fossil-scm.org/msg04699.html) .

Would that have been fixed via reflog?

What other failures have there been?

To note, many heard about Fossil because of Zed Shaw, who was bitten by the
bug, and wrote about leaving Fossil because of the data loss. I wonder,
therefore, if your recollection is echoes of that one report.

Fossil users pipe up in HN comments, like
[https://news.ycombinator.com/item?id=12665875](https://news.ycombinator.com/item?id=12665875)
from a day ago,
[https://news.ycombinator.com/item?id=12655740](https://news.ycombinator.com/item?id=12655740)
from 3 days ago, and
[https://news.ycombinator.com/item?id=12622773](https://news.ycombinator.com/item?id=12622773)
from a week ago, so there are active users.

~~~
wyoung2
> bug in Fossil in trying to figure out what check-in to update to, followed
> by a user attempt to recover, ended up deleting edited/uncommitted files

Yes, _uncommitted_ changes were lost, which is bad, but not at all what
someone would think when you say "Fossil lost data."

Also, that particular problem was fixed more than five years ago.

> What other failures have there been?

I've been using Fossil for my main work repositories for over two years now,
and have been monitoring the mailing list for about a year prior to that, and
the only things even close to that that I can think of involve crazy user
actions that confused Fossil into doing something odd, typically in the UI
display only, which are now prevented at the code level.

Example: It is possible to fork the trunk by working offline — its autosync
feature prevents it from happening when working online, connected to the repo
you cloned from — but Fossil now demands that you heal the fork after turning
autosync back on, so that you don't end up with multiple active "trunk" tips.
After the trunk fork is healed, one branch becomes the "real" trunk, and the
other looks like an unnamed branch that's now merged.

I'm not aware of any case of committed work being lost by Fossil. In every
case where someone has managed to confuse Fossil, it's always been essentially
a cosmetic issue, with all of the information necessary to get the repository
back to a sane state available in the SQLite DB file.

I have personally never run into such a problem. The closest I've ever come to
data loss with Fossil was purely due to ignorance.

(Briefly, Fossil UI was showing me one thing when I thought it was showing me
something else, and since I didn't see what I expected to see, I thought it
had lost data. This was purely a newbie misunderstanding.)

Compare git:

    
    
      https://xkcd.com/1597/
    

It's funny because it's truthy.

~~~
dalke
I essentially agree, which is why I conjectured that plq was recalling
incorrectly, based perhaps on second- or third-hand accounts of Shaw's
problem.

My hope was that plq would clarify either with a pointer or something else
more than "IIRC".

The only thing I disagree with your assessment is that "ignorance" and "newbie
misunderstanding" can sometimes be due to bad design, which is a design bug
vs. an implementation bug. In the Shaw case, there was a bug in the code which
widened the gap between the user model and how the code actually worked, and
that gap did cause data loss, just not in committed data.

Also not in a way that could be handled in git with reflog, as plq suggested.

This is a more expansive definition of "bug" than software developers, who are
often more focused on the implementation than the user interaction model and
as XKCD points out are very good at memorizing arcane commands, typically use.

Hipp wrote that he might have done the same thing as Shaw, which means that
specific case wasn't "purely a newbie misunderstanding."

I think that was a humble and magnanimous statement which cut off some of the
blame-the-user flamewar that can all too often happen in developer-driven
project. As I recall, Shaw noticed this, and thanked Hipp for the way he
responded. I've tried to bear it in mind since then.

------
PeCaN
I use fossil for all my personal projects. It's absolutely a pleasure to use.
Not much more to say about it, it's a tool that's easy to use and gets the job
done.

Easy to export to a git repo too, e.g. to mirror to GitHub (which I do).

~~~
em3rgent0rdr
could you provide your code/instructions for mirroring to GitHub? I presume
you mirror on every local commit?

~~~
PeCaN
Nothing fancy, I just do

    
    
      fossil export --git repo.fossil | git fast-import
    

manually every now and then. I could set up a fossil hook to do it, but I
haven't quite bothered to yet.

------
phantom_oracle
Link to comparison: [https://www.fossil-
scm.org/index.html/doc/trunk/www/fossil-v...](https://www.fossil-
scm.org/index.html/doc/trunk/www/fossil-v-git.wiki)

------
rwbt
Love fossil. I use it for all my projects. Simple and easy to learn CLI
(unlike some other popular DVCS) and the built-in issue tracker/wiki is very
helpful. For indie devs or small teams fossil 'just works'.

------
antman
nitpick [0] uses your git branches for bug tracking, and has a very easily
customizable interface [1]

[0] [https://github.com/tst2005/nitpick](https://github.com/tst2005/nitpick)

[1]
[http://travisbrown.ca/projects/nitpick/docs/nitpick.html](http://travisbrown.ca/projects/nitpick/docs/nitpick.html)

~~~
chriswarbo
Thanks, I've been looking for a distributed bug tracker (for use with git) for
a while. bugseverywhere seems unmaintained, and all of the other info I could
find was about abandoned projects from 2011.

I'll give nitpick a go :)

------
nomadbyte
Perhaps another factor for minor popularity of Fossil SCM is a lack of plugins
for major IDEs.

I don't believe this should be such an obstacle, as most plugins implement
only a part of SCM client features, thus asking you to resort to command-line
for certain functions. Still, for a lot of developers the expected interaction
with "everything" is through IDE. There seems to be a Git or SVN plugin for
every possible IDE, yet Fossil lags in that department.

JetBrains has a nice Fossil plugin (for IDEA); that's about it, nothing for
VisualStudio, eclipse, Xcode etc. Catch 22 -- no demand, no plugin.

We faced this with our Qt projects, and went on to develop a Fossil SCM plugin
for QtCreator: [https://github.com/nomadbyte/qtcreator-plugin-
fossil](https://github.com/nomadbyte/qtcreator-plugin-fossil)

Not that availability of plugins has to be such a big deal for a SCM adoption,
but sure this helps a lot to increase any SCM's visibility and accessibility.
In case of Fossil this probably will have to be another community effort.

------
rcarmo
I've been using Fossil on and off throughout the years, and find it to be a
very nice all-in-one solution for personal projects.

Collaborating, however, is an issue due to the prevalence of git (it was a bit
easier in the Mercurial days because hg users were used to coexisting with
something else).

The biggest advantage for me is having a single file as the repo. Makes it
much easier to archive stuff.

------
nomadbyte
Version control debates, why??

I think everyone agreed that having an SCM on a project is a must. Everyone
most likely is using some SCM already, often-times the choice is made by
someone else upstairs or in the history. Git, bzr, hg, svn, TFS (ahem) --
you've just got to use what you've got.

HOWEVER, you may just as well use an SCM that is more __optimal__ for your
development style, say, frequent commits, branching, stashes, private branches
and then just pump the completed stages into "official" SCM -- kind of
layering the version control.

You can install Git or bzr etc. just for yourself? Good!, but not everyone may
have such a policy. Fossil does not require installation, it's a self-
contained executable, you may just as well build it from source and use it in
your account.

Just as simply, the same project directory may be tracked by Fossil in
addition to the whatever is the "official" SCM, the only file it places in
working dir is ".fslckout".

I think, there's really no need to debate and pit SCMs against each other --
just use what works for you, your project, well, what fits in your own memory
(it's true, Fossil command and options set is very compact, yet potent --
check it out!)

------
jslakro
What about GitTorrent?
[https://github.com/cjb/gittorrent](https://github.com/cjb/gittorrent)

------
X86BSD
I absolutely love Fossil. I'm really glad to see it show up on HN. I've never
heard of it eating data before.

~~~
hvidgaard
It hasn't. There was a bug that would delete every file except the modified
ones. If you panic there, you could end up deleting your modifications because
you tell fossil to.

It gained quite a bit of attention because Zed A. Shaw was bitten by it.
Nevermind he didn't make a single commit for 3 days, or that he panicked, or
that he didn't even make a simple "backup this folder so anything I do doesn't
mess it up" as is standard with all other DVCS when something goes wrong.
Fossil is fine in this regard, but a rebase function would be welcome.

------
smegel
Hell of a thing to write something like that in C.

~~~
bch
Ostensibly, fossil is not written in C, but a high level language - SQL.

~~~
wyoung2
There is about 94 kSLOC of C code in Fossil at the moment, not counting SQLite
itself, according to SLOCCount. SQLite more than doubles that line count.

By that measure alone, about half of Fossil is "SQL", in the sense that more
than half of the code merely manages the various DBs.

(A Fossil workspace consists of three SQLite DBs: the actual repo DB plus two
machine-specific DBs, one local to the project and one global to the user
login.)

There is a whole lot of embedded SQL among that C code. Simply counting the
number of lines containing the 5 most common SQL statements:

SELECT: 2069 INSERT: 583 DELETE: 492 UPDATE: 410 REPLACE: 122

That doesn't mean the total number of embedded SQL statements is the total of
those 5 numbers, as some of that will be compound statements using two or more
of the above keywords. Fossil uses some of the most complex SQL I've ever seen
outside of [http://thedailywtf.com/](http://thedailywtf.com/)

So, while Fossil does rely very heavily on SQL, I wouldn't say it is "written
in SQL." It merely delegates as much as is sensible to SQL, in the same way
that a fair bit of the Fossil web user interface uses Javascript rather than
call back to the Fossil binary on the server via POST and such to fetch an
updated page.

