Setting up Visual SourceSafe

There are two aspects to setting up FogBugz-Visual SourceSafe integration:

1. Getting VSS to transmit changes to FogBugz
2. Getting FogBugz to display VSS diffs and logs

Setting up the repository in FogBugz

The starting point for setting up source control integration is to create the repository in FogBugz. To do so, log into FogBugz as an administrator and go to Admin | Source Control. Click Create New Repository. In the resulting dialog, select VSS as the type and give the repository a display name. Click Next.

In the resulting dialog, download the script necessary to get Visual Source Safe (VSS) to transmit changes to FogBugz. Instructions for setting it up are provided below. Before you close the dialog, choose whether you want FogBugz to provide links to your check-ins. You can change this setting later by clicking the Edit icon next to the repository on the Admin | Source Control page.

Diff and log links

There are two ways to have FogBugz link to checked-in files directly from cases.

The first is to set up VSS to run on the same machine as FogBugz so that you can use our internal tools. If this is not feasible for you, you can install a separate instance of FogBugz on IIS on the VSS machine, whose sole purpose is to read VSS files and show you the diffs and logs. Be sure the FogBugz user in that IIS has permissions on the VSS files on that server as specified above.

The second method, for FogBugz On-Demand users and those who do not wish to install FogBugz on the same machine that runs VSS, is to use VSS Remoting to display diffs and logs. For this method, set the path to VSS Remoting in the New Repository dialog and click OK to complete the setup.

Getting VSS to transmit changes to FogBugz

Edit the vss_fbupdate.wsf file you downloaded above as follows:

• Set the FB_VSS_USER and FB_VSS_PASSWORD variables to the user name and password of a FogBugz account.
• If you are using FogBugz in another language, you will need to update the strings FogBugz checks from the journal.txt file.  In particular, the sItemVersion and sItemAction comparisons will need to be updated.

Find out the path to your VSS database directory. For example:

C:\Program Files\Microsoft Visual Studio\Common\VSS

You can identify the VSS database directory because it contains a file named SrcSafe.ini. (Read more at Microsoft's website).

In vss_fbupdate.wsf, look for the commented-out line

'Call ProcessVSSJournal("Project Name", "Path to VSS Database directory")

Uncomment this and make a copy of each VSS project you have. For example:

Call ProcessVSSJournal("Test", "C:\Program Files\Microsoft Visual Studio\Common\VSS")

Note: If you are using MySQL, you cannot have an underscore in the file path, since it will be replaced by MySQL with a dash, and you cannot use a backslash \ since MySQL will interpret that as an escape character, so use forward slashes (/)instead.

For each VSS Database you have, run the Admin Console and choose Tools | Options.  Make sure it is set to create a file called journal.txt in the VSS Database directory.

Using the example above, the "Log all actions in journal file" would point to "C:\Program Files\Microsoft Visual Studio\Common\VSS\journal.txt".

If VSS says no such path exists, try using a UNC path (\\server\share\...). You will then have to use this in vss_fbupdate.wsf as well.

Set the vss_fbupdate.wsf file to run as a scheduled task every so often -- at least hourly, or even more often if you like. The task will complete very quickly so don't worry about running it too often.

Make sure this scheduled task runs as a user that has privileges to rename/delete files in the VSS directories (usually NOT the FogBugz user, but instead an admin on the machine).  Use the //B option to wscript so the script does NOT run in interactive mode:

c:\winnt\system32\wscript.exe //B "C:\Program Files\fogbugz\accessories\SourceControl\vss\vss_fbupdate.wsf"

Make sure that the FogBugz user (or whomever you installed FogBugz to run as) has READ access on all your VSS folders and all subfolders. The user must also have FULL CONTROL on the names.dat and the rights.dat files, and the LoggedIn directory.  Also it must have FULL CONTROL ON THE SSUS.DLL and SSAPI.DLL in order to create the SourceSafe COM object.