Visual SourceSafe: Resetting working folders

Setting a working folder for a VSS project is pretty standard practice. You set it, and you expect it to cascade down to the project's files and sub-projects.

If a sub-project has a working folder defined that differs from the cascaded one, then this takes priority for that sub-project and anything further down that branch of the tree.

Suppose you want to remove a sub-project's working folder, so it falls in line with the working folder cascaded down from the top level project. You would probably delete the path in the VSS dialog, and the working folders would then be consistent with the SourceSafe database tree.

Now suppose you want to remove a number of sub-project working folders under a certain root project. There might be 10, there might be 100's. The obvious way would be to write a little program that can work through your SourceSafe database and remove the working folders.

According to the documentation on VSS, it is possible to programatically change the working folder for a project in VSS using the LocalSpec property of the IVSSItem interface. It is also supposed to be possible to clear this property, by setting it to a blank string. It isn't.

Working folders are stored on a per user, per project, per machine basis. They are stored in the <VSSDB>\users\<user>\ folder, in a file called ss.ini.

Open this file in a text editor. In VSS, set a project's working folder and over-ride the cascading by setting a sub-project's working folder as well. Close VSS so that the changes to the ss.ini file are saved.

In the ss.ini file you'll notice some new lines at the end, looking something like this:

[$/Projects]
Dir (PCNAME) = C:\PROJECTS

[$/Projects/ProjectX]
Dir (PCNAME) = C:\PROJECTX

The working folder for all items (files) and projects under the $/Projects root will default to a subfolder of C:\Projects, unless the item falls under $/Projects/ProjectX, in which case the working folder will be in a separate directory structure under C:\ProjectX.

If you now clear ProjectX's working folder in VSS (and close VSS), the ss.ini file will be update to look like this:

[$/Projects]
Dir (PCNAME) = C:\PROJECTS

[$/Projects/ProjectX]

Now everything under $/Projects will have a working folder under C:\Projects.

However, if you'd made the change using the IVSSItem.LocalSpec, then the ss.ini file would look like this:

[$/Projects]
Dir (PCNAME) = C:\PROJECTS

[$/Projects/ProjectX]
Dir (PCNAME) =

The effect of this last line is horrible. It stops the cascading of working folders and ProjectX and anything at a lower level have "No working folder" set. If you ever wanted to check out, get or compare, you would have to set a working folder, even though the project fits into the standard tree structure. According to Microsoft, the behaviour is by design!

This problem affects SourceSafe TypeLib 6.0 and 8.0.

Rather than writing an app using the VSS API, I ended up changing my program to edit the ss.ini file directly, removing the lines for the working folders I wanted to remove.