The directory where your srcsafe.ini resides in. For example: \\machine1\directory1.

	Note
	You should login to the remote machine first.

User name to use to login to the above Sourcesafe database.

Password for the above user name.

Specify the date/time format used for the Sourcesafe history command. This property is optional. If left empty, QuickBuild will use "M/dd/yy;h:mm:ssa" as the default value. The default value is suitable for English language operating systems using US locale. For other English speaking countries with different date format like UK, Australia, and Canada the Visual Sourcesafe Date format to use (assuming you're using the appropriate locale setup as Visual Sourcesafe honors the local locale settings) should be as follows:

'd/M/yy;H:mm'

If QuickBuild is running on non-english operating systems, use the following method to determine the datetime format:

Open Visual Sourcesafe installed on your build machine, select an existing VSS database and choose to view one of the projects with files in it. There should be a list of files shown with several fields including the "Date-Time" field. You should use the datetime format property from value specified in this field. For example, if one of the values of this field is 04-07-18 20:19, the datetime format property should be yy-MM-dd;HH:mm. The semicolon between date and time format should be specified. You are encouraged to specify the property as yy-MM-dd;HH:mm:ss to add the accuracy. Take another example, if the value shown in Visual Sourcesafe is 7/18/04 8:19p, the datetime format should be M/dd/yy;h:mma. Format M/dd/yy;h:mm:ssa would increase the accuracy in this case.

The following is a list of format character meanings copied from JDK documentation:

For details about the format string, please refer to http://java.sun.com/j2se/1.4.2/docs/api/java/text/SimpleDateFormat.html

Path to your ss.exe. For example: C:\Program Files\Microsoft Visual Studio\Common\VSS\win32\ss.exe. It should be specified here, if it does not exist in the system path.

Specify version of the build since which the revision log will be retrieved. If left empty, revision log will not be retrieved.

Number of seconds the current repository should be quiet (without checkins) before QuickBuild decides to check out the code from this repository for a build. This is used to avoid checking out the code in the middle of some other checkins. This property is optional. When set as 0, quiet period will not be used before checking out the code to build.

Choose login mapping for this repository. Login mapping is used to map repository login to QuickBuild user. It can be configured at "login mappings" tab of the configuration.

Here is the list of properties you should configure in order to define a module:

Source path represents a project path relative to the root of Sourcesafe, for example testvss, /testvss, or /testvss/web, etc. Path / or \ can be used to retrieve the whole contents of the repository. Label stands for a VSS label. VSS implements branches by creating a new shared Sourcesafe projects. So you may need to configure different modules in order to get the code from different branches. If Label is left empty, QuickBuild will get the latest code for that module from VSS. If Destination path is defined, contents from Sourcesafe will be retrieved to Destination path relative to the configuration's checkout directory. Otherwise the contents will be put to Source path relative to configuration's checkout directory.

Warning

Because Visual Sourcesafe has the limitation that only one label can be attached to a particular version (except for head version). So if you define a module with a particular label, retrieve it for build, and set new label after the build, the original label will get removed, which will cause failure of subsequent builds (because original label can not be found in VSS repository). Take an example, for a particular configuration, we define a VSS repository with the following modules: The first module retrieves the latest code from componentA Source path /src/componentA Label Destination path The second module retrieves the code from componentB with label v1.0 Source path /src/componentB Label v1_0 Destination path We define steps to retrieve and build against the code from this repository, and create new label after the build. After the first build in this configuration, the latest version under /src/componentA will get a new label (v2_0 for instance), and label v1_0 of /src/componentB will be replaced by v2_0. Everything goes well initially, but the second build in the same configuration will fail, because the label v1_0 under /src/componentB does not exist. Instead, you should replace v1_0 with v2_0 in the second module definition in order to build it successfully again. So you should change the label value of the second module to the latest label every time a new label has been generated. This is somewhat unacceptable. A better solution is to share v1_0 of source path /src/componentB with another project (select branch after share option), say /src/componentB-v1_0, and get it pinned. Then for the second module, the definition can be: Source path /src/componentB-v1_0 Label Destination path /src/componentB This way, new labels are attached to the head version (get pinned of course) of /src/componentB-v1_0, which is allowed in Sourcesafe, and the effect is the same as retrieving the code from label v1_0 under /src/componentB.