Configure Visual Sourcesafe repository

In order to use this repository, visual sourcesafe need to be installed in your build machine. Download Visual Sourcesafe from http://download.microsoft.com.

[Note]Note

In order to keep output of history command of Visual Sourcesafe accurate, time setting of all developer workstations, and the build server should be kept in sync.

[Note]Note

Currently only English version of Sourcesafe is supported.

The following list of properties needs to be configured:

Sourcesafe path

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

[Note]Note

You should login to the remote machine first.

Username

User name to use to login the above Sourcesafe database.

Password

Password for the above user name.

Datetime format

Specify the date/time format used for the Sourcesafe history command. This property is optional. If left empty, Luntbuild 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 document:

Table 3.1. Date/Time format characters

CharacterMeaningExample
yYear1996 ; 96
MMonth in yearJuly ; Jul ; 07
dDay in month10
aAm/pm markerp
HHour in day (0-23)0
hHour in am/pm (1-12)12
mMinute in hour30
sSecond in minute55

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 ss.exe

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.

Quiet period

Number of seconds 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 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 code to build.

Modules

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

Source path

Specify the path in the VSS repository, for example: /testvss, or $/testvss. To specify the whole repository, just use /, or $/.

Label

Specify the label for the above source path. This property is optional. If left empty, latest version is assumed.

Destination path

Specify the directory relative to the checkouts directory of current configuration, where the contents under the above source path should be retrieved to. If left empty, retrieved code will be put into directory defined by the source path relative to the checkouts directory.

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 code from different branches. If Label is left empty, QuickBuild will get 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 checkouts directory. Otherwise the contents will be put to Source path relative to configuration checkouts directory.

[Warning]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 latest code from componentA

    Source path

    /src/componentA

    Label

    Destination path

  • The second module retrieves code from componentB with label v1.0

    Source path

    /src/componentB

    Label

    v1_0

    Destination path

We define steps to retrieve and build against codes from this repository, and create new label after build. After the first build in this configuration, 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 now, but the second build in the same configuration will get failed, because label v1_0 under /src/componentB does not exist. Instead you should replace v1_0 with v2_0 in second module definition in order to get it build successfully again. So you should change label value of second module to latest label everytime you a new label has been generated. This is somewhat unacceptable. A better solution is to share v1_0 of source path /src/componentB into another project (select branch after share option), say /src/componentB-v1_0, and get it pinned. Then for second module, the definition can be:

Source path

/src/componentB-v1_0

Label

Destination path

/src/componentB

In this way, new labels are attached to head version (get pinned of course) of /src/componentB-v1_0, which is allowed in Sourcesafe, and the effect is the same as retrieving codes from label v1_0 under /src/componentB.