Edgewall Software

Opened 17 years ago

Last modified 11 years ago

#508 new enhancement

'Related checkins' feature

Reported by: dobes Owned by:
Priority: normal Milestone: unscheduled
Component: ticket system Version: 0.7
Severity: normal Keywords: xref
Cc: gary.wilson@…, chris-r@…, kevin@…, braden@…, mikko.rantalainen@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Christopher Lenz)

In CVSTrac, a ticket has a field called "Related Checkins" which shows a list of checkins (they would be changsets in trac) and their comments.

You can add and remove from this list by editing a comma-seperated list of related checkins.

However, the most useful part, is that by putting a ticket number into your checkin message, it automatically adds that checkin to the "Related Checkins" of the ticket.

Eg. svn commit -m 'Added the ability to edit existing tickets. This fixes ticket #411'

Then when you view the ticket #411 you can see that checkin there without doing any more work.

This feature made CVSTrac sooo useful, because it was very easy to make this connection from the ticket to the checkins that attempted to fix it.

bonus marks:

The whole idea of two-way linking useful in general — once you had this feature you might also show wiki pages linking to a ticket, or tickets linking to a wiki page. Often with information given by people, the incoming links are as relevant as the outgoing ones.

BUT the automatic pingback from the checkins to the tickets is by far the most useful!

Attachments (0)

Change History (27)

comment:1 by Christopher Lenz, 17 years ago

I think source:trunk/contrib/trac-post-commit-hook addresses the automatic linking of changesets with tickets. Though I haven't tried it yet myself.

comment:2 by Jonas Borgström, 17 years ago

Priority: highnormal
Severity: normalenhancement

Sounds like a job for a subversion hook-scripts and a custom field. At least it shouldn't block 0.7.1

comment:3 by bsoudan, 17 years ago

An implementation suggestion. I'll provide a patch if this method sounds good, I use something close to this with custom scripts that I'd like to integrate into Trac:

1) Parse related ticket data from log message in sync.sync. Store data in a new table that maps revision numbers to tickets. (rev-ticket-map: revision number, ticket)

If a standard merging procedure is followed that specifies revision ranges and branches (e.g. merge from 0.7.1: r12345:12500), this parser can even be fancy enough to pull tickets from the commit messages from the merged revisions! e.g. r20000 is "merge from 0.7.1: r12345:123500", which pulls in tickets #1111, 1112, and 1212 from branch 0.7.1. So you'd have three entries in the map table: 20000 : 1111, 20000 : 1112, 20000 : 1212.

2) Ticket module can simply query mapping table to determine related checkins. (e.g. SELECT rev FROM ticket-rev-map WHERE ticket=12345)

Advantages vs. hook script and custom field:

1) No hook script or custom field required. :)

2) While developers are learning the process, I found I had to change the regexp that parses related ticket data from the log message. I also manually changed a few log messages after the developer had committed. A simple resync will fix up all the links in Trac. It'd be more complicated with a custom field and a hook-script.


1) No way to attach commits without the ticket referenced in the commit? But I'd argue it's better to change the log message and resync, anyway, shouldn't a commit message reference all related tickets?

Further ideas:

1) Reporting based directly on revision-ticket mapping, e.g. Which tickets have been committed to branches/0.7.1?

2) Might be a good idea to turn this into a ticket activity table, to handle reverts and merge activity. e.g. rather than a simple mapping, it could be something like:

(rev-ticket: rev, action, ticket, source branch, source rev)

20000 integrate 1234 20001 integrate 1250 20002 revert 1250 20003 integrate 1111 from /branches/0.7.1:r12348 20003 integrate 1112 from /branches/0.7.1:r12350 20003 integrate 1212 from /branches/0.7.1:r12412

where commit activity was:

20000 - commit ticket 1234 20001 - commit ticket 1250 20002 - revert ticket 1250 20003 - merge from /branches/0.7.1: r12345:r12500

3) Turn commits without related tickets into 'mini-tickets' somehow. Here, they show up in my integration report as 'r12345' with a short description taken from the first line of the commit message. I'm haven't thought much about how this would fit into Trac, though.

comment:4 by bsoudan, 17 years ago

I've put a bit more time into this. I decided to go with the activity table rather than the simpler rev → ticket map. Details:

1) parse log messages in sync(), create entries in revision_activity table, schema:

CREATE TABLE revision_activity (
        rev             integer,
        path            text,
        source          text,
        action          text,
        ticket          int

where rev is the revision #, path is the common path, action is 'integrate' or 'revert', ticket is ticket number. source is there to track the source of a merge.

Example of how commits translate into activity records:

revpathlog message
1/trunksome work
2/trunksome more work
3/trunkticket #1234: some bugfix
4/trunkticket #1235: some new feature
5/trunkmisc change
6/branches/branch1ticket #1236: bugfix on branch1
7/branches/branch1some other work
8/branches/branch1ticket #1240: new feature on branch1
9/trunkmerge from /branches/branch1: r0:8
10/branches/branch1revert r8
11/trunkrevert r4

Resulting activity:


2) Display related ticket activity on each ticket page. Simply pull out all records from revision_activity that match ticket #.

