Fossil Forum
Post: Fossil, Fuel, and a Dinosaur
Prompted by a question about committing from the Fossil UI:
I started using Fossil in 2017, and one of the reasons I chose it was because it had a nice point and click style add-on called Fuel. This gives what I would call a checkout-centric view, complimentary to the web based fossil ui which I call repository-centric. Both have their uses, and I believe there is reason to keep them separate.
Does anybody else use this? Or its apparent successor Diesel which I found today. Or something else?
The main benefit I find is that I frequently want to choose just a subset of changed / added files for a commit, and this is just a question of ticking boxes. I am also an occasional user, and old to boot, so don't have instant recall of exactly what the commands and their parameters are.
I still use Fuel in spite of some shortcomings - it seems to have problems with any kind of concurrency, so will sometimes omit a changed file from the view, and has issues with switching between repositories/checkouts. One thing I am grateful for is that Fossil itself seems to have a stable enough interface that Fuel still works even though it was written against a Fossil version nearly 10 years old.
I use Visual Studio Code with this Fossil extension, which integrates with VS Code's built-in source code control features.
I find it complements the Fossil UI fairly well; it shows which files were added, removed, modified, and the extra files as well; clicking on one will show the changes since the last commit. Also, the status bar shows the current branch.
Instead of ticking boxes, you can ‘stage’ files. When committing, only the staged files are committed. If no files have been staged when you commit, the extension will ask if you just want to commit all the changed files, allowing you to cancel if that was not your intention. Z 2
Thanks Martijn. VSCode is on my list of things to look at regarding whether it works alongside the gadget I am working on, perhaps I should get on with that. I wasn't aware there is a Fossil add-on for it.
Meanwhile I am not sure I want to swap editors until forced to do so by a change to Fossil or the discovery of some bug in Fuel. Time will tell if that is a good decision or not.
Cheers, Trevor
VSCode is on my list of things to look at
It's eating the world for a reason, and it isn't because of monopoly pressure this time. This time, Microsoft decided to try for exceptionalism, and nailed it.
Key to my adoption was the Neovim plugin, which obsoleted all the prior Vim emulations by taking the novel approach of running an actual instance of Neovim underneath. This not only means they don't have to chase implementation details dating back to 1979, non-UI Vim settings and Neovim plugins affect VSCode as well. It is by this means that I finally taught VSCode the "go to next/prev function" trick.
If you're not a Vimmer, I remain confident that your editor of choice has a competent emulator extension.
there is a Fossil add-on for it.
Yes, and it's pretty good. The few problems it has are straightforward to work around:
-
Its UI retains certain Git concepts like staging. I don't know if this is because VSCode thinks everything is Git and pushes that out through its extension API, or because this Fossil extension forked from a Git one, or what.
-
It polls the repo a lot, and apparently in a read-write manner such that you'll start seeing a lot more DB lock failures while it's up and running. It should use a read-only lock most of the time, but it also might be pilot error: I had about half my local repos in DELETE mode. I've just switched them all into WAL mode; we'll see if that helps.
Regardless, I mainly use the Fossil extension for visual diffing with live editing before dropping into the terminal to do the actual commits.
I had about half my local repos in DELETE mode. I've just switched them all into WAL mode; we'll see if that helps.
Is that something you can configure Fossil to do initially (or when cloning)? I don't remember ever explicitly setting that...
The db lock failures can be bothersome, indeed.
Either:
fossil rebuild --wal
or:
fossil sql 'pragma journal_mode=WAL'
Is that something you can configure Fossil to do initially (or when cloning)?
No, because WAL has restrictions that make it unsafe to do that unconditionally.
Admins who know they're in a safe conditions for this can either say1E@36,W:91779418e0904482e2a51f3a52eb743 bqBEq;
Is that something you can configure Fossil to do initially (or when cloning)?
No, because WAL has restrictions that make it unsafe to do that unconditionally.
Admins who know their use of Fossil falls under the safe condition set can either say:
fossil rebuild --wal
or:
fossil sql 'pragma journal_mode=WAL'
I agree with Warren about VSCode. Something I haven't tracked down yet, though, is how to always permit remote files to be opened in VSCode. By default, it wants to you whitelist hosts. That is a reasonable security procedure, but as a result, it makes VS Code more difficult to use in those circumstances.
The fossil plugin for VS Code worked well for when i used a few years ago. I do think i would prefer a method of checking files to commit instead of the staging that Warren was talking about. I seem to also recall some issue where if you had the repo opened but no active files in the editor, dragging a file into the editor would want to add it to the repo. That was probably more of me abusing VS Code and the plugin more than an issue with the plugin.
Oh, another thing about VS Code, i haven't seen the ability to print a file to paper. I don't think it's ever had that functionality and probably a design decision, but sometimes I want to print something without using MS Word or another text editor.