Hi!

I'm using Fossil for some days in a toy project and I'm pretty happy with it. Thanks for the great work!

The repository part is simple and elegant, but I've been a bit confused about things that Fossil can do beyond storing and versioning files. The documentation seems scattered. Maybe a page listing all fossil capabilities would be a good idea? (please, let me know if there is already one).

One thing I found confusing is that I expected to easily find CLI counterparts for web operations. It might not be really useful in some contexts (answer to a forum thread?) but maybe it would be useful in others: I've now learnt how to create or change a ticket using fossil ticket add or fossil ticket set but I couldn't figure out how to add user comments to tickets so I don't have to launch the ui to just add a note to it. Please, again, forgive me if I just didn't find it. Is it possible?

Hello,

Maybe a page listing all fossil capabilities would be a good idea?

The What is Fossil? on the homepage lists what Fossil is. Is this what you're expecting?

You can view all available commands (for web or cli) at the help page.

Do those links help? Maybe you could draft up a simple sample page of what you're describing to give us on the forum an idea of what you're thinking.

Maybe a page listing all fossil capabilities would be a good idea? (please, let me know if there is already one).

As of a week or so ago you can do that with:

fossil help --everything > afile.md

Seriously, though - fossil can do so much, that there's no sensible way to pare it down into a one-page description. The "permuted index" provides a fairly comprehensive list of all of the docs:

https://fossil-scm.org/home/doc/trunk/www/permutedindex.html

except for built-in command help text:

https://fossil-scm.org/home/help

One thing I found confusing is that I expected to easily find CLI counterparts for web operations.

Not all web operations have CLI counterparts, and vice versa. e.g. you won't find a merge or checkin features anywhere in the UI.

It might not be really useful in some contexts (answer to a forum thread?)

It seems unlikely to me that answering a post via the CLI would be useful except for simple one-line responses. Finding the proper UUIDs and typing in the response on the CLI would probably take at least as long as starting up fossil ui and typing it in (remember that the forum data uses the same distributed model as the rest of the framework, so you can edit posts offline on any repo for which you have push access). That said: patches are gladly considered.

I've now learnt how to create or change a ticket using fossil ticket add or fossil ticket set but I couldn't figure out how to add user comments to tickets so I don't have to launch the ui to just add a note to it.

The ticketing system does not have a full CLI counterpart. Patches which flesh it out are gladly considered.

Is it possible?

Possible, yes, but the features which tend to get implemented are those which scratch an itch of a contributor. So far nobody's been bothered enough by the lack of a CLI interface for tickets that they've committed to putting in the effort to remedy that. (Patches are gladly considered...)

The What is Fossil? on the homepage lists what Fossil is. Is this what you're expecting?

You can view all available commands (for web or cli) at the help page.

Do those links help? Maybe you could draft up a simple sample page of what you're describing to give us on the forum an idea of what you're thinking.

They help, thanks. I've already read them. I thought of an "expanded version" of What is Fossil?. Maybe something like this:

This is a list of everything Fossil can do:

• Repository - Version control
• Forum - description
• Wiki - description
• Technotes - description
• Tickets - description ... - ...

I mention this because I found technotes almost by chance, when investigating fossil help wiki output. BTW, they are, IMO, a different thing than wikipages, shouldn't they deserve their own command? On the underlying structure they might be almost the same thing, so I imagined it makes sense if you see from the implementation point of view.

BTW, they are, IMO, a different thing than wikipages, shouldn't they deserve their own command? On the underlying structure they might be almost the same thing, so I imagined it makes sense if you see from the implementation point of view.

Though it's probably not obvious as an end use, internally technotes are a special case of wiki pages (same for forum posts). Separating them into a separate command would end up duplicating identical functionality or redirecting both features into the same internal APIs, resulting in no technical benefit and the burden/overhead of separating them.

FWIW, we've yet to have anyone object to the technotes being bundled in the wiki CLI command.

As of a week or so ago you can do that with:

fossil help --everything > afile.md

This is very useful. I've just cloned fossil so I could run this command. I ended doing a lot of fossil help --everything | grep foo! Thanks :-)

Seriously, though - fossil can do so much, that there's no sensible way to pare it down into a one-page description. The "permuted index" provides a fairly comprehensive list of all of the docs:

https://fossil-scm.org/home/doc/trunk/www/permutedindex.html

except for built-in command help text:

https://fossil-scm.org/home/help

The help page is very useful, but there are different things cluttered in one command (technotes and wikipages) and others spread among different commands (repository management). The Permuted Index is a bit confuse. Please, see my answer to sean.

Possible, yes, but the features which tend to get implemented are those which scratch an itch of a contributor. So far nobody's been bothered enough by the lack of a CLI interface for tickets that they've committed to putting in the effort to remedy that. (Patches are gladly considered...)

Nice! Contributing to Fossil something I want to do when I have some free time. Maybe addressing some of the issues I pointed above?

Thanks for the great work again!

Maybe addressing some of the issues I pointed above?

If it scratches a personal itch of yours and fits within the overall project, we're generally happy to receive. Note, however, that checkin access to the project requires having a contributor agreement on file with Richard. See:

https://fossil-scm.org/home/doc/trunk/www/copyright-release.html

With that filled out, signed, and mailed to Richard, commit access is granted. He keeps them safe and sound in a fire-proof safe.

Maybe a page listing all fossil capabilities would be a good idea?

If your intent is to familiarize yourself with Fossil for practical use (as opposed to evaluate it for all possible uses), then the best way, in my own experience, would be to just start using it for the immediate need. Step-by-step a new need may pop, which prompts you to get another piece of useful knowledge.

