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.
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:
[$/IssueTracker/IssueTrackerUI]
Dir (PRINCE) = c:\inetpub\wwwroot\IssueTrackerUI
[$/IssueTracker/IssueTracker]
Dir (PRINCE) = D:\IssueTracker
[$/IssueTracker/IssueTracker/IssueTrackerBase]
Dir (PRINCE) = D:\IssueTracker\IssueTrackerBase
[$/IssueTracker/IssueTracker/IssueTrackerData]
Dir (PRINCE) = D:\IssueTracker\IssueTrackerData
[$/IssueTracker/IssueTracker/IssueTrackerService]
Dir (PRINCE) = D:\IssueTracker\IssueTrackerService
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.
Rather than writing an app using the VSS API, I ended up removing the lines for the working folders I wanted to remove.
It worked for me…Good luck.
No comments:
Post a Comment