Opened 20 years ago
Last modified 14 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 )
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 , 20 years ago
comment:2 by , 20 years ago
Milestone: | 0.7.1 → 0.8 |
---|---|
Priority: | high → normal |
Severity: | normal → enhancement |
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 , 20 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.
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.
comment:4 by , 20 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:
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.
comment:5 by , 20 years ago
Milestone: | 0.8 → 0.9 |
---|
comment:6 by , 20 years ago
Description: | modified (diff) |
---|---|
Milestone: | 0.9 |
comment:7 by , 20 years ago
Milestone: | → 0.9 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
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:9 by , 19 years ago
Keywords: | xref added |
---|
comment:10 by , 18 years ago
Cc: | added |
---|
comment:11 by , 18 years ago
Cc: | added |
---|
comment:12 by , 18 years ago
Cc: | added |
---|
comment:13 by , 18 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 , 17 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 , 17 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 , 17 years ago
Hey christian, crossing my fingers for 0.11 :) Thanks for the response.
_a
comment:17 by , 17 years ago
For the impatient, #6817 has a patch on 0.11 which implements this feature.
comment:18 by , 17 years ago
Cc: | added |
---|
follow-up: 20 comment:19 by , 16 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!! ;-)
comment:20 by , 16 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 , 16 years ago
How do I remove myself from this list? My attempts to modify this ticket are getting rejected as spam.
comment:23 by , 16 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 , 16 years ago
Cc: | added |
---|
comment:26 by , 14 years ago
Milestone: | triaging → unscheduled |
---|---|
Owner: | removed |
Status: | assigned → new |
See Mikael's TracHacks:TracTicketChangesetsPlugin.
Eventually "core" or "tracopt" one day?
comment:27 by , 14 years ago
Cc: | added |
---|
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.