Otherwise, the sheer volume of features and design details may simply be easily overwhelming and only serve to distort your understanding of Fossil for practical use. Just as Git, not a bad DVCS as such, but it overwhelms users from the start, thus many consider it complex and hard to remember. Fossil could be that too, but in Fossil case, there's a simple route -- the practical use is rather straightforward, and progressively lets one discover features on-demand so to speak.

I hope you were able to locate "The Book" (The Schimpf's Fossil Book), which so far is the most gentle and practical introduction to Fossil use.

I couldn't figure out how to add user comments to tickets so I don't have to launch the ui to just add a note to it. Please, again, forgive me if I just didn't find it. Is it possible?

Just as you learned how to change tickets's fields using CLI, the "User Comments" field is "icomment".

fossil ticket change the-ticket-id icomment "Changed the user comments"

You can list the ticket's fields as:

fossil ticket list fields 

Is there room for change or you are very committed to keep this as it is because of backwards compatibility? (I'm OK with either answer, I just wanted to know :-))

i suspect that the ticket CLI command simply doesn't get much use, so it has never been really refined to be a tool one can use productively. We certainly don't get many posts about it in the forum. If you have patches which improve upon it, we'd certainly like to see them.

While we generally go out of our way to keep backwards compatibility, it would genuinely surprise me if there were any strong objections to improving the ticket CLI.

While we generally go out of our way to keep backwards compatibility, it would genuinely surprise me if there were any strong objections to improving the ticket CLI.

Agreed, and even more true for the web UI.

I have added some project ideas relating to ticketing both in Fossil and libfossil to the GSoC projects page . It's ideal for a mid-level student project, because all of the underlying systems are solid, it's just about matching developer workflow to a user interface.

I needed to review the status of other free software ticketing projects for non-Fossil purposes. There are still very few good candidates, and I realised it would be a really good idea if the Fossil ticketing system became more usable.

Dan Shearer dan@shearer.org

I have added some project ideas relating to ticketing both in Fossil and libfossil to the GSoC projects page . It's ideal for a mid-level student project, because all of the underlying systems are solid, it's just about matching developer workflow to a user interface.

These last days I thought a lot about that. Although I'm probably not eligible for GSoC, I'd be happy to work on that if no one takes it. This looks like the perfect project to get familiarized with fossil internals before jumping into more complex projects.

I needed to review the status of other free software ticketing projects for non-Fossil purposes. There are still very few good candidates, and I realised it would be a really good idea if the Fossil ticketing system became more usable.

Not completely related but my plan was that, after refactoring ticket UI/CLI, work on some kind of integration with email (some discussion here) that would allow someone to almost completely work with tickets and the forum via email. I think that some (most?) bug tracking systems support that. The one that comes up in my mind right now is the old but good GNATS, although it is not something that would be used as a reference for "modernization".

Not completely related but my plan was that, after refactoring ticket UI/CLI, work on some kind of integration with email (some discussion here) that would allow someone to almost completely work with tickets and the forum via email. I think that some (most?) bug tracking systems support that. The one that comes up in my mind right now is the old but good GNATS, although it is not something that would be used as a reference for "modernization".

I agree email support both inbound and outbound is important IMHO for ticketing systems. Another example besides GNATS is the roundup issue tracker as an more modern example. It can even use sqlite as its backend. (Note I am a developer/release engineer for roundup and use fossil to manage a custom roundup tracker.)

By silasdb wrote on 2021-02-24 16:45:55:

I'd be happy to work on that if no one takes it.

People are more likely to take it if you work on it first :-) There are plenty of subprojects, enough for everyone.

As per the discussion you referenced, email integration for tickets could certainly work in the same way as proposed for bounce handling. If an MTA injects an email using "fossil email -R repo receive_ticket" containing a hash we generated, then we accept that email otherwise we reject it. There might perhaps be boundary conditions such as "the hash can't be more than six weeks old".

Implementing "email receive_*" would solve multiple problems at once, including some that haven't been mentioned in these threads yet.

Dan Shearer

People are more likely to take it if you work on it first :-)

Agreed :-)

So, where do I begin? I mean, I've started to take a look at the code (which I imagine is not very complex -- and I have previous experience with C) and I've been reading Fossil documentation and trying Fossil itself a lot, but I need a place or someone to ask questions to. The forum would get polluted with technical small questions, so there might be somewhere else.

So, where do I begin? I mean, I've started to take a look at the code (which I imagine is not very complex -- and I have previous experience with C) and I've been reading Fossil documentation and trying Fossil itself a lot,

The ticket code is actually surprisingly twisty because it's so configurable. Most of fossil's data structures are very fixed, but the ticket engine is almost entirely malleable.

but I need a place or someone to ask questions to. The forum would get polluted with technical small questions, so there might be somewhere else.

The forum is the right place, but the fossil:/chat room (open to all with checkin access) is also useful if you're concerned about noise pollution. We briefly tossed around the idea of a dev-only forum at some point, but that's not seemed worth the effort so far. Whether or not anyone is listening in the chat room is hit and miss, though, as we're scattered around the world in many time zones.

silasdb wrote on 2021-02-24 17:59:45:

So, where do I begin?

Maybe with this minor fix: a heading on the first line of a ticket is ignored.

See this ticket and then compare the plain text version.

This is using Fossil trunk as of yesterday.

Dan Shearer

Maybe with this minor fix: a heading on the first line of a ticket is ignored.

Tip: fossil generally strips the first header line for use as the page title. You'll need to figure out how to turn that off for this context. (i'm on a train or i'd point out some source code.)