Future ideas:

1) Revision activity reports.

comment:5 by daniel, 17 years ago

Milestone: 0.80.9

comment:6 by Christopher Lenz, 17 years ago

Description: modified (diff)
Milestone: 0.9

comment:7 by Christian Boos, 17 years ago

Milestone: 0.9
Owner: changed from Jonas Borgström to Christian Boos
Status: newassigned

Though not going as far as what was suggested by bsoudan, I think that the TracCrossReferences fulfills the original intent expressed in this ticket:

  • from a given ticket, you can automatically reach all the changesets that mention the ticket (and see enough context to see what kind of activity was done for the ticket)
  • from a given changeset, you can see all the tickets that mention this changeset

comment:8 by Christopher Lenz, 16 years ago

Milestone: 0.91.0

Postponed to 1.0.

comment:9 by Christian Boos, 16 years ago

Keywords: xref added

comment:10 by Russell Hind <rhind@…>, 15 years ago

Cc: rhind@… added

comment:11 by anonymous, 15 years ago

Cc: gary.wilson@… added

comment:12 by chris-r@…, 15 years ago

Cc: chris-r@… added

comment:13 by anonymous, 15 years ago

I started out with a simple macro [[DisplayCheckins(782)]] that accessed svn every time, but that was far too slow. If trac could somehow be persuaded to keep a cached copy of svn log --xml in memory, then that structure could be accessed fast enough to not slow down ticket display.

The best of all solution was if a short-hand for the changes was available to use in Wiki. That would be really cool. We are running out of letters, but something like changes:#783 or ?#783 would be great.

Note: By suggesting that the number comes first the listings in timeline, log and changeset listings will be easier to read since the cut-off will take out some text and not the ticket number.

comment:14 by root@…, 14 years ago

This seems like such a basic feature I'm amazed it hasn't made it in yet. This is the only thing I consistently curse about trac, in almost every other way trac is perfect.

The post commit hook suggested in #1495 (and here, I suppose) isn't what I'm really looking for. I'm looking for a standing list of all changesets that mention that ticket with standard trac wiki syntax: #508 or ticket:508

1.0 seems like a looooong way, I would think .11 is more like it. Are there plans to merge the xref branch to trunk?

comment:15 by Christian Boos, 14 years ago

See ChristianBoos#NextSteps. As you can see there, the TracCrossReferences project has a few prerequisites, but it should nevertheless come before 1.0 ;-)

comment:16 by anonymous, 14 years ago

Hey christian, crossing my fingers for 0.11 :) Thanks for the response.


comment:17 by Christian Boos, 14 years ago

For the impatient, #6817 has a patch on 0.11 which implements this feature.

comment:18 by anonymous, 14 years ago

Cc: kevin@… added

comment:19 by elektromin, 13 years ago

Oh, I'm so dissapointed. I've just spent a few days getting my trac installation up and running, and my number #1 expected feature (that I just assumed were there) isn't implemented yet… :-(

Please fix this! Pretty please!! ;-)

in reply to:  19 comment:20 by ebray, 13 years ago

Replying to elektromin:

Oh, I'm so dissapointed. I've just spent a few days getting my trac installation up and running, and my number #1 expected feature (that I just assumed were there) isn't implemented yet… :-(

Please fix this! Pretty please!! ;-)

Take a look a the trac-post-commit-hook (assuming you're using SVN). It's not perfect, but it's very useful for this functionality.

comment:21 by rhind@…, 13 years ago

How do I remove myself from this list? My attempts to modify this ticket are getting rejected as spam.

comment:22 by rhind@…, 13 years ago

Cc: rhind@… removed

Trying again with a comment.

comment:23 by rhind@…, 13 years ago

It seems that if I don't enter a comment when removing from the cc: list it gets rejected as spam. Is that really necessary or a bug in the spam checker?

comment:24 by Braden McDaniel <braden@…>, 13 years ago

Cc: braden@… added

comment:25 by Christian Boos, 11 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:26 by Christian Boos, 11 years ago

Milestone: triagingunscheduled
Owner: Christian Boos removed
Status: assignednew

See Mikael's TracHacks:TracTicketChangesetsPlugin.

Eventually "core" or "tracopt" one day?

comment:27 by Mikko Rantalainen <mikko.rantalainen@…>, 11 years ago

Cc: mikko.rantalainen@… added

Modify Ticket

Change Properties
Set your email in Preferences
as new The ticket will remain with no owner.
The ticket will be disowned.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from (none) to anonymous. Next status will be 'assigned'.

Add Comment

E-mail address and name can be saved in the Preferences .
Note: See TracTickets for help on using tickets.