> Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that.
This is probably in reference to this old message by Richard D. Hipp [1]:
"Fossil, in contrast, is designed to remember everything. Fossil was specifically designed to support the DO-178B inspired development process used by SQLite, with few developers and a complete and immutable audit trail for all inputs."
DO-178B, now superseded by DO-178C [2], was an FAA standard used for the approval of commercial software-based aerospace systems.
svn was used successfully for many years at many companies without having the git "feature" of deleting history. svn obliterate was never implemented and if people needed something like that they would use admin hacks. It was definitely as easy as git makes it.
Re:Fossil – Next Generation
by jimktrains2 on Wednesday November 22, 2017 @10:22AM
(#15757411)
It also comes from how git is used. With git small commits are possible. It's nice to be able to manage those and build larger, coherent ones. Also, because of the distributed nature, sometimes rewriting is useful to fix mistakes.
However, yes, that is not the only possible workflow. SVN and CVS have been used on very large projects with moderate success. SQLite development is done in fossil. It's not impossible to do it correctly with immutable history.
You could obviously edit the underlying sqlite data store if you really wanted to, but there is no UI and they consider that a feature. While I'm sure I'm coming off as judgey I can understand their points, even if I feel like it would lead to a mess at every company I've worked at.
It is nice that additional things besides source can be tracked, bug requests for instance.