Repositories tags

[chris.burroughs@…]

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.

[Steffen Hoffmann]

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.

[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.

[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.

[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.

[Steffen Hoffmann]

Btw, #2404 is certainly related.