Configure a Subversion Client to Use the VCS Integration¶

To use Subversion to store the metadata of Virtual DataPort, you need to set up a Subversion server (the supported versions are 1.7 and later). In addition, in the host where the Virtual DataPort server will run, follow these steps:

1. Install a Subversion client. The version of the client has to be 1.7 or later. The recommended client is Apache Subversion.

2. Add to the PATH environment variable the directory where the svn executable is located. For Apache Subversion, that is the bin directory.

3. If the Virtual DataPort server will run on Windows, download the “Microsoft Visual C++ 2010 Redistributable Package”. To do this, follow these steps:

   1. Open the page to download the Microsoft Visual C++ 2010 Redistributable Package.

   2. Execute the file “vcredist_x64.exe” and follow the instructions.

4. Make sure that the “global ignores” list of the Subversion client does not include any of the following patterns:

   • d*.a, *.o, (in general, *.<character>)

   • d*.vql

   • *.properties

   • *.dependencies

   With Apache Subversion, you have to change the value of the property global-ignores in this configuration file:

   • On Windows: %APPDATA%\Subversion\config

   • On Linux: ~/.subversion/config or /etc/subversion/config

The default configuration of Subversion clients includes several file and directory name patterns that are ignored by Subversion operations. For example, by default Apache Subversion 1.7.5, ignores the files that match any of the following patterns:

global-ignores = *.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a
*.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store

Note that *.o and *.a are included in the list. This is problematic because of the way Virtual DataPort maps folders to their physical location in the file system when exporting to repository or performing VCS operations.

For example, a folder named a will be physically located at <some>/<path>/folder.a. As all *.a files and directories are ignored by Subversion by default, VCS operations involving such Virtual DataPort folders will fail.

Make sure that the global-ignores list does not include any of the mentioned patterns, as they correspond to the types of files involved in VCS operations.

Configure the Denodo Platform to Work with Subversion¶

Ignore this section if you installed the Denodo Platform on Windows.

If you installed the Denodo Platform on Linux and are going to use Subversion to store the metadata of Virtual DataPort, follow these steps:

1. Launch a Virtual DataPort Administration Tool and log in as an administrator user (e.g. the default admin user).

2. Perform the steps described in the section Enabling Uniqueness Detection of the Administration Guide.

3. If you are going to connect to Subversion using the HTTP or HTTPS protocol, follow the steps described in the section Activating the LS Optimization.

Configure the Denodo Platform to Work with Microsoft TFS¶

To use Microsoft Team Foundation Server (TFS) to store the metadata of Virtual DataPort, you have to set up a Microsoft Team Foundation Server (TFS). The supported versions are 2010 or higher.

The Denodo Platform includes the necessary libraries to connect to a TFS server.

The TFS administrator is in charge of creating and managing the collections that will contain team projects with Virtual DataPort metadata and their different development branches, if any. We recommend having at least one branch in each project with Virtual DataPort metadata (as described by this MSDN article).

The recommended repository structure will be like this (the nodes in italics are managed by the TFS administrators, the others are managed by Virtual DataPort):

• TFS Servers

  • DefaultCollection

  • Collection 1

  • Collection 2

  • …

  • VDP Collection 1

    • Team Project 1

    • Team Project 2

    • …

    • Team Project n

      • Branch-1

      • Branch-2

      • …

      • Branch-n

      • Main

        • databases

          • my database 1

          • my database 2

          • …

          • my database n

            • …

        • extensions

        • environments

        • maps

Each TFS collection is backed up by a different database, so it must be managed separately from the others.

Each TFS project can contain several Virtual DataPort databases for each development branch, which will share environments and global elements, so we recommended that each TFS project contain Virtual DataPort metadata related to only one application.