Things I like about Fossil: * Single file repository with proper transactional semantics (it's an SQLite DB) rather than a "pile of files" implementation. I ca

Things I like about Fossil: * Single file repository with proper transactional semantics (it's an SQLite DB) rather than a "pile of files" implementation. I can trivially and safely copy the repository, send it as a mail to a new collaborator, etc. * Fossil is a single executable. Unlike Git or Mercurial, that makes installation trivial. * The whole system is remarkably clean, simple, and lacking in cruft. This also makes it easy to explain and get people started. * Fossil has a well thought-out system for tags and named branches; they are persistent, but can be renamed. This is different from Git, where history tends to be largely a soup of anonymous objects, and Mercurial, where it is impossible to rename branches. * It comes with a built-in wiki and distributed ticketing system. If you want to self-host rather than rely on GitHub/Bitbucket, that's already a very useful feature. * `fossil undo` is very useful, even though it supports only one level of undo. * The ability to store and share unversioned files is often very convenient. Things I don't like about Fossil: * The console interface is sometimes too simplistic for some commands (`fossil timeline` is one of the biggest offenders); it errs in the opposite direction from Git and relies on a GUI too much for basic operation (though I'd still prefer it over Git, but not necessarily other VCSes). That said, you can script it fairly adequately either with the JSON interface or even through direct SQL queries if you don't mind investing the time. * The workflow for external contributions for contributors without commit access is more cumbersome than necessary; in principle, `fossil bundle` serves that need, but it lacks some features (you can't bundle non-commit artifacts, for example). * Commit messages all get squished into a single line of output. You could argue that wiki pages or technotes are the proper way to document more complex information (so you don't have to sift through commit messages), but it's difficult to relate them to a specific commit and they aren't supported by `fossil bundle`, as mentioned above. There's some unfinished work on attaching remarks to commits [1], but this work seems dormant. * Scalability is even more of a problem than with other distributed version control systems if you're dealing with really big repositories (not that those other systems necessarily cover themselves in glory, either), though the situation has improved in recent years. [1] https://www.fossil-scm.org/index.html/timeline?r=remarks-on-checkins https://www.fossil-scm.org/index.html/timeline?r=remarks-on-...