This topic explains how to connect SOAtest to your source control repository.

Sections include:

About Source Control Support

Any source control system that plugs into your Parasoft SOAtest environment can be used to manage your source and test files.

If your team is using a one of the specified supported source control system (see list below) and performs the necessary configurations (as described later in this topic), Parasoft can:

SOAtest includes out-of-the-box support for the following source control systems:

VendorTested version
Git

1.7, 1.8, 1.9, 2.x

Microsoft Team Foundation Server2012, 2015, 2017, 2018, 2019
Perforce2006.2, 2015
Subversion (SVN)

1.2, 1.3, 1.4, 1.5, 1.6, 1.7, 1.8, 1.9, 1.10, 1.11, 1.12, 1.13

You can use the source control API to integrate with other source control systems. Refer to Adding a Custom Source Control Integration.

Deprecated Source Control Systems

Support for the following SCMs is deprecated since SOAtest 2020.1.

See Configuring Deprecated Source Control Systems for configuration information.

Subclipse Support

Each Subclipse plugin version is compatible with specific Subversion versions. Ensure that your Subclipse plugin is compatible with a version of Subversion that Parasoft supports.

For example, you do not install Subversion 1.3 and Subclipse plugin 1.2, Subclipse 1.2 uses Subversion 1.4. Subclipse 1.4.x requires Subversion 1.5.0 version of JavaHL/SVNKit. Subclipse 1.4.5 already has subversion client adapter 1.5.2.

Subversion clients earlier than 1.4 do not support working copies produced by Subversion 1.4. If you are using Subclipse plugin 1.2 (which includes Subversion 1.4), you might receive the following error message:

svn: This client is too old to work with working copy '.'; please get a newer Subversion client

This means that Parasoft is using a command-line client that is version 1.3 or older. The solution is to update your command-line SVN client to version 1.4. The client version can be verified by executing the following command:

svn --version

Some source controls (including ClearCase, Perforce, Synergy, and Visual SourceSafe) require users to mark (lock) sources before editing them. If you are using one of these source control systems and you prompt SOAtest to perform an operation that involves editing a "read-only" file in source control, it will first open a dialog asking you whether you want to make the file writable and lock it. Click OK, then provide your source control username and password in the next dialog that opens; this allows it to access the source control system and set the lock.

Enabling Source Control Support

To enable support for any of the supported source control systems:

  1. Make sure that the command line client for the given source control is on the system%PATH%/$PATH and is available when SOAtest is launched.

  2. Choose Parasoft> Preferences. The Preferences dialog will open.
  3. Select Parasoft> Scope and Authorship in the Preferences dialog.
  4. Check Use source control (modification author) to compute scope.
  5. Select Parasoft> Source Controls in the Preferences dialog.
  6. If the appropriate repositories are already set (refer to the auto-configuration process described in Configuring SOAtest Across Teams), enter your user and password, and specify the path to your source control client executable (if it is not already on your system path).

    If the appropriate repositories are not already set (refer to the auto-configuration process described in Configuring SOAtest Across Teams) specify them as follows: 
    1. Enable the source control system you want to use and specify the path to the SCM client executable. You do not need to specify the executable path if it is already on your system path.
    2. Click New in Repository properties field and enter the source control properties required for the selected type of source control system.  
    3. Click OK to close the Source Control Description dialog.
  7. Apply your changes and click OK.

To test the integration:

  1. In the Parasoft environment, open a project that is checked out from the repository.
  2. Open a file in the editor.
  3. Right-click the source code, and choose Parasoft> Show Author at Line. If the correct author is shown, the integration was successful.

To troubleshooting problems with source control integration, run -consolelog -J-Dcom.parasoft.xtest.logging.config.jar.file=/com/parasoft/xtest/logging/log4j/config/logging.on.xml. This should result in detailed log information being printed to the console.

To include messages from the source control system that may contain fragments of user source code, use an additional flag: -Dscontrol.log=true

