3 ms·

Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this pr

Last time I had this discussion I was told it's fundamentally against the concept of fossil and that editing history is an antifeature. Also, they claim this provides assistance in meeting regulatory standards, but never saw much more than assertions on that. 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.

rbehrends 9y ago
> 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. [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... [2] https://en.wikipedia.org/wiki/DO-178C https://en.wikipedia.org/wiki/DO-178C
oblio 9y ago
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.
- jimktrains2 9y ago
  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.

rbehrends 9y ago

> 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. [1] https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg19555.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o... [2] https://en.wikipedia.org/wiki/DO-178C https://en.wikipedia.org/wiki/DO-178C

oblio 9y ago

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.

jimktrains2 9y ago
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.