RFC: Better machinery for tickets with elaborated description

(1.1) By george on 2022-05-22 21:49:27 edited from 1.0 [source]

Fossil's ticketing subsystem has a couple of shortcomings for the case when tickets typically have elaborated description and that description is amended (more-or-less) frequently:

There is a lack of quick and easy way to see what exactly has changed in the description of a ticket (no diff's).
Ticket change artifacts that convey small changes in the description do not pass through the delta-compression and thus do not enjoy the corresponding reduction of disk-usage.

I see two possible ways to resolve these shortcomings.

The first way is to implement the missing pieces in the ticket subsystem, which might require:

A TH1 command that computes diff's for a pair of strings.
Perhaps this command also should handle long lines nicely (as suggested elsewhere).
A setting that holds name(s) of ticket field(s) that may be worth for delta-compression.
Changes to the ticket_put() function to actually store the appropriate ticket-change artifacts using delta-compression.

The second way is to treat specially-named wiki pages (i.e. "ticket/1234abcd...") as a description for the corresponding ticket, which might require:

A special SQL function that decodes wiki artifacts (a TH1 command could also do the trick, but SQL function may have more applications).
Amendments and redirects to some web pages (/wiki, /tkthistory and maybe a few others)
Amendments to some timeline SQL queries (so that changes to this specially-named wiki pages are treated as ticket changes).
Some filtering in the sync machinery to prevent the flow of these specially-named wikis to/from the unauthorized users.

A side-benefit from resolving these shortcommings would be a possibility to setup a repository in such a way that ticket subsystem is actually used as a sort of advanced knowledge management system, where "articles" can have many attributes and complex filtering queries. This may also be somewhat related to the markdown-tagrefs feature.

I do not yet have a strong opinion on which way is better. The first way seems easier to implement correctly.

Please comment on the topic.
Is it a good idea to resolve these shortcomings of the ticketing subsystem? Which way seems better? Do you see some yet unmentioned obstacles?

(2) By Stephan Beal (stephan) on 2022-05-22 22:26:03 in reply to 1.1 [link] [source]

Fossil's ticketing subsystem has a couple of shortcomings ...

i would be very surprised if anyone would object to someone improving and cleaning up the ticketing system :).

Changes to the ticket_put() function to actually store the appropriate ticket-change artifacts using delta-compression.

All you need for that is the RID of the parent record (if any). If there's not a logical parent record then it's going to be difficult to guess what it should be delta'd against. In theory, any artifact can be a delta of any other artifact, but in practice, deltaing against the prior version of an artifact will provide the best compression.

Is it a good idea to resolve these shortcomings of the ticketing subsystem? Which way seems better? Do you see some yet unmentioned obstacles?

i don't use the ticket system often enough to have any strong opinions on it, but have the opinion that a general cleanup of the UI and any related infrastructure cleanups which go along with that would certainly be welcomed.

This may also be somewhat related to the markdown-tagrefs feature.

Tickets could benefit from hashtag support similarly to forum posts and (potentially) wiki pages. The ability to search and filter by tags (whether they are hashtags or fossil tags) would be a nice capability, especially for tickets. Both approaches (hashtags and fossil tags) have benefits and downsides, though, and it's not clear to me which one would be the overall better choice.