Open Source Bug Tracking for Visual SourceSafe?

rfsayre asks: "My employer has been looking into bug tracking options for use with Microsoft Visual SourceSafe, and while I don't have the authority or the resolve to encourage migration from the various MS tools that are in use, I would like to see an Open Source bug tracking system used, instead of Visual Intercept from Elsinore Technologies. Mainly I'm concerned that my employer will try to go as cheap as possible, and I think providing access to everyone from developers to QA interns could get expensive. Of course, what good is bug tracking if not everyone has access to it? So please, show me some Open Source alternatives that talk to SourceSafe, preferably with web based access."

Look at bugzilla

[Bazzargh]

Several other config tools have been integrated to some extent to Bugzilla. See:

http://www.trilobyte.net/barnsons/html/Bugzilla- Gu ide.html#INTEGRATION

Unfortunately for you, not VSS. However, look at the cruisecontrol project (on Sourceforge) and ant - they have (java) code for integration with VSS that may help you build what you need. Since what's in there is essentially just calls to the command line of VSS, and Bugzilla CVS integration is at much the same level, you might want to just read the VSS manual instead of looking at ant. (there's VSS integration for NTemacs that works the same way if you'd rather)

The Perforce integration has more info on what they did than the CVS one has (http://www.perforce.com/perforce/products/p4dti.h tml) , unless you just look at the code.

Hope this helps
Baz

Re:Look at bugzilla

[mentin]

Don't use command line for integration. VSS has a COM that is much more convinient to use. It is not perfect, but working.

Close...

[costas]

I have integrated VSS with Compuware Track Record. Compuware claim that is doable out of the box but after much research I eventually just went through a VB applet to do it.

After that painful experience, I fired up Python and talked to VSS through it. I still have a buncha classes that wrap around a VSS client pretty extensively, so that may lay the groundword for an interface to Bugzilla or something.

One other thing that I meant to look into but never got a chance: VSS provides a fairly extensive OLE interface which is callable through Python (and I am guessing Perl too). It should be simple enough to wrap around that to provide integration with Bugzilla or some such, or alternatively, to finally get a decent unix VSS client (the one that MS points to simply sucks).

No can do

[SecretAsianMan]

Until we invent computers with an infinite amount of memory, I don't think it will be possible to track all of Visual SourceSafe's bugs. You might want to think of another solution to your problem.

Sorry, I'm feeling ornery today and I could not resist!

From someone who deals with sourcesafe daily

[/Idiot\]

Please, until the VSS bugs are ironed out (prob won't ever be for VSS 6.0, ask again when .NET ships) use something rational.

To be fair by it's self it's ok but not very functional. Integrated with VB6 it is as buggy as hell.

But you all knew that allready :-)

Use CVS

[Alex Belits]

No, really, use CVS. Then think about bugs tracking -- bugzilla should be fine for that.

Re:Use CVS -- See Joel on Software

[myelin42]

If you're trying to get someone to move away from VSS, and are looking for more opinions on it (I haven't seen any actual *facts* yet, but there are plenty of opinions), a reasonably respected one would probably be Joel Spolsky's (from Joel on Software [joelonsoftware.com]). He was the Microsoft "Program Manager" from VBA (the version of Visual Basic that Office uses for scripting).

Basically, MS doesn't use it internally - they don't trust it. Apparently they use a lot of their own stuff in development (for example -- Joel was on the Excel team, and they all used Excel for project planning, and added in project planning features, making it reasonably good for development planning. Here are the details [fogcreek.net]). For NT (-> 2K -> XP) they used something called SLM, which was replaced by something else. Here's a USENIX paper [usenix.org] on it.

His company has a bug tracking system ("FogBUGZ") too, and if you buy a site license ($1995) -- which covers the whole project team -- you get the source and are allowed to modify it and use your modified versions internally. See here for more info [fogcreek.com]. It doesn't integrate with VSS, unfortunately ;-)

Re:Missing the point

[MrBlack]

Visual Intercept does integrate with VSS, so obviously someone thinks this is a good idea. I can see the value of being able to look at your bugs (or "incidents" as Visual Intercept calls them) and say "we had this bug in version 1.x, it disappeared in 1.y but reappeared in 1.z", but how do bugs/"incidents" get attributed to an individual file?

Certainly if a system was automatically reporting it's own bugs you could have code that said "Error in module XYZ", but presumable most bugs might come via e-mails/calls from beta testers/users/testers. In my experience many "bugs" are more to do with the GUI (since this is the part of the system the user interacts with directly), which an automated error-logging system would have a hard/impossible time finding.

Is there something cool you can do with a system like this that I'm not getting here?
Does anyone have experience integrating bug tracking and version control? Does the quality of data generated offset the implementation difficulties?