[sgbeal]

> Someone will write the necessary scripts (e.g. fossil-rebase) to go into the DB and rewrite history.

No, they won't. The fossil file format is very strongly protected against any changing of history. Changing history changes multiple hashes (at multiple levels) and breaks it. Immutable history is literally part of the metadata specification, and the db is "just a data store," independent of that specification.

[thechriswalker]

From what I just read, the "shun" method means that you can rewrite history by adding a shun, rebuilding a copy, then switching copies.

Not db rewrite, but the same end result.

edit: bad english

[SQLite]

That won't work because the SHA1 hashes won't match up.

If you accidentally check-in proprietary or sensitive content that you didn't mean to publish, you can shun that content. Shunning leaves a hole in your history. There is no way to replace that hole with different content.

[pdw]

Git is the same, if you rebase many hashes will be recalculated, and the "tampering" would be obvious to anyone who had a copy of the repository. It is possible to implement the equivalent of rebase in any distributed VCS, the authors of Fossil simply chose not to. If it becomes more popular, somebody else likely will.

[sgbeal]

i've been on the fossil dev team since 2008, and i have seen many people claim that it "could" be compromised/modified post facto, and yet... nobody has been able to do it. Fossil's core data model does not just _assume_ that history doesn't change - it makes it essentially impossible to do.

Shunning is a special case which removes a given artifact from the db, but is considered a "nuclear option" of last resort. i've never personally used it.