when a checkin comment features a link to a bug, append a comment to that bug with a link to either that checkin, or the diff of that checkin to previous version. include the checkin comment in the bug comment as well.

<hr><i>kkinnell added on 2008-12-27 18:02:40:</i><br>
This may have been implemented by check-in [426a3ba49ebb066c192e29e62b07a65854e840c7] (in which case I missed something, but it may just be the developer discipline mentioned below.)

If this request hasn't been implemented...

I see the convenience of this, but it's more a matter of developer discipline than anything, isn't it?  I don't think you can actually remove the need for review of the tickets affected by a commit.

Suppose you make a change that affects two tickets, then back it out and commit a change that affects only one of them?  At that point, you'd have a ticket with an "affected by commit" comment and a second "affected by commit" comment, with no effective change in the code.  You surely would <em>not</em> want to back out any other changes to the baseline, so it wouldn't by very safe to back out ticket wiki changes&#8212;you could be "backing out" to a new leaf, instead of the baseline you had at the first commit.

It would be far better to document the "badness" of the original change in the code than to hide it in a commit comment (which may not even mention it) I would think.  This sort of thing may happen more than one would guess, especially if the code is under heavy development.

If this feature hasn't been implemented, it would have to be a toggle.  I think it would be better to make this a Th1 "plugin" and share it around.

<hr><i>anonymous added on 2009-01-09 08:15:41:</i><br>
the checkin you mention seems unrelated to me.

we use this feature in svn heavily at work, in fact ticket numbers are required for checkins, and its very convenient. the idea is a history of the files changed to fix a particular issue. even if you have to back out the change you can see the activity in the ticket and know its related.

a plugin would be fine too. im not going to tell you how to implement something, its just a suggestion.