Article:		Bug Trackers: Do They Really All Suck?
Subject:		bugtracker TRAC rocks
Date:		2005-12-12 11:47:45
From:		jeremiah.jahn
Response to: bugtracker TRAC rocks
But how does it integrate with SVN? I see that you can use it view an SVN repository, but how do you say that you have fixed bug X in a particular commit? How do source updates and issues get associated?

Showing messages 1 through 3 of 3.

• bugtracker TRAC rocks
  2005-12-28 12:07:15  ttriche [View]
  
  
  I meant to reply to your message. See my reply above -- Trac integrates with SVN in the same manner that FogBugz does. It would not blow me away to discover that one was "inspired" by the other, although this is a pretty obvious insight once you start using CVS or SVN commit log actions (eg. the ever-popular "mail out the changes" script).
  
  Having seen Joel's writings, I suspect FogBugz is excellent too.

• bugtracker TRAC rocks
  2005-12-15 06:08:07  bazzargh [View]
  
  
  We use FogBugz, which ships with integration to subversion:
  http://www.fogcreek.com/FogBugz/docs/40/Articles/SourceControl/SubversionIntegrationScri.html
  
  actually the integration is pretty simple (Matthew's 'first approach'), and works the same as the their cvs integration did: if you mention the bug# in the commit message, a trigger script tells FB the files that changed in that commit.
  
  In the FB UI you see links to those files. We've set it up to link to viewvc. Actually this integration could be better with svn, because instead of linking to dozens of files (which is what it does) it could just link to the page for that commit in viewvc.
  
  The api is pretty trivial (and hopelessly insecure too...hmm) so if we felt the need, it would be easy to do a 'method #2' scan of commit messages to see if anything was missed.
  
  I'm not suggesting FB is without fault; the prefix for linking to commits isn't per-project, for example, so doesn't scale to multiple repositories.
  
  A few unrelated points:
  #1 - I've tried some commercial solutions with integrated bug tracking (Continuus/CM). Nothing but pain. I'd far prefer something with an open integration story than a closed we-do-everything featureset.
  
  #2 - git-bisect is a pretty damn cool feature for bug hunting, I'd love to have this in other tools:
  http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html
  
  #3 - The insistence of bug trackers on categorization is wrong; you end up with a proliferation of dropdown lists for project, platform, subsystem, release, customer...with inevitable clashes over which list a label should go in (is a customer-specific build a project or a release?) I'd like to see a system which lets you add and remove tags instead.
• bugtracker TRAC rocks
  2005-12-28 12:11:10  ttriche [View]
  
  
  > #3 - The insistence of bug trackers on categorization is wrong;
  > you end up with a proliferation of dropdown lists for project,
  > platform, subsystem, release, customer...with inevitable clashes
  > over which list a label should go in (is a customer-specific build
  > a project or a release?) I'd like to see a system which lets you add
  > and remove tags instead.
  
  Finally, a useful task for tags! ;-)
  
  This is an excellent idea and (as with the most elegant solutions) obvious once someone mentions it. With a capable database (SQLite or PostgreSQL are supported by Trac, I'm sure FogBugz has some sort of DB backend too) a simple many-to-many table would suffice (and eliminate dupes if you stemmed and soundexed the entries upon creation).
  
  It would be easier for users and for developers (eg. to aggregate and perform meta-analyses to determine the highest-impact direction for new development or refactoring). I think I will search the Trac list, and if it hasn't been suggested, I will bring it up.