[patch] Showing related changesets on a ticket

[kevin@…]

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:

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

[kevin@…]

Screnshot of a ticket with changesets

[kevin@…]

Patched against trunk@6505

[cboos]

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.

[kevin@…]

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

[kate@…]

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!

[kevin@…]

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!