'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!

[Christopher Lenz]

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 Borgström]

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.