'Related checkins' feature

[dobes]

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!

[cmlenz]

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.

[jonas]

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

[bsoudan]

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.

Disadvantages:

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.

[bsoudan]

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:

rev	path	log message
1	/trunk	some work
2	/trunk	some more work
3	/trunk	ticket #1234: some bugfix
4	/trunk	ticket #1235: some new feature
5	/trunk	misc change
6	/branches/branch1	ticket #1236: bugfix on branch1
7	/branches/branch1	some other work
8	/branches/branch1	ticket #1240: new feature on branch1
9	/trunk	merge from /branches/branch1: r0:8
10	/branches/branch1	revert r8
11	/trunk	revert r4

Resulting activity:

rev	path	source	activity	ticket
1	/trunk	-	integrate	0
2	/trunk	-	integrate	0
3	/trunk	-	integrate	1234
4	/trunk	-	integrate	1235
5	/trunk	-	integrate	0
6	/branches/branch1	-	integrate	1236
7	/branches/branch1	-	integrate	0
8	/branches/branch1	-	integrate	1240
9	/trunk	/branches/branch1:r6	integrate	1236
9	/trunk	/branches/branch1:r7	integrate	0
9	/trunk	/branches/branch1:r8	integrate	1240
10	/branches/branch1	-	revert	1240
11	/trunk	-	revert	1235

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.

[cboos]

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

[cmlenz]

Postponed to 1.0.

[anonymous]

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.

[root@…]

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?

[cboos]

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

[anonymous]

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

_a

[cboos]

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

[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!! ;-)

[ebray]

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.

[rhind@…]

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

[rhind@…]

Trying again with a comment.

[rhind@…]

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?

[cboos]

Milestone 1.0 deleted

[cboos]

See Mikael's ​TracHacks:TracTicketChangesetsPlugin.

Eventually "core" or "tracopt" one day?