Modify

Opened 2 years ago

Last modified 22 months ago

#9902 new enhancement

tags for repositories

Reported by: chris.burroughs@… Owned by: hasienda
Priority: normal Component: TagsPlugin
Severity: normal Keywords: repository tag provider
Cc: rjollos Trac Release: 0.12

Description

We have a relativly lage number of repositories in a single trac instnace. It would be nice to group them by tags (ie things belonging to team foo, libraries vs daemons etc). I'm not sure if the right approach is to extend the TagsPlugin or if it's sufficiently different that a new plugin is more appropriate.

Attachments (0)

Change History (5)

comment:1 in reply to: ↑ description Changed 2 years ago by hasienda

  • Cc rjollos added
  • Keywords repository tag provider added

Replying to chris.burroughs@gmail.com:

... not sure if the right approach is to extend the TagsPlugin or if it's sufficiently different that a new plugin is more appropriate.

Sure. TagsPlugin data model is ready for tagging any Trac resource by coding an implementation of the ITagProvider for the corresponding Trac resource realm. There are already more than ticket and wiki: screenshot (ScreenshotsPlugin) and blog (FullBlogPlugin). Patches welcome.

comment:2 Changed 2 years ago by rjollos

An extension to the TagsPlugin to support tagging repository paths AND changesets would be enormously useful. Tagging changesets could be used as a tool for code review, or to aggregate regressions into a list.

comment:3 Changed 2 years ago by hasienda

Development note: Code for implementation must accept and work with both, the old one-repo-per-env (0.11) as well as the new multirepos support (>= 0.12).

I've just seen something in the TracStatsPlugin, that could be used as a starting-point to get a grip on these different db schemas. I'd need that, because I use the repository part of Trac so rarely, and never in production by now.

comment:4 Changed 2 years ago by hasienda

Tagging changesets is a nice idea.

How about that: Let's extend versioned (like ticket keywords) and unversioned (like wiki page) tags for all realms. An API change. This way you could configure your IRepositoryTagProvider to tag every new changeset with an unversioned default tag like "new" aka "unseen" that you could flip/delete while doing occasional reviews.

Have more automated tags like "fix", "fix-partly" (if change message includes suitable signals like "closes", "fixes" or "refs"). Optionally copy repository properties like author, branch name, etc. into the tags domain too, as is done with the field name selector list option "ticket_fields" for tickets.

Maybe some other plugins, that use there own schema by now for tracking special aspects of Trac resources, i.e. like WatchlistPlugin, could use a third type of "invisible"/hidden tags, where the TagsPlugin just shares it's db storage backend with other plugins, and optionally could provide a single-point of cumulative show-case and/or admin access per real/resource/user and for admins.

Well, just some ideas, maybe for tags-0.8 and beyond.

comment:5 Changed 22 months ago by hasienda

Btw, #2404 is certainly related.

Add Comment

Modify Ticket

Action
as new .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.