Clicking on the tags in /taglist dows not show technotes
(1) By Norbert (NorbertK) on 2022-11-25 14:00:10 [link] [source]
Hello all,
i use fossil for the ansible scripts which define my environment and find it very handy to document all work on the system(s) in one place .
So I write short technotes when i update a major piece of software interactively , like for exampe nextcloud. I experiment with Tags in this context.
When i use /taglist in the web interface i see the tags, when I click them I see no checkins, which is correct, because there are none.
I assumed it would show all kinds of artifacts relating to this tag. I adjusted my timeline settings accordingly so that everything is shown in /timeline, but the link from the taglist (in the form xxx/timeline?t=<Tagname>seems not to honour this setting.
Would it make sense to chnge the software in this regard ?
Thanks alot
Norbert
(2) By Stephan Beal (stephan) on 2022-11-25 15:13:53 in reply to 1 [link] [source]
I assumed it would show all kinds of artifacts relating to this tag.
Historically, fossil only supported tags on checkins. It was only relatively recently extended to support propagating tags on all artifacts which can have parents (wiki, technotes, and forum posts), but few of its tag-using features have been updated to deal with those other types.
Would it make sense to chnge the software in this regard ?
It would, we just need a volunteer to do write the code :).
Sidebar: fossil's data model supports tagging anything, even another tag, so any such feature changes don't require changes to the data model.
(3) By matt w. (maphew) on 2023-02-27 04:59:13 in reply to 2 [link] [source]
I think this thread is talking about the same experience I've just had:
- Create a new technote in web ui and assign it tags
meta, cms - Later create another technote and assign tag
meta - In timeline view click on tags: 'meta': I expected to see both of the previous technotes but instead am told '0 check-ins related to "meta"'.
A trip to Branching doc and jumping down to Tags heading quickly reveals "A tag is a name that is attached to a check-in." Hmm. right, these are not checkins. Then here in this thread we have:
...extended to support propagating tags on all artifacts which can have parents (wiki, technotes, and forum posts) ... It would [make sense to change the software in this regard] we just need a volunteer to do write the code :).
I don't know C, python is my game thus far, but I'll try see if I can figure something out. Where should I start?
(4) By Stephan Beal (stephan) on 2023-02-27 06:02:04 in reply to 3 [source]
I don't know C, python is my game thus far, but I'll try see if I can figure something out. Where should I start?
The /brlist page is possibly the lowest-friction starting place, the code for which can be found by searching src/branch.c for "E: brlist". The db schema for the tags can be found in src/schema.c in the tables "tag" and "tagxref". The "tag" table holds all unique tag names and "tagxref" maps those tags to the artifacts which have them.
That said...
Implementing tags for technotes, forum posts, and wiki pages has a significant caveat which only became clear to me over the past week while working on a new forum feature which makes use of them...
Tags come in 2 flavors: "standard" tags are applied to one specific artifact (so one specific version of a forum post, technote, check-in, or wiki page). Propagating tags apply to a given version, and all subsequent versions, until the point in the history where the tag is cancelled. e.g. when a check-in is branched from another, as happens via the "ci" command's --branch NAME flag or the "branch new" command, the new checkin gets the new branch's name applied as a propagating tag and the prior branch name's tag gets cancelled so that it no longer applies to check-ins in the new branch. The older branch tag continues to propagate along the branched-from checkin, however.
When applying tags to technotes, wiki pages, and forum posts, it will almost always be desirable for the tag to apply across the item's full history. Doing so requires applying a propagating tag to the first version of that item (and only the first version). Applying non-propagating tags means that only the tagged version of the given item is tagged, which will only rarely be useful for non-check-in artifacts.
That is to say: it's not simply a matter of slapping tags onto objects and searching for them later. Care has to be taken that the proper type of tag is applied to the proper version(s) of objects. The forumpost-close branch contains some documentation about this quirk, along with code which uses a tag for "locking" forum posts.
(5) By matt w. (maphew) on 2023-02-28 05:37:39 in reply to 4 [link] [source]
Thank you Stephen! Once I get my build environment sorted I'll start trotting down that path, and report back on any progress I might make.