Configure Visual Sourcesafe repository
| Chapter 3. Configure repositories |

## 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.

| Warning
You need to run the application server (Tomcat by default) that hosts QuickBuild as a foreground process (instead of a NT service) in order to work with Sourcesafe repository.

| 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
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
  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

  Character | Meaning | Example
  --- | --- | ---
  y | Year | 1996 ; 96
  M | Month in year | July ; Jul ; 07
  d | Day in month | 10
  a | Am/pm marker | p
  H | Hour in day (0-23) | 0
  h | Hour in am/pm (1-12) | 12
  m | Minute in hour | 30
  s | Second in minute | 55

  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.

Login mapping

  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.

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's checkouts directory. Otherwise the contents will be put to Source path relative to configuration's checkouts 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 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`.

Configure Subversion repository |  | Configure StarTeam repository