Git Configuration

The Git repository you connect to must allow anonymous pulls.

  1. Open a command prompt and clone your repository:

    git clone <repository> 

  2. If cloning from a git URL, then the git push  URL must also be configured to automatically push test cases checked in with Git.

    git config remote.origin.pushurl git@<your repository URL> 

  3. Set git config  on the newly created repository user.name

    git config user.name "<your username>" 

    This step can be skipped if a global git user.name is already set. The user.name must match the user's DTP user name.

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

A Git repository is considered shallow if the file .git/shallow exists. Git may not accurately produce authorship data when checking out shallow clones from a repository. You should check out full clones to retrieve accurate authorship information.  

Perforce Configuration

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

By default, username is used to determine file/method authorship. However, some teams access Perforce with a shared user name and a unique workspace for each developer.

If you want to use workspace name  (or user name and workspace name) to determine  authorship, open the Authorship tab and modify the setting as needed.

Subversion Configuration

Parasoft’s Subversion support is based on the command line client 'svn'. See About Source Control Support for a list of supported SVN versions.

The client certificate must be stored in the Subversion configuration area. The Subversion client has a built-in system for caching authentication credentials on disk. By default, whenever the command-line client successfully authenticates itself to a server, it saves the credentials in the user's private runtime configuration area—in ~/.subversion/auth/ on Unix-like systems or %APPDATA%/Subversion/auth/ on Windows.

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

Team Foundation Server Configuration

 See About Source Control Support for a list of supported versions.

SOAtest for Eclipse doesn't require any additional software to be installed for TFS integration (the required libraries are included).

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

By default, SOAtest uses the cached credentials for accessing TFS (this could be your user login or some previously logged in information). You can provide custom credentials if you want to use them instead of the cached ones.

Configuring Deprecated Source Control Systems

Support for the following SCMs is deprecated and will end in a future release.

AccuRev Configuration

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

ClearCase Configuration

To use ClearCase with SOAtest:

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

CVS Configuration

To use CVS with SOAtest, ensure that the .cvspass file is in one of the following locations:

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

General tab

Custom SSH/CVS_RSH tab

Serena Dimensions Configuration

To use Serena Dimensions with SOAtest, Linux and Solaris users should run SOAtest  in an environment prepared for using Serena programs, such as 'dmcli'

  • LD_LIBRARY_PATH should contain the path to <SERENA Install Dir>/libs.
  • DM_HOME should be specified.

Since many Solaris users commonly set the required Serena variables by running the Serena dmgvars.sh file, it also necessary to modify LD_LIBRARY_PATH variable. To use Serena Dimensions with SOAtest, LD_LIBRARY_PATH needs to include the following items (paths can be different on client machines):

  • SSL/Crypto library - /usr/local/ssl/lib
  • STDC++ library -  /usr/local/lib

When you are enabling source control support, specify the repository properties in the following tabs.

Properties tab

Workset Map tab

If the project has been downloaded/moved to a location other than default work area, use this tab to specify a mapping between the project (or stream) with the Serena repository and the local project.

If you are working in the default work area, you do not need to define mappings. 

Enter an expression that maps workspace resources to Serena Dimension repository paths.

StarTeam Configuration

The Borland StarTeam SDK is must be installed. Contact your oThis can be downloaded for free from the Borland web site.

For Visual Studio plugins, Parasoft StarTeam support is available for VS 2005 and VS 2008. When you are enabling source control support, specify the following repository properties:

Synergy Configuration

The following Synergy/CM communication modes are supported:

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

Visual SourceSafe Configuration

When you are enabling source control support, specify the following repository properties in the Create Source Control Description dialog:

Specifying Source Control Definitions via localsettings

Source control definitions can be specified in localsettings (e.g. for sharing team-wide settings via DTP, Concerto, or by specifying options at the command line). See Configuring Localsettings for details.