Modify

Opened 12 years ago

Last modified 4 years ago

#9902 new enhancement

Repositories tags

Reported by: chris.burroughs@… Owned by:
Priority: normal Component: TagsPlugin
Severity: normal Keywords: repository tag provider
Cc: 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 (8)

comment:1 in reply to:  description Changed 12 years ago by Steffen Hoffmann

Cc: Ryan J Ollos added; anonymous removed
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 12 years ago by Ryan J Ollos

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 12 years ago by Steffen Hoffmann

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 12 years ago by Steffen Hoffmann

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 11 years ago by Steffen Hoffmann

Btw, #2404 is certainly related.

comment:6 Changed 8 years ago by Ryan J Ollos

Owner: Steffen Hoffmann deleted

comment:7 Changed 6 years ago by Ryan J Ollos

Summary: tags for repositoriesRepositories tags

comment:8 Changed 4 years ago by Ryan J Ollos

Cc: Ryan J Ollos removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The ticket will remain with no owner.

Add Comment


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

 
Note: See TracTickets for help on using tickets.