Fossil SCM

> I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c.

While I agree that there are those who take pride in how spartan tools they use, it's not correct to make blanket judgements about the whole suite of hackerware. Emacs, for instance, is not difficult to use, it is a different computing environment, which, when you get hold of it, can boost your productivity. I've written many little programs in it that I use every day which I'd never be able to write in other languages because a) I need to know at least one GUI framework and many other libraries, b) no other environment has the same use-hack-eval-use development experience, and c) the way you create GUIs in Emacs is so effective (mixture of special-mode, plain text and text with properties attached; all buffer-manipulation commands come in to your app out of nowhere, gratis) that one can set sth. working in their first hacking session, and then on improve their tools while using it, all interactive, whereas in all other GUI frameworks you're left alone with widgets and a dev cycle that's nearly always approximately write-compile-debug-compile.

Git, instead, is a plain tool for one purpose with an arcane user interface. I believe the patch theory school of VCS tools (e.g. darcs) will overtake in future when they'll smooth out their rough edges as they provide a very intuitive way to work with code as a series of related changes.

It came up on HN not long ago: https://news.ycombinator.com/item?id=12673229. Normally we'd bury this one as a duplicate, but the community is clearly interested in this.

I firmly believe that GitHub has at least 40% role in git's success. Another 40% is Linus, and the remaining 20% is git's technical merits.

I'm using it for a number of personal projects and a couple of projects with a small number of collaborators.

Advantages: The entire repository is a single file (SQLite database), which makes some things easy (backup, putting it on a USB drive, mailing it to another person) and has support for tickets and a wiki built-in. It is simple, but feature-complete for the use cases it is intended for.

Disadvantages: The command line interface is lacking in some regards (which can be fixed through addon tools, but isn't for everybody). In particular, there's a huge feature gap between `fossil ui` and `fossil timeline` for viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to deal with commit hashes rather than numerical version numbers (which can be an annoyance when using annotate/blame, for example). Third-party contribution via `fossil bundle` is too limited IMO; you really want all contributors to have direct access to the repository to be productive.

I tried using Fossil as a DVCS/Project management tool for a class I'm currently teaching - but in the end I couldn't quite figure out self-registration combined with allowing authenticated push in a way that worked for ~25 students without needing much instruction/hand-holding.

If I'd had some form of user-database already, I could probably have gotten it to work with a proxy in front - but for now I've ended up using gogs: https://gogs.io/

I'm not certain I actually prefer gogs to fossil, but apart for working as I wanted/needed without much setup it had the dubious benefit of forcing me to teach my students to use git, along with a rather cumbersome pull-request system (gogs tend to hickup on commits that probably should've been possible to fast-forward, possibly due to not forcing git to ignore white-space).

Dubious because as a bit of a mercurial fanboy, I think git has a frustrating and opaque command line interface, not helped by the fact that a standard workflow uses various "non standard" (as in: the most obvious) commands. Benefit because learning git is unquestionably a valuable skill, due to the popularity git enjoys, in no small part due to github's success.

I'd like to go back and revisit Fossil at a later time, but right now I'll probably spend any time I can find on (investigating) migrating from gogs to gitlab -- as it's turned out that the limits on pull-requests in gogs make it complicated to use with large groups of people new to version control.

That said, I'm a strong believer in combining wiki, version control and issues in a single repository supporting various DVCS workflows.