View All Revisions Associated With A Ticket

[siegel.adam@…]

I did not see a way to easily determine which revisions are associated with a ticket. Sometimes we keep a ticket open and it has multiple commits against it. It would be nice to see a summary list of commits against a ticket.

[Markus Tacker <m@…>]

Well, you could add ticket number to the commit message and the do a search.

[Emmanuel Blot]

I think this is the exact purpose of the hook scripts, especially trunk/contrib/trac-pre-commit-hook​ and trunk/contrib/trac-post-commit-hook:

You need to specify in the commit message the ticket number the change refers to. The script adds a new comment to the ticket with a reference to the changeset, while the changeset contains a reference to the ticket through the log message and the special wiki syntax for tickets.

[siegel.adam@…]

I think you really need to consider a method for forming a tight coupling between a ticket and a changeset. In the "real world", you have a configuration control board and a test team. The test team has its own copy of the project. The control board approves tickets for testing, not revisions. It is extremely important to say to the test team, please import commits from tickets 5, 8 and 10 (as approved by the board) into your area and regression test. That information needs to be easily calculated. If there was a table that linked ticket number to revisions that would provide the tight coupling.

[Emmanuel Blot]

Feel free to re-open the ticket if you think this should be implemented within Trac.

It seems it's not a small-effort task: adding an extra table for this kind of tracking can be easily done (you can do it from the hook script as well), but it means that you also need some kind of GUI to manage this information. Maybe that is something that could be addressed by TracCrossReferences ?

[Christian Boos]

Indeed, the current source:sandbox/trac-xref branch supports simple backlinks between tickets and changesets.

Have a look at the ticket #508, which was the initial request for this feature.

[smashcasi@…]

I also think an explicit relationship between tickets and changesets would be valuable. It fits well with Trac integration - define a significant feature in a wiki page, which in turn references tickets for its implementation, which in turn reference the changesets that actually implemented the feature.

The xref implementation offers such linking, but I think integration into the change history for the ticket is also worthwhile. For example, looking at a ticket I could see a changeset followed by additional comments on the change (i.e. "nope, still doesn't fix the issue for me"), followed by another changeset that fully resolved the issue.

While the hook script solution works for this, a Trac-side implementation would offer consistent behavior across all supported source-control systems in the future, without the need for additional setup.

[Christian Boos]

The xref implementation offers such linking, but I think integration into the change history for the ticket is also worthwhile. For example, looking at a ticket I could see a changeset followed by additional comments on the change (i.e. "nope, still doesn't fix the issue for me"), followed by another changeset that fully resolved the issue.

The xref implementation does exactly that. In the Cross-references page of a ticket, you'll see all the multiple references to a changeset, sorted from the most recent to the oldest, each with its context (the still doesn't fix the issue for me in the above example).

In addition, if you activate the semantic_wiki configuration switch, you're even able to explicitely associate an explicit relation to the reference, e.g. <<introduced-in [1234]>>.

In the future, I'll add support for custom fields that can be dedicated to manage a given relation, e.g. a Fixed by field.