I recently enabled my own ability to host CGI applications on this site. Thinking on the sorts of capabilities this enables for myself I have spent some time investigating new tools, the most interesting of which is probably Fossil.
Fossil offers a number of different ways of hosting the service from an always-on server and as a CGI application. While there was nothing exactly stopping me from running a server I find it a little more interesting to use it as a service that scales down to zero resources when not in use, especially while I'm only trying things out.
Few things have proven easier to host. Fossil is available in my distribution's package manager or as a binary download. With it downloaded I created a script in my CGI directory for the web server to execute:
#!/usr/bin/fossil cgi
repository: /var/local/fossil/wunderkammer.fossil
And that was it. Assuming there is an open fossil repository at the
path specified (created with fossil init ...
and fossil open ...) it just works. There are access
controls available that I configured to disable some features
etc. but that was after it was all running successfully.
Four-fifths of everybody's work must be bad. But the remnant is worth the trouble for its own sake.
—Rudyard Kipling, The Light That Failed
There are a few quirks to using fossil coming from another DVCS like git or mercurial. The standard configuration enables "autosync" so local commits are pushed (to use git parlance) to the remote. This can be disabled but with it on the feeling is much more like subversion. Fossil more or less disallows rewriting history which is often the first and loudest complaint from other usage reports on the internet. I don't really have such a problem with it so I won't say much more about it except to lead to the next point.
The design of fossil comes from the SQLite project which is styled after the cathedral rather than the bazaar. The idea is that project contributors are adept and understand the goals of project. There is no history rewriting because the fossil authors believe there is value in seeing how a feature developed and where the development dead-ends lay. I think probably this is the real source of problems for people trying to use fossil, the design of the system is for development groups that are significantly more rigorous than the majority of the profession. There are other minor issues like a lack of support for editing comments on tickets or anemic support for a continuous integration system but I think at heart fossil will likely never get broad support because it is intended for better than average groups of users.
Thankfully, there is no such requirement for a single user such as myself. I'm free to make silly mistakes (or not!) and clutter project history with impunity. I don't tend to use things like rebase in my own projects because... why would I? Instead the way I will use fossil is akin to an automatic backup solution, commits are just checkpoints to which I can add comments and branch development. That is basically all I ask of my version control systems anyhow so I'm willing to compromise on these other aspects. What I get in exchange has so far felt worth the trade-off.
It turns out fossil has it's origins in another project cvstrac which was an inspiration for trac, probably the last really useful ticketing and wiki system I have used in a professional context. It is almost no wonder I find fossil appealing.
The ticketing system is about as feature-rich (or poor) as something like todo.sr.ht (I've linked the Hare project ticket tracker for a real-world example) and vastly more usable than something like Jira (it took me multiple minutes of hunting around to even surface the linked ticket list view, I'm linking to Clojure's Jira because it is one of the few publicly accessible Jira boards that I'm aware of) or ClickUp. Sourcehut is probably closest in spirit or design intent than the other two but I have such a bone to pick with enterprise-grade systems that I can't pass up the opportunity to mention how dreadful they are in practice. I think the pursuit of infinitely flexible or configurable systems tends towards products that are less useful for everyone.
The wiki system would be adequate except that it renders quickly and integrates a diagramming language pikchr directly, making it distinctly nicer to use compared to most other wiki systems. One oddity is the distinction between wiki pages and embedded documentation, which is just files within the repository that end up rendered by the same engine but with support for a few dynamic linking features. I think the embedded docs are probably nicer for long-lived documentation for being editable within a preferred editor but for ease of use the wiki has been perfectly fine so far.
Collaboration tools are a little quirky but point to the origins of the project and tendency to centralize everything under one umbrella. Fossil is a homegrown SCM for use with the SQLite project and includes the forum where user questions, feature requests, and development activity is discussed. It also includes a rudimentary chat system and can integrate with mailer daemons for notifications, along with RSS feeds. All in a couple of megabytes!
Compared to my usual work day interactions for software development this all sounds like a bit of a dream. Rather than trying to collaborate with meeting notes across Slack huddles/chats, Teams meetings notes, Lucid whiteboards, Clickup whiteboards, Miro whiteboards, Clickup docs, Slack threads, Teams channels, Clickup tickets, Slack lists, Github issues, Github comments, Github releases, Slack notifications of Github releases, Clickup comments linking to Slack threads with updates about releases, Clickup pages linking to Sharepoint pages containing Excel sheets containing release information -- imagine having just one system.
I was recently looking at an alternative to both git-send-email and
github style pull requests through
the pr.pico.sh project. It seems
like a code review system could possibly be incorporated into fossil
with the /ext CGI extension system or this ssh-based
approach. Fossil supports "bundles" which are a little like
patches++. I'm not sure though that it would really be worth it,
just as easy would probably be to spin up a forum thread to discuss
changes or use chat. In fact that seems to be
how other
projects intend to accept and discuss change proposals.
While I do think it might be fun to try integrating with the CGI extension system I think the best use of fossil is probably as it has been designed. Where something like git might be a toolbox to sift through to find pieces that might accomplish what you're trying to do fossil really does seem like A Coherent Software Configuration Management System like it bills itself.
I may dump some occasional notes into a wiki page or try out pikchr for some diagrams. I may well migrate a few half-abandoned projects from git to fossil just to try it out. Generally though I think I'll enjoy a little bit of sanity in the software world at least for a little while.