#6817 closed enhancement (duplicate)
[patch] Showing related changesets on a ticket
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | ticket system | Version: | |
Severity: | normal | Keywords: | |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal 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.
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)
Change History (6)
by , 17 years ago
Attachment: | screenshot.PNG added |
---|
comment:1 by , 17 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 by , 17 years ago
Ouch, I guess I didn't search the existing tickets well enough then :) Thanks for letting me know.
comment:3 by , 17 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 , 17 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!
Screnshot of a ticket with changesets