Edgewall Software
Modify

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#6817 closed enhancement (duplicate)

[patch] Showing related changesets on a ticket

Reported by: kevin@… Owned by: Jonas Borgström
Priority: normal Milestone:
Component: ticket system Version:
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:

Description

Attached is a small patch that adds a list of related changesets to the ticket view. (By related changeset, I mean those that reference a ticket in the commit message, in the form #nn). The extra section is only shown if there are any changesets to link to for that ticket; otherwise it looks the same as before.

It looks like: Screnshot of a ticket with changesets

We've been using a patch like this where I work for a year or so now, and we've found it to be really helpful (especially in conjunction with TortoiseSVN's bugtraq:warnifnoissue and bugtraq:logregex properties). I wondered if anyone else would like to see this sort of thing in a future release?

(I did see that there is an xref branch that looks like it will address this type of thing, along with a lot more, but I wasn't sure what plans there might be for merging that. This patch is also just for one part of the xref stuff — the part that I found myself wanting — and as such it's a much smaller change.)

It does add a new table (to avoid incurring a full index scan on each ticket view). That will be created in an install or upgrade, but if anyone wants to try the patch on an existing installation you'll need to do something like this:

create table ticket_revision
(
  ticket integer not null,
  rev text not null,
  primary key (ticket, rev)
);
create index idx_ticket_revision_rev on ticket_revision (rev);

I've only tested the code against PostgreSQL 8.2 and 8.3 at this point.

Apologies if this is something that has already been discussed. I did see mention of some similar things on the mailing list a while back, but I just didn't find anything that quite filled my own needs the same way.

Lastly, this is my first time trying to submit anything to this project, so any feedback on the patch/ticket would be much appreciated :)

Thanks, Kevin

Attachments (2)

screenshot.PNG (8.8 KB ) - added by kevin@… 12 years ago.
Screnshot of a ticket with changesets
ticket_references.diff (4.5 KB ) - added by kevin@… 12 years ago.
Patched against trunk@6505

Download all attachments as: .zip

Change History (6)

by kevin@…, 12 years ago

Attachment: screenshot.PNG added

Screnshot of a ticket with changesets

by kevin@…, 12 years ago

Attachment: ticket_references.diff added

Patched against trunk@6505

comment:1 by Christian Boos, 12 years ago

Resolution: duplicate
Status: newclosed

Thanks for your interest to the cross-reference topic. That particular kind of cross-references has been discussed since quite some time (#508).

Hopefully with 0.12 and wikidom (#4431), we'll be able to provide the infrastructure to make this kind of extension more robust.

comment:2 by kevin@…, 12 years ago

Ouch, I guess I didn't search the existing tickets well enough then :) Thanks for letting me know.

comment:3 by kate@…, 11 years ago

Kevin, thanks bunches! I just got the patch working, as far as I can tell. I am running mysql 5.0, so here is a bit of info for you:

I created a table using varchar(255) for rev due to the following error: BLOB/TEXT column 'rev' used in key specification without a key length Rev appears to be a revision number, so might it make more sense to use an integer? Either way, varchar should do the job.

I only have one linked revision so far and it did what it was supposed to - so cudos!

comment:4 by kevin@…, 11 years ago

Hey Kate, glad the patch is proving useful to you. You're right, I should have used a varchar field in the snippet of SQL that I posted. I use PostgreSQL, which has a nice text datatype that doesn't need a length, but it's not the most portable option. Thanks for pointing that out.

It should work fine on MySQL when running setup.py on the patched source though (as opposed to creating the table by hand). At least I think so; I don't have MySQL around to check :)

As for why rev is a text column: it's to match the rest of the schema (e.g. the revision table). I assume that's for forward-compatibility with revision control systems other than SVN, since some of those use revision IDs that are non-numeric. But I could be wrong.

Hope that helps!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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