Article:		Bug Trackers: Do They Really All Suck?
Subject:		bugtracker TRAC rocks
Date:		2005-12-12 11:04:03
From:		masp
We use TRAC, http://www.edgewall.com/trac/ and it simply rocks. Uses Subversion, so merging bugfixes between branches is easier. Try for yourself and you will never look back! :-)

Showing messages 1 through 7 of 7.

• bugtracker TRAC rocks
  2006-10-27 06:01:05  joedayney [View]
  
  
  Hi There,
  
  New to all of this and have got SubVersion set up and TortoiseSVN and have Trac set up and would like to integrate Trac to SubVersion ... looked at the Docs but would be greatful for info on the steps to set up. Thanks.
  
  Joe

• bugtracker TRAC rocks
  2005-12-28 12:04:51  ttriche [View]
  
  
  You set up the Trac commit hook, and it parses your log messages.
  
  Then when you write "fixes bugs #123 #456 and #789" in your commit message, that changeset gets hyperlinked to the bug and the bug is automatically closed. Trac's integration with SVN is very tight and well executed. If you already have svn2rss or email commit messages set up, adding another commit hook is trivial. If not, read the instructions.
  
  Trac owns. If you haven't tried it, you won't understand. This article displayed an amazing amount of ignorance considering the wide uptake of Trac among popular projects. There is a Ruby version underway (Collaboa) which basically mirrors Trac with some Rails-ish integration, although FWIW, Rails uses Trac. But lately the development of Trac has progressed to refactoring and modularizing everything, rather than massive new features. To me, that is a very good sign.
  
  There are things that suck about Trac, but compared to every other bugtracker I have ever used (bugzilla, mantis, jira) they are so miniscule as to be almost irrelevant.
• bugtracker TRAC rocks
  2006-10-27 06:02:41  joedayney [View]
  
  
  Hi There,
  
  New to all of this and have got SubVersion set up and TortoiseSVN and have Trac set up and would like to integrate Trac to SubVersion ... looked at the Docs but would be greatful for info on the steps to set up. Thanks.
  
  Joe

• bugtracker TRAC rocks
  2005-12-12 11:47:45  jeremiah.jahn [View]
  
  
  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?
• 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.