Fog Creek Software
Discussion Board




integration with VSS

I've read over the support articles about using FogBUGZ with VSS.  I want to make sure I understand it fully.  Hopefully I won't sound too dim.

1. We tell VSS to spit its change reports into a journal file.
2. We schedule a script that eats that file and updates the FogBUGZ database.

So, Bob makes a change, and when he checks it in in VSS he includes the "BugZID: 1234" line.  Whenever this script runs, FugBUGZ gets told about this, and the "checkin" information appears in the bug.

Is this script supplied with FogBUGZ, or is it something we write?  The support article discussing it makes it seem like it's a piece of FogBUGZ.

Who's scheduling and running that script?  SourceSafe?  FogBUGZ?

How much time does this take?  Is this the sort of thing that could be run every ten minutes, or is it an overnight kind of thing?

What happens to that journal file?  I can imagine it's going to get pretty big after a while.  Does it have to be manually deleted or cleared or does the script take care of that?

I assume the web pages showing the log and diff are generated by CVS/Perforce, and that sort of thing isn't available via VSS.  Correct?

Thanks for entertaining these probably really basic questions.

Chaz Larson
Wednesday, January 15, 2003

In my haste to publish the docs, I pushed them up to the LIVE server even though we aren't shipping the VSS integration just yet (but it's coming VERY soon).

Basically you got everything correct.  The scripts that run that munge the journal file will be supplied by fogbugz and can be set up to run as a scheduled task.. Once the script sees a change, it deletes it, so the file won't grow and grow.  The DIFF/LOG file stuff is integrated with FB also, so you will be able see those same screens, not just with CVS/Perforce but for VSS also.

Michael H. Pryor
Wednesday, January 15, 2003

"VERY soon" meaning?

Chaz Larson
Thursday, January 16, 2003

Oops.  Pressed Post too soon.

Thanks for your quick response.  It looks to me like we'll be switching from ugly-homegrown-Access-bugbase to FogBUGZ pretty soon here.

The VSS stuff is important, though, and we'll probably wait until that's in place.

Chaz Larson
Thursday, January 16, 2003

Oh, and any comments about the time this takes?

Now I'll stop replying to myself.

Chaz Larson
Thursday, January 16, 2003

It would probably take you an hour or two to setup.  (Might take five minutes, but I'd rather err on the conservative side).

Very Soon means, basically days or weeks, rather than weeks or months.  That's as granular as I can be.

Michael H. Pryor
Thursday, January 16, 2003

With the time question, I'm thinking of the script itself on an ongoing basis, rather than the setup time.

I've got this scheduled task running that eats my journal.txt and sends the data to FogBUGZ.  Does that scheduled task take a few minutes, hours, days?

This is something my software development manager is asking about.  If the guys check their stuff into VSS, and it's going to take a long time [where "a long time" means hours] before fogbugz is updated with that information, that's a drag.

chaz larson
Thursday, January 16, 2003

Wait... do you mean, will the script itself take a long time because it has to do a lot of processing..?  The answer to that is no. Once the script is started it should finish in a minute.

If you mean, is there a time delay between when they submit code changes and when fogbugz is updated with the info.. That is configurable by you.  You can have the script run every five minutes if you want.  Or just nightly.. It's up to you.

Michael H. Pryor
Thursday, January 16, 2003

Excellent.  Thank you.  I was asking about the former.

chaz larson
Thursday, January 16, 2003

VSS integration is a very good thing I'm looking forward to.

Some possible optimizations (after 1st release please) may be possible to decrease the time between VSS changes to Fogbugz.

May be by triggering the update from a VSS event? Even if the event just sets a flag, so the scheduled update process knows if anything is changed at all. (Then you can schedule it to 5-10 minutes rather than hours or nights).

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/guides/html/vsoriAdministratorsGuide.asp?frame=true

Adriaan van den Brand
Wednesday, January 22, 2003

VSS events are only raised within VSS add-ins, which are added-in to the VSS Explorer. The idea is that when you check something in through Explorer, it can do whatever processing needs done.

However, such an add-in needs to be on each VSS user's system for this to be effective. This is why processing the journal.txt file is done; it is configured once for all VSS users.

If the script that drives this process (the one that eats journal.txt) were reimplemented as a DLL or service, it could use the FindFirstChangeNotification API to accomplish the same purpose -- basically, sleep until a change is made to journal.txt.

David Thompson
Wednesday, January 22, 2003

It should be simple to write a service to watches the journal file, and does something when teh journal file is updated (I know you can do this with .NET

Chez.

Murray Roke
Wednesday, April 28, 2004

*  Recent Topics

*  Fog Creek Home