There is big drawback in making it very hard to edit "history": you are bound to carry in your project all sorts of things that you do not want to. And this becomes an even worse problem when you combine source code, tickets and a wiki as Fossil does.
Somebody posts spam as tickets? Now you are bound to have traces of that spam forever in your published repository.
I switched away from bzr to git, just like many others, also because bzr made it impossible to fix small stupid mistakes. OK, I pressed Enter while reaching out for the shift key and made a commit with the wrong commit message. Why do I have to keep that? What does the project gains from this?
I think the problem here is with the word "history". We attach a lot of meaning to that word and nobody wants to be a "history rewriter" or a "revisionist". I prefer more neutral terms like "patch queue" or "version chains". "I polished the chain" sounds much better than "I rewrote history".
On a side note I'd probably refrain from using the phrase "polished the chain" due to the euphemistic nature of 'verb the noun' statements and my natural British tendency to avoid talking about sex explicitly and thus think everyone is talking about sex implicitly.
It's also possible to access everything in the repository using the command:
fossil sqlite3
[Richard Hipp]: The bug that you hit had been there for ages - it wasn't new. But it was obscure. You were just the first to stumble over it. Sorry.
The bug in this case caused a loss of uncommitted work.
One of the things to like about Fossil is its concept of record immutability, that is, data is retained intact in the database even when superseded by a newer version. Fossil asserts a highly ethical position, that revising historical facts is not an acceptable practice.
Using Fossil over the last couple of years, its performance and stability have been rock solid, and I haven't experienced any data loss or other problems with it.