Fog Creek Software
Discussion Board




Integrating bug tracking app w/ source control app

I know I've seen people comment that this is a must have feature. More importantly, though, I'm not really willing to add another step to our production process unless the additional overhead is low, but we've hit a point where all involved now agree that the pain of installing and using source control is outweighed by our need (up to now we've been doing it manually). And of course, it's another notch on the Joel test (on which we score 9 or 10, depending on your definition of a build and what exactly Joel means by a "daily build".

So: for those of you who have actually used an integrated solution, how do the ones that you liked best work?  Anything that you continually wished worked differently (missing features?)

How do you handle the inevitable times that you fix one problem and in doing so fix another?

Or do people think integrating is not a good idea?

If it's relevant, we're planning to use CVS as our source control and our own bug tracking solution (sorry Joel!)

Any warnings on how not to use CVS (from a human perspective, not technical), problems you've run into  etc would be great.  I have read quite a lot of documentation online, so it's personal feedback I'm looking for here.

Thanks,

Phibian
Thursday, July 17, 2003

The only application of this type that I really, really liked was Apollo computer's DSEE (Domain Software Engineering Environment). When HP bought Apollo DSEE got shunted into a company called ClearCase which was swallowed up by Rational and is now part of IBM.

I've just Googled for ClearCase and looked at the web site. It's now a monster, so maybe not such a good idea....

David

David Roper
Thursday, July 17, 2003

[[ It's now a monster ]]

You wouldn't believe ! My company has a full-time employee to just baby-sit ClearCase. Brrr ..

Evgeny Goldin
Thursday, July 17, 2003

Hi David,

What about that application did you like, as compared to the others that you have used? (Specific features that were good?)

Thanks,

Phibian
Thursday, July 17, 2003

[My company has a fulll timer employee just to baby-sit the monster]

Only one? We have 3 people on this site (OK, we have 1000 or so employees, and wer write a lot of telecoms software here.

Seriously though, if you can afford it, I recommend Clearcase. It is just stunning! I don't think we could do what we do at the rate we do it without it.

regards,

treefrog
Friday, July 18, 2003

Ohg, and what is good about clearcase? Apart from the industrial merge management tool, it all boils down to a file called a "config spec". This defines your "view" - which branches you pick up from the source tree. The file contains a series of rules for picking which versions of files to use, and when to create new branches. I can pick by branch, by label, by time, by combinations of all three, I can tell various rules to apply only to certain files or directories.

I can work in "snapshot" mode, wher I download the code to a local copy on my machine, or in dynamic mode, where I really do see the filesystem (in real time) as corresponding to the view specified by my config spec. In the latter case, if someone else checks in a new version on a branch I am picking up, I will automatically get the upgraded version.

It may be amonster, but it is defineitly a beast of a tool. Well recommended!

regards,

treefrog
Friday, July 18, 2003

Folks, I'm not as interested in the features of Clearcase that you like.  I'm interested in how it integrates with your bug tracking software and what you like about that.

In any case, Clearcase is not an option for us.  We wrote a web-based alternative to Outlook in order to ditch Exchange because we got fed up with administering it.  I'm not about to introduce a package that requires full-time babysitting. 

Phibian
Friday, July 18, 2003

Well, I'm running bugzilla and CVS.

As you may or may not know, CVS has the ability to run scripts at various points (like "commit"). So I just wrote a few scripts that:

- examine the log message for the commit for a bug number (just a simple search for "bugid=n") and reject the commit if the bug number is missing or if the bug isn't open (by just reading the bugzilla database directly)

- if it is a valid bug, I write to a file attached to the bug with the filename, reversion number, and committer

So with this system I can:

- find out the reason for making a change (read the bug number in the log message and look up the bug)

- find out what files were changed for each bug (read the special CVS modifications file attached to the bug)

It doesn't let me automagically jump between the two, but if I wanted to I might be able to add something like that with URLs. And you could probably add all kinds of fancy things. Of course, this depends on how well you can access your bug tracking app programmatically.

All this was just some stuff I slapped together in perl in a few hours. It sound's like a common problem, but I wasn't able to find anything on CPAN that looked like it did anything similar.

Bill Tomlinson
Friday, July 18, 2003

*  Recent Topics

*  Fog Creek Home