English فارسی Suomi
Français Nederlands Translate

Subversion Edge


Read me
CollabNet Subversion Edge - Linux 32/64-bit
Version 1.3.2
Release Date: March 3, 2011
   1. Overview
   2. Platform and configuration
   3. Requirements
   4. Installation notes
   5. Updates
   6. Documentation
   7. Known issues
   8. Support for CollabNet Subversion Edge
   9. About Subversion and CollabNet
1. Overview
   CollabNet Subversion Edge includes everything you need to install, manage
   and operate a Subversion server.  It includes all of the Subversion and
   Apache binaries needed to run a Subversion server.  It also integrates the
   popular ViewVC repository browsing tool so that users can view repository
   history from a web browser.
   CollabNet Subversion Edge also includes a powerful web-based management
   console that makes it easy to configure and manage your Apache server and
   Subversion repositories.  You can easily setup the server to use SSL
   connections and even connect the server to a corporate LDAP repository,
   including Microsoft Active Directory.
   CollabNet Subversion Edge only supports serving Subversion repositories via
   Apache httpd and it only supports the Subversion fsfs repository format.
2. Platform and configuration
   Product: CollabNet Subversion Edge
   License: GNU Affero General Public License 3.0 (AGPLv3)
   Certified platforms: Red Hat Enterprise Linux 5.x 
                        CentOS 5.x
                        SuSE Linux Enterprise 11.x
   NOTE: These are the platforms we formally certify when testing.  CollabNet
   Subversion Edge is known to work on virtually all Linux distributions and is
   informally tested on others such as Ubuntu and Fedora.
   There are separate downloads for 32-bit and 64-bit Linux.  Download the 
   appropriate version for your distribution and kernel.
3. Requirements
   * Java 1.6 JRE/JDK must be installed. We recommend the JRE provided by
     Sun/Oracle.  When testing on 64-bit Linux we have used the 64-bit JVM.
   * Python 2.4 to 2.6 must be installed.
4. Installation Notes
   IMPORTANT: Do not untar CollabNet Subversion Edge using root or sudo.  This
   will cause the UID/GID on the files to carry the values from our build
   system instead of being reset.
   1. Set the JAVA_HOME environment variable, and point it to your Java 6 JRE
      home.  For example:
      export JAVA_HOME=/usr/java/default
      Test the variable:
      $ $JAVA_HOME/bin/java -version
      java version "1.6.0_20"
      Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
      Java HotSpot(TM) Client VM (build 16.3-b01, mixed mode, sharing)
   2. Switch to the folder where you want to install CollabNet Subversion
      Edge.  You must have write permissions to this folder.
      $ cd /opt
   3. Untar the file you downloaded from CollabNet.
      $ tar zxf CollabNetSubversionEdge-x.y.z_linux-x86.tar.gz
      This will create a folder named "csvn" in the current directory. You can
      rename this folder if desired.
   4. Optional. Install the application so that it will start automatically
      when the server restarts.  This command generally requires root/sudo to
      $ cd csvn
      $ sudo -E bin/csvn install
      In addition to configuring your system so that the server is started
      with the system, it will also write the current JAVA_HOME and the
      current username in to the file data/conf/csvn.conf.  You can edit this
      file if needed as it controls the startup settings for the application.
      By setting the JAVA_HOME and RUN_AS_USER variables in this file, it
      ensures they are set correctly when the application is run.
   5. Optional. Configure proxy settings.  CollabNet Subversion Edge need
      access to the internet to check for and install updates.  If you need to
      go through a proxy to access the internet, then you can configure the
      proxy by editing the data/conf/csvn.conf file which was created by the
      previous step.  Uncomment and edit the HTTP_PROXY variable to configure
      your proxy server.
   6. Start the server.  Be sure that you are logged in as your own userid and
      not running as root.
      $ bin/csvn start
      This will take a few minutes and the script will loop until it sees that
      the server is running.  If the server does not start, then try starting
      the server with this command:
      $ bin/csvn console
      This will start the server but output the initial startup messages to
      the console.
   You must login to the CollabNet Subversion Edge browser-based management
   console and configure the Apache server before it can be run for the first
   time.  The UI of the management console writes the needed Apache
   configuration files based on the information you provide.
   The default administrator login is:
   Address: http://localhost:3343/csvn
   Username: admin
   Password: admin
   Subversion Edge also starts an SSL-protected version using a self-signed SSL
   certificate.  You can access the SSL version on this URL:
   Address: https://localhost:4434/csvn
   You can force users to use SSL from the Server configuration.  This will cause
   attempts to access the site via plain HTTP on port 3343 to be redirected to the
   secure port on 4434.
5. Updates
   CollabNet Subversion Edge includes a built-in mechanism for discovering and 
   installing updates.  You must use this facility to install updates.  Do not
   download and run a new version of the application installer.
   The update mechanism will require you to restart the servers at the end of
   the process, but it will do it for you.
6. Documentation
   Documentation for CollabNet Subversion Edge is available here:
   Context-sensitive help is also linked to this location from within the
7. Known issues
   - For the latest FAQ, visit the project home page here:
   - If you try to access an existing BDB (Berkeley DB) based repository
     through CollabNet Subversion Edge, then you will receive an alert "Failed
     to load module for FS type 'bdb'." This is because CollabNet Subversion
     Edge does not support BDB.  CollabNet recommends FSFS over BDB for ease
     of maintenance and supportability.
    - You can access the application from localhost, but not other computers
    on your LAN.  This usually means that you need to configure Firewall rules
    for you server to open the firewall for port 3343:
edit /etc/sysconfig/iptables
edit /etc/sysconfig/ip6tables

Add the following line to the above files, it line be will the line before
the last 2 lines.

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3343 -j ACCEPT
/etc/init.d/iptables restart
/etc/init.d/ip6tables restart
8. Support for CollabNet Subversion Edge
   Ask questions and get assistance with using CollabNet Subversion Edge via
   the community forums on openCollabNet.  The forum for CollabNet Subversion
   Edge questions is available here:
   Find out about CollabNet Technical Support at 
   Information about CollabNet Training, Consulting, and Migration
   services is at http://www.open.collab.net/training/
   Join openCollabNet for community support: http://open.collab.net
9. About Subversion and CollabNet
   CollabNet launched the Subversion project in 2000 in response to the demand 
   for an open standard for Web-based software configuration management that 
   could support distributed development. CollabNet continues to be strongly 
   involved with the Subversion project and offers CollabNet Subversion
   Support, Training, and Consulting services. 
   CollabNet also provides the most widely used collaborative development 
   environment in the world. More than 1,400,000 developers and IT projects 
   managers collaborate online through CollabNet. The company is transforming 
   the way software is developed by enabling organizations to leverage global 
   development talents to deliver better products and innovate faster. 
   Visit CollabNet at http://www.collab.net for more information.
   Subversion is a registered trademark of the Apache Software Foundation.
   http://subversion.apache.org/Enter new section title. 


Welcome to CollabNet Subversion Edge

CollabNet Subversion Edge provides a powerful web-based management console to install, operate and manage Subversion repositories on your Apache server.

Highlights - version 1.3

  • Subversion Edge 1.3 supports Solaris 10 SPARC/x86 systems.
  • Internationalization is supported. Translations are available in Chinese, Japanese, Korean, and Portuguese. For more information, see this wiki.
  • When Subversion Edge is configured to support LDAP, users can now log into the console using their LDAP credentials. They have ROLE_USER permissions, but can be assigned other roles to allow them to administer the server using their LDAP credentials.
  • You can now create users with periods in the name and repositories with hyphens in the name.
  • Performance could be slow when gathering statistics for repositories with a lot of revisions. The job has been changed to run less frequently and completely asynchronous to the web UI.

Highlights - version 1.2

  • Converting your Subversion Edge server to TeamForge mode is supported on Windows systems.
  • Integration of the SIGAR library provides better networking and file system statistics. You can also monitor the disk space used by your Subversion repositories, including individual repositories.
  • Subversion Edge is preconfigured for SSL on port 4434 using a self-signed certificate, in addition to the existing plain HTTP port 3343.
  • Usage of SSL for the Subversion Edge console can be required by checking an option on the Administration tab. This causes requests on port 3343 to be redirected to SSL on port 4434.

Highlights - version 1.1.0

  • You can bring the power and features of TeamForge to your Subversion Edge users by converting your server to a managed SCM integration server in TeamForge 5.4.
  • In TeamForge 5.4, you have an option to discover the Subversion Edge servers on your LAN.

Highlights - version 1.0.0

  • Subversion Edge runs on Microsoft Windows and Red Hat Enterprise Linux.
  • Installing and updating are simple. For Windows, there is an installation wizard, and for Linux, it's a matter of unpacking a tar.gz file. Updates can be done from the web console.
  • It is possible use a corporate LDAP repository to authenticate users.
  • You can add new users via the web console. Users can also log in and edit their passwords that Apache uses for authentication.
  • Role-based access control lets you assign roles to users to define their responsibilities.
  • You can create new repositories as well as connect existing ones.
  • You can maintain Subversion access control rules from the web console.
  • Statistics such as network throughput and server disk space are available to monitor your server.
  • Server logs are rotated daily and retained for the number of days you specify.
  • It integrates the ViewVC repository browsing tool.
  • The openCollabNet page provides a portal to a number of Subversion integrations, download clients and community forums supported by CollabNet.

Supported Operating Systems

CollabNet Subversion Edge is supported on the following operating systems.

Windows 32/64-bit All Editions

  • Windows 2008 Server (including R2)
  • Windows 2003 Server (including R2)
  • Windows 7
  • Windows Vista
  • Windows XP

NOTE: Windows distribution includes and installs Python 2.5.4 runtime needed for proper operation of Subversion Edge.

Linux 32/64-bit

  • Red Hat Enterprise Linux 5.x
  • SuSE Enterprise Linux 11
  • CentOS 5.x

NOTE: Linux distribution relies on the version of Python distributed with the core operating system distribution. Subversion Edge includes the necessary components to support Python versions 2.4, 2.5 and 2.6 and should work on any Linux distribution that includes one of those Python versions. It does NOT work on distributions like Red Hat Enterprise Linux 4 which includes Python 2.3.

Solaris sparc/x86

  • Solaris 10

NOTE: Subversion Edge requires Python 2.4 to 2.6. Unlike most Linux distributions, Solaris installations do not necessarily install or require Python to be installed. For our testing, we used the Python 2.4 version provided on the Solaris 10u9 DVD (SUNWPython). The Python package from sunfreeware.com did not work with Subversion Edge because it is compiled statically and lacks the shared libraries needed for Apache mod_python.

Future Operating Systems

We are committed to maintaining Subversion Edge on future releases of Windows, Red Hat Enterprise Linux, CentOS, SuSE Enterprise Linux and Solaris. We will make adjustments to the required Python binaries as needed when these distributions are updated.


Subversion Edge Components

CollabNet Subversion Edge is comprised of a number of components, with varying licenses.

CollabNet Subversion Edge

This is the core web UI for managing Subversion.

CSVN EdgeWeb-based management console1.3.2AGPL v3
JettyJava application server7.0.2.v20100331Apache 2.0/EPL 1.0
GrailsApplication framework1.3.4Apache 2.0
SIGARSystem Information Gatherer and Reporter1.6.4Apache 2.0
Java Service WrapperLaunch app as service/daemon3.4.1GPL v2Linux-only
Yet Another Java Service Wrapper (really!)Launch app as service/daemonbeta-10.2LGPL v2.1Windows-only
Sun Update Center - pkg(5)App packaging and updates2.3.1CDDL+GPLv2

Apache Subversion Native Binaries

This is our packaging of the latest open-source Subversion/Apache and ViewVC releases.

SubversionCore Subversion code1.6.16Apache 2.0
httpdApache HTTP Server2.2.16Apache 2.0
ViewVCSubversion Repository Browsing1.1.4*ViewVC (BSD-style)*Includes relevant patches from latest ViewVC releases
PythonPython runtime2.5.4Python (BSD-style)Windows-only


Set up CollabNet Subversion Edge


Linux Installation Instructions

The Linux distribution is a simple tar.gz archive that you can expand to any location that you want to install. You do not need to be root to install or run the application, inf fact you SHOULD NOT be root when you install or run the app. You will need root or sudo permissions if you want to be able to configure the application to run the included Apache httpd on port 80/443.


Before you can run the application, you need to prepare your system.

1. Java 6 Required

You must have a Java 6 JRE installed and working. We recommend that you use the Sun/Oracle JRE. It is the only one we test and qualify.

2. JAVA_HOME must be set

You must have the JAVA_HOME environment variable set, and pointed to your Java 6 JRE home. For example:

export JAVA_HOME=/usr/lib/jvm/java-1.6.0-sun

3. Python must be installed

It is probably a safe assumption that Python will already be install on any version of Linux.

Install the application

Remember, run the installation and the application as a normal user. Do NOT use root or sudo.

1. Choose the install location

Switch to the parent directory that you want to install the app.

$ cd /u1 

You will need permission to write files to this location. If necessary, use root or sudo to give yourself permissions.

$ sudo chmod a+rw /u1

2. Download the installer

The installers are available on openCollabNet

3. Unpack the installer

$ tar -zxf CollabNetSubversionEdge-1.0.0_linux-x86.tar.gz

This unpacks the install to a "csvn" folder. Feel free to use the "mv" command to rename the folder to something else.

Run the application

$ cd csvn
$ bin/csvn start

It'll take a minute for the application to start. You should be able to access it from a web browser at:


If you cannot access the application, here are some commands you can run:

$ bin/csvn status
CSVN Console is running (PID:23952, Wrapper:STARTED, Java:STARTED)

If the console is not running, then try starting it like this:

$ bin/csvn console

This should direct the startup message to your console so that you can see what the problem is. Most likely, your JAVA_HOME is not set or not pointing to the right location.

If you want to stop the running server you can run this command:

$ bin/csvn stop

NOTE: The Apache server is NOT stopped by this command. You would need to stop the server from within the web UI or from the command line via:

$ bin/csvn-httpd stop

Install the application so that it will start automatically when the server restarts.

To start the server automatically when the system reboots run the following command as the user you want the server to run with.

$ cd csvn
$ sudo -E bin/csvn install
In addition to configuring your system so that the server is started with the system, it will also write the current JAVA_HOME and the current username in to the file data/conf/csvn.conf. You can edit this file if needed as it controls the startup settings for the application. By setting the JAVA_HOME and RUN_AS_USER variables in this file, it ensures they are set correctly when the application is run.

Other Information

If you want to run your Apache/SVN server on port 80/443 you will need to run some commands as root/sudo. The web application UI will give you the instructions when this is necessary. Just try to configure the server for port 80 in the web UI, and it will tell you if there are actions you need to take.


Solaris Installation Instructions

The Solaris distribution is a simple tar.gz archive that you can expand to any location that you want to install. You do not need to be root to install or run the application, inf fact you SHOULD NOT be root when you install or run the app. You will need root or sudo permissions if you want to be able to configure the application to start automatically when your Solaris server boots.


Before you can run the application, you need to prepare your system.

1. Java 6 Required

You must have a Java 6 JRE installed and working. We recommend that you use the Sun/Oracle JRE. It is the only one we test and qualify.

2. JAVA_HOME must be set

You must have the JAVA_HOME environment variable set, and pointed to your Java 6 JRE home. For example:

export JAVA_HOME=/usr/java

3. Python must be installed

Unlike most Linux distributions, Python is not guaranteed to be installed on all Solaris installations. We tested using the Python 2.4 package (SUNWPython) included on our Solaris 10u9 DVD. Subversion Edge requires Python 2.4 - 2.6 and it must be compiled with shared libraries.

Install the application

Remember, run the installation and the application as a normal user. Do NOT use root or sudo.

1. Choose the install location

Switch to the parent directory that you want to install the app.

$ cd /opt 

You will need permission to write files to this location. If necessary, use root or sudo to give yourself permissions.

$ sudo chmod a+rw /opt

2. Download the installer

The installers are available on openCollabNet

3. Unpack the installer

 $ gzip -d CollabNetSubversionEdge-x.y.z_solaris-x86.tar.gz
 $ tar xf CollabNetSubversionEdge-x.y.z_solaris-x86.tar

This unpacks the install to a "csvn" folder. Feel free to use the "mv" command to rename the folder to something else.

Run the application

$ cd csvn
$ bin/csvn start

It'll take a minute for the application to start. You should be able to access it from a web browser at:


If you cannot access the application, here are some commands you can run:

$ bin/csvn status
CSVN Console is running (PID:23952, Wrapper:STARTED, Java:STARTED)

If the console is not running, then try starting it like this:

$ bin/csvn console

This should direct the startup message to your console so that you can see what the problem is. Most likely, your JAVA_HOME is not set or not pointing to the right location.

If you want to stop the running server you can run this command:

$ bin/csvn stop

NOTE: The Apache server is NOT stopped by this command. You would need to stop the server from within the web UI or from the command line via:

$ bin/csvn-httpd stop

Install application so that it starts automatically on reboot

Run the following command as the user you want the server to run as. Do not run this command as root or using sudo:
 $ cd csvn
 $ bin/csvn install 

In addition to configuring your system so that the server is started with the system, it will also write the current JAVA_HOME and the current username in to the file data/conf/csvn.conf. You can edit this file if needed as it controls the startup settings for the application. By setting the JAVA_HOME and RUN_AS_USER variables in this file, it ensures they are set correctly when the application is run. NOTE: The install script will use sudo to create the necessary symlinks to autostart the application. You may be prompted by sudo for your password.


Windows Installation Information

The Windows installer is a standard MSI-based Windows installer. We are using Advanced Installer by Caphyon to author the installation process. Running the installer is simple, the only option during the wizard is to select the location to install the product. We default the path to C:\csvn. We chose this as the default, as opposed to using C:\Program Files to minimize issues around dealing with paths that have spaces in the name and also to avoid Windows User Account Control (UAC) issues on Vista and later OS. We can test these scenarios and resolve issues in the product but as you start adding hook scripts and other integrations to Subversion it is an issue you are always dealing with. So we chose a default path that avoids some of these problems and makes the overall experience easier for the administrator.

Things we do during the install process

Here are some of the things we do during the install process, beyond simply copying the bits to your drive.

  1. Check for and install a valid Java 6 runtime. This is handled as an installation pre-requisite automatically. If a JRE is not found, we run the Sun/Oracle installer.
  2. Set/replace the JAVA_HOME environment variable to point to the Java 6 runtime
  3. Install Python 2.5 runtime, including mod_python and Windows extensions
  4. Set/replace the registry entries for Python2.5 to point to the version we install
  5. Set/replace the PYTHONHOME environment variable to point to our Python 2.5 runtime
  6. Add Windows service for the CollabNet Subversion Edge Console
  7. Add Windows service for the CollabNet Subversion Server (Apache)
  8. Add Windows Firewall exceptions for the Apache executable and the default Subversion Edge port (3343)
  9. Create a Start Menu shortcut to open browser to http://localhost:3343/csvn
  10. Add the csvn\bin and csvn\Python25 folders to beginning of PATH

Problems we are aware of

Here are some issues we are aware with the install.

  1. Trying to use ViewVC can give an Internal Server Error - 500. This problem is typically caused because you have conflicting DLL's in your Windows system32 folder. We did not want our installer to mess around with this folder, so we do not try to fix your system. In our own testing, the most common cause of this problem was if you have previously installed ActiveState Python 2.5. Their installer puts some DLL's that begin with "py" in the system32 folder. Moving these to a temp folder immediately solves the problem. We are using the Python distribution from python.org and the DLL's appear to conflict with one another. A similar problem can occur if you have conflicting OpenSSL DLL's in the system32 folder. These are the files (libeay32.dll and sslway32.dll). Typically, rebooting the server after installing our application resolves this problem because we put our folder first in the PATH. You could also remove the DLL's.
  1. 64-bit Windows. We are providing a native Windows 64-bit installer and we check for and install a native 64-bit JRE. However, the Apache and Subversion native binaries that we are currently providing are still 32-bit. We will be updating these to true 64-bit binaries in the near future. By using the 64-bit installer, you will be connected to the right package repository to receive these updates automatically in the future. We are also fully testing the installer and binaries on 64-bit versions of Windows 2003 and 2008.

SSL Configuration

Subversion Edge Console - Jetty Application Server

As of the 1.2 release the Subversion Edge console is pre-configured for SSL on port 4434. You can access the server using SSL simply by using https and port 4434 when you specify the URl. For example: https://localhost:4434

If you want to require all users to use SSL, there is a setting on the Administration tab to require SSL. This will cause traffic on port 3343 to be redirected to port 4434.

Subversion Edge configures the server using a self-signed certificate that we provide with the software. Since the certificate is self-signed users will receive warnings in most browsers when accessing the site. Individual users can install the certificate to their browser if they want to no longer see the warnings. If you want to solve this for all users, then you must purchase, install and configure an official SSL certificate from a trusted Certificate Authority.

Use your own SSL Certificate

You may decide you want to purchase an official SSL certificate or use an existing SSL certificate that you already use internally. This is relatively easy to do. The first step, possibly the most difficult, is that you need to have your SSL Certificate as well as the private key and any necessary intermediate certificates loaded into a Java keystore. If you purchased a certificate from a vendor and followed their instructions, it is possible that you already have this in a keystore. More often, you will have the certificate and key in OpenSSL format for use for your Apache server (see below). You can use this same certificate for the Jetty server, but you must first import the certificate and key into a keystore. For some reason, the Java keytool command does not provide an option to do this. Fortunately, it can be done using Java API's and there are a number of people on the web that have provided such classes for you to use. Here is a link to a resource that I have used for this: http://www.agentbob.info/agentbob/79-AB.html

Once you have your certificate and key in a keystore, you simply need to edit the file named svnedge-ssl.xml located in INSTALL_DIR/appserver/etc to point it at your keystore and certificate. This is what the file looks like as shipped:

<Configure id="Server" class="org.eclipse.jetty.server.Server">

    <!-- =========================================================== -->
    <!-- Set SSL connector                                           -->
    <!-- =========================================================== -->

    <Call name="addConnector">
          <New class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector">
            <Set name="port"><SystemProperty name="jetty.ssl.port" default="4434"/></Set>
            <Set name="maxIdleTime">30000</Set>
            <Set name="Acceptors">2</Set>
            <Set name="AcceptQueueSize">100</Set>
            <Set name="Keystore"><SystemProperty name="jetty.home" default="." />/etc/svnedge.jks</Set>
            <Set name="Password">OBF:1vv11wum1uo91t331unp1wts1vu9</Set>
            <Set name="KeyPassword">OBF:1vv11wum1uo91t331unp1wts1vu9</Set>
            <Set name="truststore"><SystemProperty name="jetty.home" default="." />/etc/svnedge.jks</Set>
            <Set name="trustPassword">OBF:1vv11wum1uo91t331unp1wts1vu9</Set>


Just replace the Keystore and truststore values with the path to your keystore and the passwords with the password you used to protect the keystore. The next section explains how to generate an obfuscated password so that it is not exposed in plain text.

Generate Obfuscated Password

If you edit the Jetty SSL configuration you may find yourself needing to supply Jetty with an obfuscated version of the password you used for your keystore and certificate. Jetty provides a tool to generate an obfuscated password that you can enter in its configuration files. You need to use that tool to generate an obfuscated version of your password. In this example, the password I used was "svnedge". Navigate to the appserver folder and run the following command:

Linux: $ java -cp lib/jetty-http-7.0.2.v20100331.jar:lib/jetty-util-7.0.2.v20100331.jar org.eclipse.jetty.http.security.Password svnedge

Windows: > java -cp lib\jetty-http-7.0.2.v20100331.jar;lib\jetty-util-7.0.2.v20100331.jar org.eclipse.jetty.http.security.Password svnedge


This generates the OBFuscated password as well as an MD5 hash. For the SSL configuration, you will need the OBFuscated password.

Apache Subversion Server

You can configure the Apache Subversion Server to use SSL simply by checking the box labelled "Apache Encryption" on the Administration tab. When this is done, we install an initial self-signed certificate provided with Subversion Edge. This matches the self-signed certificate that the console uses so that a user only needs to accept the certificate one time. The following directives are added to the Apache configuration to use these certificates:

SSLCertificateFile    "/install-path/data/conf/server.crt"
SSLCertificateKeyFile "/install-path/data/conf/server.key"

If you want to use your own SSL certificate, you can simply replace the "server.crt" and "server.key" files in the data/conf folder with your certificate and key. If you have purchased a certificate from a vendor, you may receive an intermediate certificate in addition to these two files. If you give this file the name "server.ca" and place it in the data/conf file then we will add an additional SSL configuration directive:

SSLCertificateChainFile    "/install-path/data/conf/server.ca"

Your SSL vendor should have instructions on their site for the Apache mod_ssl directives they require. If they reference this directive, then you will need to copy this file so that we add the directive.

Remove Passphrase from Private Key

It is fairly common to protect a private key with a passphrase, however in order to be able to start the Apache server from anything other than a Terminal window you must remove the passphrase from the private key file. This can be accomplished using OpenSSL as follows:

# you'll be prompted for your passphrase one last time
openssl rsa -in protected.key -out server.key

In the above example, the private key that is protected by a passphrase is named "protected.key" and we output the "server.key" file as needed by Apache.


Subversion Edge allows you to configure LDAP authentication using SSL. If your LDAP server uses a custom SSL certificate and you want Apache to validate that certificate, you can add this directive to httpd.conf:

Include "path/to/csvn_main_httpd.conf"
LDAPTrustedGlobalCert CA_BASE64 path/to/LDAP-Server.crt 

Refer to the documentation of this directive in the Apache documentation. 

Instructions for Migrating from Existing Subversion Installation

Migration to Subversion Edge from an existing Subversion installation is fairly straightforward. The steps below should apply to any flavor of Subversion, whether it is CollabNet Subversion, open-source Subversion or some other Subversion server product. However, there are a lot of different ways that Subversion could be deployed so we have not attempted to provide an automated upgrade or migration.


Please be mindful of these limitations of Subversion Edge before beginning a migration. These are not temporary limitations, but core choices made in the design for Subversion Edge.

  • No support for svnserve or SSH
  • No support for BerkeleyDB (BDB) repositories

1. Install Subversion Edge

Generally, you will want to install Subversion Edge on the server as your first step and then migrate your repositories and configuration. Some things to look out for:

  • If you are going to leave your existing SVN server running during this process, watch out for port conflicts. You may need to configure the Subversion Edge SVN server to run on a different port during the process, and then take over the original port when you are ready to switch over.
  • On Windows, the Subversion Edge installer adds itself to the PATH. This could potentially create conflicts with existing SVN server depending on the version currently installed. Unfortunately, it is hard to predict in advance whether or not this will prove to be something you need to watch out for. If you are having problems starting the server, this would be a place to look.

2. Migrate Existing Repositories

This is the easiest step. Just configure Subversion Edge to serve repositories from their existing location by pointing the Repository Parent Directory to the old location. Alternatively, you can use the new location for repositories and manually move the existing repositories to this folder (Subversion Edge does not automate this). After moving, just click the Repositores -> Discover option in Subversion Edge to have it recognize new repositories.

Filesystem Permissions for Repositories

On Unix systems, the repositories need to be owned by the user under which the Subversion Edge server will run. The Discover Repositories feature will detect if the owners do not match and prompt you to change the imported repository's owner. New repositories created under Subversion Edge will have the correct permissions.

3. Migrate Configuration

User Accounts

If you are currently using LDAP, then this process is pretty simple. Just enter the LDAP configuration into Subversion Edge under Administration -> Authentication. If your existing LDAP configuration is more complicated than what Subversion Edge supports, you may need to alter the Apache Configuration. See the next section.

If you are using an Apache password file you have some options:

  1. Re-create the user accounts in Subversion Edge. This has the advantage of making the future administration easier. Users can login to Subversion Edge and change their own passwords, and administration can take place from the console.
  2. Copy your existing file to [CSVN_HOME]/data/conf/svn_auth_file. This will immediately transfer the SVN credentials but not create accounts for them in Subversion Edge. You can then gradually enter the user accounts into Subversion Edge when password or other changes are needed. When you create a user in Subversion Edge, the Apache/SVN password will be reset to what you provide when creating the account. The user can then login and change it.

NOTE: Apache passwords are a one-way hash for security reasons, so there is no way to extract the current password and create a Subversion Edge user account.

Finally, if you are using some other user account system, then you either need to switch to the ones we provide in Subversion Edge or customize the Apache Configuration.

Apache Configuration

Subversion Edge manages and writes the Apache configuration, but it supports only a subset of directives, since it is assumed that this Apache instance will only be used for SVN. However, if you require additional Apache customizations in order to run Subversion, let us know about them so we can add support to a future release.

Subversion Edge only writes the main Apache httpd.conf file when it does not already exist ([CSVN_HOME]/data/conf]) -- for instance, during a clean install. This main file pulls in the sections generated by Subversion Edge via Include, so after we write the httpd.conf initially, you can add in any customizations that might be needed and expect it to remain untouched. For complete control of the Apache configuration, you can disable the Include directives and replace with your own code.

Do not edit the Subversion Edge-managed include files as they will be overwritten the next time the Subversion Edge configuration is changed or the server started. If you need to edit the content of those files, then remove the Include, copy and paste the content into the main httpd.conf and edit.

SSL Certificate

Subversion Edge generates an initial self-signed certificate when SSL is requested. We expect users to replace this with their own server certificate. Copy those to [CSVN_HOME]/data/conf/server.crt and [CSVN_HOME]/data/conf/server.key

Path-based permissions

If you are using Subversion's mod_authz_svn feature to control access to paths within repositories you can simply copy and paste your current rules into Subversion Edge.

Example Scenarios

Here are some example scenarios of complicated configurations and how they might be handled with Subversion Edge.

Tweak the Apache settings on connections, clients etc.

This should be as simple as editing the httpd.conf and adding the desired directives. We are writing defaults for some of these directives based on feedback and experience. For example, on Windows we add the MaxMemFree directive to reduce the memory bloat that can happen on Windows Apache Subversion. The feedback we got for Linux was that the Apache defaults were pretty ideal for most users so we left those defaults in place.

We are not currently doing anything to tweak the LDAP cache settings or SSL cache. We should do so in the future if we learn of any settings that improve performance and reliability.

LDAP-based authorization

We support configuring LDAP authentication, but not authorization. There are some Subversion users that seem to like to write fairly complicated Apache configuration where they do the path-based authorization using rules within the Apache configuration. This allows them to tie the authorization more easily to groups in their LDAP system. We do not have any UI to support this, so the user would need to edit httpd.conf to add these rules and maintain them the way they do today. I really cannot envision us going down this path, as opposed to using Subversion authz rules for path-based permissions.

We probably should provide options in our UI to do some blanket restrictions based on LDAP group. For example, we could require that any authenticated user belong to a certain LDAP group, presumably an engineering group. Better to let customers state these as requirements.

Kerberos Authentication

We probably could not handle this as we do not provide any support for it in the binaries, just as we do not in CollabNet Subversion either. Ideally someone that has this configured could share some details on their configuration and what it requires and we could add it to our roadmap to build the necessary support into our binaries as phase one. If we had that in place, then the user could edit the httpd.conf as necessary to use it. Ideally, we could eventually add UI to support configuring it. 


HOWTO: Modify the default ports used by Subversion Edge

By default, the Subversion Edge admin console listens for requests on two ports:

  1. 3343 - This is the plain HTTP port
  2. 4434 - This is the SSL HTTPS port

We chose default port numbers that are unlikely to already be in use on your server, but there will be occasions where you need to change one or both of these ports because another application is using the port. The default ports are set by modifying the Jetty system properties jetty.port and jetty.ssl.port (Jetty is the Java Application Server used by Subversion Edge). These properties are defined in the service wrapper configuration file used to configure Subversion Edge.

On Linux, this file is located at:


On Windows, this file is located at:


Just open the file in a text editor and search for these lines:

# Java Additional Parameters

There you will find the two port numbers and there you can modify them.

Final Caveat

There is one final caveat to add. This file that you are editing is not 100% safe from being replaced when installing updates. It will only be replaced if something changes in the application where we must modify this file. For example, the 1.2 release added the 4th parameter to the above list to add the SSL port. Hopefully the need for these sort of changes will be rare, but when they happen you will need to edit the file again after installing updates.


HOWTO: Enable Debug logging for the Subversion Edge console

If the Subversion Edge server is running, then debug logging can be enabled from the web UI. Just click on the Administration tab and then Server Logs > Configure. The change will take effect immediately.

If your Subversion Edge server is getting an error when starting, this is how you can enable debug logging so that you get more information during the startup process. This might help pinpoint the problem.

1. Make sure the Subversion Edge server is not running. This is important. On Windows, make sure the CollabNet Subversion Edge service is stopped. On Linux run:

 $ bin/csvn stop

2. Open the CSVN database in a text editor. This is the file data/csvn-production-hsqldb.script. On Windows you can just use Notepad for this. On Linux you might use vi or whatever your favorite text editor is. Find the area of the file that begins with this:


This is the statement that is adding the row to the table for your server. You should see within that row something like 'WARN', which is the default log level. You should see the value twice, the first will be the value for the Apache Subversion server, the second is the value for the Subversion Edge console, so that is the value you want to change. If you have changed these in the web UI you will see a different value and will need to look for that value. The possible values are ERROR, WARN, INFO, DEBUG.

3. Restart the Subversion Edge server. The log is in data/logs and named "console_YYYY_MM_DD.log" where the current date is replaced in the file name. This log file should now contain more information during the startup process.

WARNING: Do not attempt to change the database file while the application is running. The file should only be edited when the application has cleanly exited. 

Developer Information 

Subversion Edge is a Groovy on Grails application. Here is some information on developing the application

  • GettingStarted- Information on the Subversion Edge development process
  • EclipseIDE - Using the SpringSource Tool Suite for development
  • DevGuidelines - Subversion Edge development guidelines
  • DevBuilds - Install a development or release candidate build
  • i18nLanguages - Open for contributions
  • Functional Tests - Testing user-facing functionalities using the Grails Functional Tests plugin

Getting Started with Subversion Edge and Grails

This document is to give you some links and pointed to getting started with development in this project and with Grails.

Get Grails

Grails needs a JDK installed, we assume you already have one. The Sun 1.6 JDK is recommended version. We are currently using Grails 1.3.4. You can download it here:http://www.grails.org/download/archive/Grails. Note that you must use the same version of Grails used by the application.

Unpack Grails to a location such as $HOME/grails-1.3.4

Checkout the SVNEdge application

It is a good idea to go ahead and checkout using the command line. It should work from an IDE too, but there is some Grails initialization work you are going to need to do from command line anyway so you might as well just do the checkout from command line.

$ svn co https://ctf.open.collab.net/svn/repos/svnedge/trunk/console

Install Grails plugins and using Grails Command Line

Our application uses a number of Grails plugins, and if you are going to use an IDE, you will need these installed to not have compile errors. I found the easiest way to get all the plugins was to just run some grails commands from command line:

There is a Getting Started guide here: http://www.grails.org/Quick+Start. Here are the basic things you need to do:

  1. Create a JAVA_HOME environment variable pointing to root of your Java install
  2. Create a GRAILS_HOME environment variable pointing to root of your Grails install
  3. Add Grails bin folder to your PATH

Here are examples from OSX:

export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Home
export GRAILS_HOME=/Users/username/grails-1.3.4

Once these steps are done, navigate to your checked out project and run prepare to setup the binaries on the system:

grails prepare

This will also download and install all the plugins.

Next, either run the app:

grails run-app

or run the tests like so:

grails test-app

This will compile the application and run the tests. Note that you might get a build failure with a message involving HtmlUnit the first time you build. If so, just repeat the command and it should finish.

Next Step - Using an IDE

Instructions for developing SVNEdge using the SpringSource Tool Suite (Eclipse)


SpringSource Tool Suite

SpringSource, the corporate sponsor for Grails, provides an Eclipse-based IDE called the SpringSource Tool Suite (STS). There are other IDE's and tools that support Groovy and Grails development, but this page will be focused on using this specific IDE. STS is free and open-source. You can learn more about this IDE as well as download it here: http://www.springsource.com/products/sts. The download includes everything you need, including Eclipse. If you already have Eclipse installed, you can add the STS bits via an update site.

The product support forum is here http://forum.springsource.org/forumdisplay.php?f=32 and it includes FAQ on the IDE in general as well as the Grails support.

Install Grails Extensions

NOTE: When installing it is a good idea to not install into a path with spaces in name. On Windows, this can mean overriding the default location to something like C:\SpringSource.

The current version (2.3.2-RELEASE) of STS does not include the Grails tools in the default install, you have to install them separately after installing STS. You do this from within the IDE itself so go ahead and start the IDE. On initial startup, there is a first-time Welcome page. Click the link to Open the STS Dashboard. If you miss this, it shows up on the Help menu under Dashboard. The Dashboard has some RSS feeds with more info as well as some useful links. You will also notice it has tabs at the bottom and one of those tabs is labeled "Extensions". Click on that tab. It will being up a nice installer for extra plugins you can install.


We want to install these items:

  • Grails Support
  • Groovy Eclipse

If an item does not show up in the list, it is likely only because it is already installed. After you have selected all the extensions you want, click the Install option. You should get a dialog like this:


Just follow your way through the wizard to download and install the extensions and restart the IDE.

Install CollabNet Desktop

Next step is to install the CollabNet Desktop - Eclipse Edition. This will provide you with a Subversion client as well as a custom TeamForge client with pre-configured access to this community site. You can download the CollabNet Desktop from here. Just follow the instructions provided to install.

If you are on Windows, you should be all done and ready to go. For any other OS, please take a look at this Subclipse wiki page that has information on installing and configuring JavaHL for your OS. In general, you should be able to use our CollabNet download to make this easy.

Getting started with Subversion Edge in Eclipse

You should have already followed all of the instructions in GettingStarted to get Grails installed and working on your computer as well as the Subversion Edge code checked out. These instructions are going to assume that is the method you will follow.

First Steps - Setting up Grails

Before you can get started, there are a couple of things to do with Grails in Eclipse. Both of these are done in the Eclipse preferences (Window > Preferences).

1. Under General > Workspace > Linked Resources - Define a GRAILS variable that points to your .grails/RELEASE folder (usually in HOME).


This preference is a convention we are using in our project so that the Eclipse project files do not have hard-coded paths to the Grails plugins. The GRAILS variable defines the root location in your home folder where plugins are installed. For example on OSX, my location would be:


And on Windows it would be:

C:\Documents and Settings\mphippard\.grails\1.2.1

The Grails tool adds Eclipse Linked Resources to the application to point to these plugins so that the tooling can find their classes. The Linked Resources variable name just allows us to soft-code the location and share the project files.

2. Under Groovy > Grails - Define your Grails installation folder (GRAILS_HOME).


This preference is needed by the Grails tooling itself and allows it to execute the grails command line tools from within Eclipse.

Importing the SVNEdge application into Eclipse

With the previous steps done, you are now ready to do Subversion Edge development in Eclipse. Obviously the first step is to get the project into Eclipse. If you have followed GettingStarted, then you already have it checked out. All you need to do is point Eclipse at that checkout and get to work. To do this use the Eclipse Import wizard. File > Import


Choose General > Existing Projects into Workspace option.


Point to the path where you have checked out Subversion Edge. The wizard will find the project automatically. Make sure you do NOT take the option to copy the project. We do not want to physically copy it to a new location, just use it as is.

Click Finish.

The import happens pretty quickly, but will also kick off the Eclipse builders etc., so you should see some activity. The project should be recognized as a Grails project automatically, as well as connected to Subclipse/SVN automatically. It should look like this:


If it is your first time building the project and the Eclipse IDE is not recognizing classes, make sure you have set up the grails artifact completely as discussed inGettingStarted. These additional steps are needed so that all of the Grails dependencies are installed and registered to Grails.

Finally, note the little Grails project decorator on the project icon that denotes that this is a Grails project, as opposed to the "J" you would see on a Java project. Also note the Subversion decorators and information on the items that indicate it is connected to SVN.

Hacking from Eclipse

This FAQ on the SpringSource forum has some links for more information on the tools. There are Groovy and Grails aware editors and compilers within Eclipse. So you should have things like syntax highlighting, code completion as well as immediate feedback on code and compile errors. There is also support for running grails commands from the IDE so that you do not have to go out to a command line. We can expect and hope that with each release these tools will get better and better. The one feature I want to describe, is how to setup an Eclipse Run Configuration. This is useful for being able to launch the application or run the tests. This is also how you can debug the application as all you need to do is double-click on some lines of code to set breakpoints and then start your Run Configuration in Debug mode. You can then step through the code with a nice graphical debugger. First, we have to create the Run Configuration. To do this go to the menu and choose Run > Run Configurations (Note you can also use Debug > Debug Configurations, they are the same thing different modes).

Down the left-hand side of the dialog will be all of the different types of run configuration you can setup. We want the Grails configurations. Click on Grails and then the little New Configuration icon at the top.


In this example, I have already started filling out the dialog. Give it a nice name at the top. Select the SVNEdge project, and then enter the Grails command you want to run. You probably want to at least have run-app and another for test-app.

Wait! There is still more to do. Click on the Arguments tab and add the VM Arguments as shown. This increases the PermGen space for the JVM which is needed.


Note that I discovered on Windows you get an error launching the JVM if you try to include the -Xmx256m or similar to set the heap size. This is because the batch file on Windows that starts Grails already sets the heap to 512m and does not handle it properly if you provide the same start option. This is corrected in Grails 1.2.1.

Once this is done click Apply to save your configuration. Then go ahead and start it using the Run or Debug option. As I said, just repeat this process to create launch configurations for other Grails commands. Once you have run these configurations once, they will show up as shortcuts on your Run/Debug menu and in the Run/Debug toolbar.

Commit messages

  • At the top of your commit message, start with the [artifact ID] (the artifactNNNN in square brackets). This allows CTF to auto-associate the commit to the artifact.
  • Next add an overview Description section.
  • Finally, add a Detail section where you enumerate the files changed and a description of what changed in each file.

Subversion config

A Subversion config file with all of the right settings is attached to bottom of this wiki page. Download and copy it into ~/.subversion to replace your existing config file. If you want to edit your config file manually, make sure that you have auto-props turned on and then add the following to the end of your [auto-props] section.

  • .groovy = svn:eol-style=native
  • .gradle = svn:eol-style=native
  • .gsp = svn:eol-style=native

Code conventions

  • No tabs.
  • 80 column width.

Code reviews

  • Not needed for trivial or obvious changes
  • Use internal Review Board for other patches ("Code Review" tab in the project). If you get at least one +1 and no -1, you can commit.
  • If no access to Review Board then mail patch to the discussion forum.


Config file (sample)

 ### This file configures various client-side behaviors.


### The commented-out examples below are intended to demonstrate

### how to use this file.

### Section for authentication and authorization customizations.


### Set store-passwords to 'no' to avoid storing passwords in the

### auth/ area of your config directory.  It defaults to 'yes'.

### Note that this option only prevents saving of *new* passwords;

### it doesn't invalidate existing passwords.  (To do that, remove

### the cache files by hand as described in the Subversion book.)

# store-passwords = no

### Set store-auth-creds to 'no' to avoid storing any subversion

### credentials in the auth/ area of your config directory.

### It defaults to 'yes'.  Note that this option only prevents

### saving of *new* credentials;  it doesn't invalidate existing

### caches.  (To do that, remove the cache files by hand.)

# store-auth-creds = no

### Section for configuring external helper applications.


### Set editor to the command used to invoke your text editor.

###   This will override the environment variables that Subversion

###   examines by default to find this information ($EDITOR, 

###   et al).

# editor-cmd = editor (vi, emacs, notepad, etc.)

### Set diff-cmd to the absolute path of your 'diff' program.

###   This will override the compile-time default, which is to use

###   Subversion's internal diff implementation.

# diff-cmd = diff_program (diff, gdiff, etc.)

### Set diff3-cmd to the absolute path of your 'diff3' program.

###   This will override the compile-time default, which is to use

###   Subversion's internal diff3 implementation.

# diff3-cmd = diff3_program (diff3, gdiff3, etc.)

### Set diff3-has-program-arg to 'true' or 'yes' if your 'diff3'

###   program accepts the '--diff-program' option.

# diff3-has-program-arg = [true | false]

### Section for configuring tunnel agents.


### Configure svn protocol tunnel schemes here.  By default, only

### the 'ssh' scheme is defined.  You can define other schemes to

### be used with 'svn+scheme://hostname/path' URLs.  A scheme

### definition is simply a command, optionally prefixed by an

### environment variable name which can override the command if it

### is defined.  The command (or environment variable) may contain

### arguments, using standard shell quoting for arguments with

### spaces.  The command will be invoked as:

###   <command> <hostname> svnserve -t

### (If the URL includes a username, then the hostname will be

### passed to the tunnel agent as <user>@<hostname>.)  If the

### built-in ssh scheme were not predefined, it could be defined

### as:

# ssh = $SVN_SSH ssh

### If you wanted to define a new 'rsh' scheme, to be used with

### 'svn+rsh:' URLs, you could do so as follows:

# rsh = rsh

### Or, if you wanted to specify a full path and arguments:

# rsh = /path/to/rsh -l myusername

### On Windows, if you are specifying a full path to a command,

### use a forward slash (/) or a paired backslash (\\) as the

### path separator.  A single backslash will be treated as an

### escape for the following character.

### Section for configuring miscelleneous Subversion options.


### Set global-ignores to a set of whitespace-delimited globs

### which Subversion will ignore in its 'status' output, and

### while importing or adding files and directories.

global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store

### Set log-encoding to the default encoding for log messages

# log-encoding = latin1

### Set use-commit-times to make checkout/update/switch/revert

### put last-committed timestamps on every file touched.

# use-commit-times = yes

### Set no-unlock to prevent 'svn commit' from automatically

### releasing locks on files.

# no-unlock = yes

### Set enable-auto-props to 'yes' to enable automatic properties

### for 'svn add' and 'svn import', it defaults to 'no'.

### Automatic properties are defined in the section 'auto-props'.

enable-auto-props = yes

### Section for configuring automatic properties.


### The format of the entries is:

###   file-name-pattern = propname[=value][;propname[=value]...]

### The file-name-pattern can contain wildcards (such as '*' and

### '?').  All entries which match will be applied to the file.

### Note that auto-props functionality must be enabled, which

### is typically done by setting the 'enable-auto-props' option.

*.bat = svn:eol-style=native

*.bmp = svn:mime-type=image/bmp

*.c = svn:eol-style=native

*.class = svn:mime-type=application/octet-stream

*.command = svn:eol-style=native;svn:executable

*.conf = svn:eol-style=native

*.cpp = svn:eol-style=native

*.css = svn:eol-style=native

*.csv = svn:eol-style=native

*.doc = svn:mime-type=application/msword

*.dsp = svn:eol-style=CRLF

*.dsw = svn:eol-style=CRLF

*.elc = svn:mime-type=application/octet-stream

*.exsd = svn:eol-style=native

*.gif = svn:mime-type=image/gif

*.groovy = svn:eol-style=native

*.gsp = svn:eol-style=native

*.gz = svn:mime-type=application/x-gzip

*.h = svn:eol-style=native

*.htm = svn:mime-type=text/html;svn:eol-style=native

*.html = svn:mime-type=text/html;svn:eol-style=native

*.htm.en = svn:mime-type=text/html;svn:eol-style=native

*.html.en = svn:mime-type=text/html;svn:eol-style=native

*.java = svn:eol-style=native

*.jar = svn:mime-type=application/octet-stream

*.jpg = svn:mime-type=image/jpeg

*.js = svn:eol-style=native

*.MF = svn:eol-style=native

*.mf = svn:eol-style=native

*.patch = svn:eol-style=native

*.pdf = svn:mime-type=application/pdf

*.pl = svn:eol-style=native;svn:executable

*.pm = svn:eol-style=native

*.png = svn:mime-type=image/png

*.ppt = svn:mime-type=application/vnd.ms-powerpoint

*.prefs = svn:eol-style=native

*.properties = svn:eol-style=native

*.props = svn:eol-style=native

*.ps = svn:mime-type=application/postscript

*.py = svn:eol-style=native;svn:executable

*.class = svn:mime-type=application/octet-stream

*.pyc = svn:mime-type=application/octet-stream

*.rtf = svn:eol-style=native;svn:mime-type=text/rtf

*.sgml = svn:mime-type=text/sgml

*.sh = svn:eol-style=native;svn:executable

*.sql = svn:eol-style=native

*.tar = svn:mime-type=application/x-tar

*.term = svn:eol-style=native;svn:executable

*.tif = svn:mime-type=image/tiff

*.tsv = svn:eol-style=native

*.txt = svn:eol-style=native;svn:mime-type=text/plain

*.vm = svn:eol-style=native

*.xls = svn:mime-type=application/vnd.ms-excel

*.xml = svn:eol-style=native;svn:mime-type=text/xml

*.zip = svn:mime-type=application/x-compressed

Makefile = svn:eol-style=native

makefile = svn:eol-style=native

.classpath = svn:eol-style=native

.project = svn:eol-style=native

.MF = svn:eol-style=native


HOWTO: Install a development or release candidate build

Subversion Edge includes a built-in mechanism for installing updates. It does this by checking an update server for new packages and then downloading and installing them. The location it checks for new builds can be modified so that you can point your server at the server we use to publish release candidate or development builds. This wiki page will explain how you can modify your installation to get updates from one of these locations.

WARNING: Subversion Edge does not provide any mechanism to remove an update once it is installed. The only way to go backwards is to have a backup that you restore or to delete the installation entirely and re-install the old version. Keep this in mind before you install one of these builds.

The following URL's are the location of the packages. You do not use these URL's from a web browser. You will use them in the instructions at that follow to point Subversion Edge at these servers to check for and download updates.

Official Release area

Paths under /releases/ are where the release versions of our packages are kept.

Linux 32-bithttp://pkg.collab.net/release/linux
Linux 64-bithttp://pkg.collab.net/release/linux64
Windows 32-bithttp://pkg.collab.net/release/windows
Windows 64-bithttp://pkg.collab.net/release/windows64

 Release Candidate area

The /qa/ path contains the release candidate package area.

Linux 32-bithttp://pkg.collab.net/qa/linux
Linux 64-bithttp://pkg.collab.net/qa/linux64
Windows 32-bithttp://pkg.collab.net/qa/windows
Windows 64-bithttp://pkg.collab.net/qa/windows64

Development Builds area

This is bleeding edge. Every successful Hudson build pushes new packages to this area.

Linux 32-bithttp://pkg.collab.net/dev/linux
Linux 64-bithttp://pkg.collab.net/dev/linux64
Windows 32-bithttp://pkg.collab.net/dev/windows
Windows 64-bithttp://pkg.collab.net/dev/windows64


Modify Subversion Edge to use a new URL

This is how you modify Subversion Edge to get updates from a new location.

1. Stop the Subversion Edge service. On Windows stop the service. On Linux run:
$ bin/csvn stop
2. Open a command prompt and navigate to the "bin" folder of the Subversion Edge installation.

3. Run the following command to change the location from which packages are retrieved:


$ ./pkg set-authority -O http://pkg.collab.net/qa/linux "collab.net"


> pkg set-authority -O http://pkg.collab.net/qa/windows "collab.net"

That is an upper-case "o" not a zero. And the "collab.net" needs to be specified exactly as that is the "key" to our packages.

4. Test that it worked:


$ ./pkg refresh
csvn 1.3.0-1379.751 installed u---
pkg 1.122.2-38.2699 installed ----
python2.4-minimal installed ----

$ ./pkg list
csvn-svn                                      1.6.12-1379.751 installed  u---


> pkg refresh

csvn 1.3.0-1379.751 installed u---
pkg 1.122.2-38.2699 installed ----
python2.4-minimal installed ----

> pkg list
csvn-svn                                      1.6.12-1379.751 installed  u---

The first command refreshes the metadata. The second command lists the packages and versions you have installed locally. The "u" in the final column means there is an update available.

5. Restart the Subversion Edge server. When you login you should be able to install the updates via the web UI. You can eventually reset your server so that it is pointing at the official releases just by running the same steps and providing the URL for the release server. If you have installed a newer release locally, then you will not see any updates until a newer version makes its way to official release status.

Install Updates via Command Line

If you have gone this far you might want to just install the updates via the command line. This could especially be useful if you install a build that will not start! To install the updates via command line just run this command:

pkg image-update

On Windows, you the updates are installed into a staging area because Windows does not allow files that are being used to be replaced. So normally our app shuts down and installs the updates and then restarts. To do this> pkg refresh manually, make sure that BOTH services are stopped and then run this command:

> dist\install-updates.bat

Once this is done, then just start the Subversion Edge server.

CollabNet Subversion Edge i18n Languages Translations

We are proud to announce the support for internationalization of the CollabNet Subversion Edge starting on 1.3. The current list of translations as displayed below. If you want to provide language support for your country, please create a patch from the main messages.properties artifact from the console application.

Languages List

LanguageCountryContributor NameReviewer NamePatch
ChineseChina-Flag.pngYiping Zhang (yiping at collab dot net)Needs Reviewartf5050
EnglishUnited-States-of-America-Flag.pngCollabNet Subversion Edge teamCollabNet Subversion Edge team
JapaneseJapan-Flag.pngKotaro Murakami (kmurakami at collab . net)Needs Reviewartf4994
KoreanSouth-Korea-Flag.pngYongman Joo (ymjoo at collab . net)Needs Reviewartf5092
PortugueseBrazil-Flag.pngMarcello de Sales (mdesales at collab . net)Needs Reviewartf4989

Steps to contribute

1. Creating a User Request artifact in the Subversion Edge tracker. That way, we will add the information about your contribution in this page.

2. Checkout the languages directory: https://ctf.open.collab.net/svn/repos/svnedge/trunk/console/grails-app/i18n

3. In order to verify your work, download the latest version of production and update it to development.

4. Verify that you have the development version with support to i18n

5. Add your contributed translations file in the correct directory

6. After you finish the translations, attach the patch to the artifact created on 1. We will commit the changes once we verify.

Any problem you may have, please let us know using the Developer's list at "dev-svnedge@ctf.open.collab.net".

Subversion Edge Languages Diff Utility

In order to keep a language pack up-to-date, please run "grails diffI18n" for verifying which keys, in the English messages, are needed to be imported to your language of choice.

As explained above, each message bundle is saved in specific messages_LANGUAGE.properties or messages_LANGUAGE_COUNTRY.properties. The former maintains the list of translations for a language code, while the latter contains the list of translations related to a language of a specific country. Therefore, the translation to be selected will depend on the availability of the language translated. For instance, the following screenshot is from a user's browser with the first preferred language set to be Chinese. The script can be used by users who use the command-line shell to work on their translations by just running the grails command "grails diffI18n", as shown below.

mdesales@csvn:/u1/development/workspaces/collabnet/svnedge-1.3.4/console$ grails diffI18n
Welcome to Grails 1.3.4 - http://grails.org/Licensed under Apache Standard License 2.0
Grails home is set to: /u1/development/ide/springsource/grails-1.3.4
Base Directory: /u1/development/workspaces/collabnet/svnedge-1.3.4/console
Resolving dependencies...Dependencies resolved in 2858ms.
Running script/u1/development/workspaces/collabnet/svnedge-1.3.4/console/scripts/DiffI18n.groovy
Environment set to development

####### CollabNet Subversion Edge Language Keys Diff Util ########
# Available Languages at'/u1/development/workspaces/collabnet/svnedge-1.3.4/console/grails-app/i18n/'
# 1) Spanish (es)
# 2) French (fr)
# 3) Russian (ru)
# 4) Chinese (China) (zh_CN)
# 5) German (de)
# 6) Dutch (nl)
# 7) Italian (it)
# 8) Thai (th)
# 9) Portuguese (pt)
# 10) Japanese (ja)

The list of all language messages is displayed and the user can choose which language to compare with. After choosing the language, the script reports if there are new keys added or removed. The following example shows the use of the script with Chinese while translating, where 7 new strings were added in the English version. The user can open the list of changes in report file .diffprops.

# Choose one to diff with the English version: 4
# You selected 4. Diffing that language with English
# The language 'Chinese (China)' needs more 624 strings
# See the diff at/u1/development/workspaces/collabnet/svnedge-1.3.4/console/grails-app/i18n/diffI18n_zh_CN.diffprops
# Remember to edit your language 'Chinese (China)' using an editor inthe format UTF-8.

The following section are screenshots of some of the languages available.

Screenshot: Subversion Edge in Chinese China-Flag.png


Screenshot: Subversion Edge in English United-States-of-America-Flag.png


Screenshot: Subversion Edge in Japanese Japan-Flag.png


Screenshot: Subversion Edge in Portuguese Brazil-Flag.png



Introduction and Setup

The CollabNet Subversion Edge Functional Tests are based on the Groovy on Grails plugin "Functional Tests". But, before you get started with them, make sure you have covered the following required steps:

Besides Unit and Integration tests used during development, the source-code under development already contains the functional tests plugin support and some developed classes, as shown in the Eclipse view "Project Explorer". In the file system, the files are located at CSVN_DEV/test/functional, where the directory CSVN_DEV is where you have previously checked out the source-code. Those set of test cases are the last one being run in our internal Continuous Integration server (Hudson) and it's usually a good place to find bugs related to the user-facing features during development.


Functional Tests Basics

This section covers the basics of the functional tests infranstruction on Subversion Edge and assumes you are already familiar with the Grails Functional Tests plugin documentation. The plugin is already installed in the Subversion Edge development project, as you can use the commands to run a functional test and visualize the test results and report. The test cases are run as RESTful calls to the controllers defined by the application, but it can also use a URL. For instance:

  • get("/user/list") is actually making an HTTP Request to get("http://localhost:8080/csvn/user/list").
  • get("http://ctf.open.collab.net") is used to access external sites, and therefore, should only be used when accessing resources outside SvnEdge. An example of such use is the TeamForge conversion tests.

After the execution of an HTTP method wrapper such as "get()" or "post()", any test case has the access to the response object "this.response" with the HTML code payload. Grails uses this object to execute any of the "assert*" methods documented.

Another important piece of configuration is the CSVN_DEV/grails-app/conf/Config.groovy. Althoug Grails grails uses the closure "environment.test", SvnEdge uses the general closure "svnedge" during development and test phases and, therefore, values from configuration of that closure are accessable from the test classes.

Functional tests infrastructure

Considering you have your development infrastructure set up, you will find the current implementation of functional tests at the directory "CSVN_DEV/tests/functional". Notice that the directory structure follows the Java convention for declaring packages, and has already been configured to be included as source-code directories in the current Eclipse configuration artifact ".classpath" on trunk.


We have created the following convention for defining the packages and functional test classes:

  • com.collabnet.svnedge

The package containing major abstract classes to embrace code reuse while aggregating reusable patterns throughout the entire Test infrastructure. The reusable utility methods were extracted during the first iteration of the development of the SvnEdge functional tests. For instance, the access to the configuration keys from "CSVN_DEV/grails-app/conf/Config.groovy" can be easily accessed from the test cases using the method "getConfig()" or just "config". Similarly, the access to the i18n keys can be performed by calling "getMessage('key')", as the value of "key" is one of the keys located at the "messages.properties", which renders strings displayed in the User Interface. Note that the English version of the i18n messages are used in the functional tests. Moreover, the abstract classes have their own intent for the scenarios found on Subversion Edge functionalities:

  1. AdminLoggedInAbstractSvnEdgeFunctionalTests: test class that sets up the test case with the user "admin" already logged in ("/csvn/status/index").
  2. LoggedOffAbstractSvnEdgeFunctionalTests: test class that starts the application in the index auth page where a user can login ("/csvn/auth/index").
  • com.collabnet.svnedge.console

The test cases related to the web console, or Subversion Edge itself. Different components must have its own package. For instance, take the name of the controllers to as the name of the component to be tested such as "user" and "repo", as they should have their own test packages as "com.collabnet.svnedge.console.ui.user" and "com.collabnet.svnedge.console.ui.repo", respectively. The only classes implemented at this time are the login

  • com.collabnet.svnedge.teamforge

The test cases related to the teamforge integration. As you will see, there are only one abstract class and two functional classes covering the functional tests of the conversion process when the server has repositories to be imported (Full Conversion) and when the server does not have any repository created (Fresh Conversion). The latter case is a bit tricky as the SvnEdge environment defines a fresh conversion when its database does not have any repository defined. In this way, test cases related to repositories need to make sure to "discover" repositories if the intent is to verify the existence of repositories in the file-system.

Writing New Functional Test Cases Suite

This section describes how to create test suites using the Functional Tests plugin. In order to maximize code-reuse, we defined a set of Abstract classes that can be used in specific type of tests as shown in the diagram below. Instead of each test case extend the regular class "functionaltestplugin.FunctionalTestCase", we created a more general abstract class "AbstractSubversionEdgeFunctionalTests" to define general access to configuration artifact, internationalization (i18n) message keys, among others. In addition to the infrastructural utility methods, the main abstract SvnEdge test class contains a set of "often used" method executions such as "protected void login(username, password)", which is responsible for trying to perform the login to SvnEdge for a given "username" and "password". The result of the command can then be verified in the body of the implementing class. More details later in this section. First, any test will be implementing one of the test scenario classes: "AdminLoggedInAbstractSvnEdgeFunctionalTests" or "LoggedOutAbstractSvnEdgeFunctionalTests". However, the test cases for the conversion process needed a specialized Abstract class "AbstractConversionFunctionalTests", which is of type "AdminLoggedInAbstractSvnEdgeFunctionalTests" because only the admin user can perform the conversion process.


As it is shown in the UML Class Diagram above, the AbstractSvnEdgeFunctionalTests extends from the Grails Functional Test class. In this way, it will inherit all the basic method calls for assertions from JUnit and grails. The class is shown in RED because it is a "PROHIBITED" class. That is, no other classes but the GREEN ones should directly extend from the RED class. The fact is that the test cases implementation in Subversion Edge only has 2 different types of tests and, therefore, new test cases should only inherit from "AdminLoggedInAbstractSvnEdgeFunctionalTests" or "LoggedOutAbstractSvnEdgeFunctionalTests". Similarly, additional functional tests to verify other scenarios from the conversion process has to inherit the behavior of the abstract class "AbstractConversionFunctionalTests".

Basic Abstract Classes

As described in the previous sections, the two major types of test cases are related to when the Admin user is logged in and when there is no user logged in. That is, tests that require different users to login can use the latter test class to perform the login and navigate through the UI. Before continuing, It is important to note that the Functional Tests implementation are based on JUnit using the 3x methods name conversions. For instance, the methods "protected void setUp()" and "protected void tearDown()" are called before and after running each test case defined in a test class. Furthermore, it is also important to to call the super implementation of each of the methods because of the dependency on the Grails infrastructure. Take a look at the following JavaDocs to have an idea of the basic utility methods implemented on each of them.

Just as a reminder, upon executing the test cases defined in a class, JUnit executes the method "setUp()". If any failure occurs in this test, Grails will fail not only the first test case, but ALL the test cases defined in the Test Suite. This is related to the fact that the method "setUp()" is executed before the execution of each test case. Once the execution of a given test case is finished, the execution of the method "tearDown()" is performed. Any failure on this method also results in ALL test cases to fail.

The test cases defined in the abstract classes are defined to give the implementing concrete classes the access to all the important features for the test cases. As mentioned earlier, utility methods to access the configuration properties and internationalization (i18n) messages are provided. In addition, convenient test cases for performing assertions are also implemented in the Abstract classes. The next sections will provide in-depth details in the implementation of the test suites.

Concrete Functional Tests Suites Implementation

The simplest implementation of Functional Tests is the LoginFunctionalTests used as an example before. However, executing the scenario to be implemented using the production version is the first recommended step before writing any piece of code. You need to collect information about the scenario to be executed, choose UI elements to use in your test case, etc. For instance, consider the execution of the Login scenario of a user with wrong username. By default, the development and test environments of Subversion Edge will be bootstrapped with different users such as "admin", "user" and "user.new". Considering a scenario where the attempt to login with a wrong username called "marcello" is performed as the result is shown in the screenshot below:


The test case shows that by entering a wrong username and password, an error message is shown as the server responded with a complete and correct page (HTTP Response Code 200), although an error occurred during the execution of the test case. Based on those information, the automated tests can be written in the test suite to verify the possible test cases for the different users in SvnEdge, including the implementation of the wrong input. Note that the implementation of each test case have the procedures to be verified in the super class through the call to a method "testUserLogin" whereas the implementation of the testFailLogin() is the only implementation that is located in the LoginFunctionalTests. Other abstract and concrete test classes are shown in the UML Class diagram below. Note that the YELLOW classes are the concrete classes that extends the functionality from the abstract classes.


  • LoginFunctionalTests.html: The concret functional tests class suite that verify the login for each of the different usernames, as well as the failure tests.
package com.collabnet.svnedge.console.ui

import com.collabnet.svnedge.LoggedOutAbstractSvnEdgeFunctionalTests;

class LoginFunctionalTests extends LoggedOutAbstractSvnEdgeFunctionalTests {

    protected void setUp() {

    protected void tearDown() {

    void testRootLogin() {

    void testRegularLogin() {

    void testDotsLogin() {

    void testFailLogin() {
        this.login("marcello", "xyzt")
        assertContentContains getMessage("user.credential.incorrect",
            ["marcello"] as String[])

The fact is that the methods "loginAdmin()", "loginUser()", etc, are implemented in the AbstractSvnEdgeFunctionalTests to allow code reuse in other test classes, and therefore, the test case "testFailLogin()" uses the basic method "AbstractSvnEdgeFunctionalTests.login(username, password)" for the verification of a user that does not exist. Also, note that the verification of the login scenario is as simple as verifying if the a given String exists in the resulting HTTP Response output. For instance, when attempting to login with a user that does not exist, the error message "Wrong username/password provided for the user "marcello". This is due to the fact that the String is located in the messages bundle "user.credential.incorrect" and the method "getMessage()" is the helper method implemented in the class AbstractSvnEdgeFunctionalTests.

Another important thing to keep in mind is about code convention. The name of test cases are defined as cameCase, prefixed by the keyword "test". The name of the test cases can be as long as "AbstractConversionFunctionalTests.html". The most important point here is that the name of the method must be coherient to the steps being performed. Also, note that Groovy accepts a more relaxed code notation, which makes it easy to read:

        // JAVA method invocation Notation
        this.login("marcello", "xyzt")

        // GROOVY method invocation Notation
        this.login "marcello", "xyzt"

When it comes to the real implementation of a given scenario, you have to constantly refer to the Grails Functional Tests documentation and that's where you will find your "best friends". Yes!!! Your best friends! The assert methods that will help you verify the results of the HTTP Response. But first, let's take a look at the implementation of the basic method that performs "login" and "logout". As we know from the definition of the abstract classes, each time a method from a class that extends "LoggedOutAbstractSvnEdgeFunctionalTests" is executed, the method setUp() inherited from this class is executed first.

public abstract class LoggedOutAbstractSvnEdgeFunctionalTests extends AbstractSvnEdgeFunctionalTests {

    protected void setUp() {
        //The web framework must be initialized.


        if (this.response.contentAsString.contains(
                getMessage("layout.page.login"))) {

    protected void tearDown() {
        //Stop Svn Server in case it is running


        //The tear down method terminates all the web-related objects, and
        //therefore, must be performed in the end of the operation.

Note that the implementation of the concrete classes MUST make a call to the super.setUp() first, so it executes the depending steps. As you can see in the class implementation below, the method setUp() will first make a request to "/", that is, "http://localhost:8080/csvn/" since the RESTful method "get()" uses the base URL + the context name "/csvn". Then, the first assertion is important to verify that the Server is up and running, as well as verifying that the request did not return any error in the UI. Bookmark the RFC2616 and use the HTTP Response Status Codes as required. The default one to verify is "200", even though the scenario results in an error message as the test case "LoginFunctionalTests.testFailLogin()". Finally, after verifying if the status code is as expected, the test uses the object "response" to verify if the HTML content contains the string identified by the key "layout.page.login" in the the i18n artifact "CSVN_DEV/grails-app/i18n/messages.properties". For this case, the method is verifying for the key:


Following the way JUnit implements the test execution cycle, the method "tearDown()" is executed right after each method "testXYZ()" is executed. In our case, there are a few steps to be verified before terminating the test case. As it might be necessary, the HTTP server might have been started during a test case, and therefore, the method "stopSvnServer()" is called. This is specially placed in the "highest" abstract class because all types of test cases might want to start the HTTP server from the status page. After an HTTP reques to "/" is performed, the verification to the output is performed to and in case is necessary, the method "logout()" is executed as implemented in the abstrac class "AbstractSvnEdgeFunctionalTests". That is, if the HTML code from the response object contains the string identified by the key "layout.page.logout" (LOGOUT), then click in the link "LOGOUT". Then, assert if the HTTP response status was equals to 200 and that the content contains the header string "Login" identified by the key "login.page.auth.header".

     * Performs the logout by clicking on the link.
    protected void logout() {
        def logout = getMessage("layout.page.logout")
        if (this.response.contentAsString.contains(logout)) {
            click logout

Similarly, test cases that perform login will essentially fill out the login form and click on the button "Log in". The basic implementation of the method "login(username, password) is shown below. The HTTP GET Request to the page "/login/auth" is performed followed by the assert of the status code. Then, if the test environment keeps the user Logged In as a result of a failure of any previous test case, the verification if the user is logged in is performed so that the call to the method "logout()", as shown above, is performed. Finally, when the user s in the front page, the login form is filled out with the correct values. Please refer to the "Grails Functional Tests Documentation" for details on how to fill out and submit form fields, but it should be straightforward. The only detail needed is to capture the name of the form defined in the HTML code. A good helper way is to use Google Chrome or Firefox "Web Developer" plugin to capture the UI element "ids". Specifically for the form submission, the ID of the form and the "id"s from the form fields are necessary. Then, the label value of the SUBMIT button is necessary, and as shown in the code below, that string is located in the string with the key "layout.page.login".


    protected void login(username, password) {

        if (this.response.contentAsString.contains(
                getMessage("layout.page.login"))) {
        def login = getMessage("layout.page.login")
        form('loginForm') {
            j_username = username
            j_password = password
            click login

It is extremely important to note here a very hard problem when it comes to "clickable" items in the UI. Since we are using a mix of the Grails GSP tags and some CSS styles from TeamForge, Grails creates the buttons in a different way for Forms and Places without the HTML form entity. Whenever a form was generated by Grails, the Submit button like the "login" one showed above will only respond to the command "click LABEL" inside of the form() closure. On the other hand, the command "click LABEL" will only perform its action when declared outside of the form() closure. Different examples of these GOTCHAS have been found while the Conversion tests were being written.

To summarize the steps to automate manual tests with corresponding Functional Tests, the suggested steps are as follows:

  1. . Perform the test scenario manually and gather necessary information about the User Interface, choosing unique elements that are present in the resulting action. For the case of login, the verification of the string "Logged in as:" is perfomed. For tests exploring failures and error messages, choose to assert about the existence of these error messages.
  2. . Once you are familiar about how the scenario behaves, create the main Test Case Suite by extending from one of the GREEN abstrac classes in the UML Class Diagram shown above. Choose the names related to the component.
  3. . Propose code reuse by implementing new methods in the AbstractSvnEdgeFunctionalTests if necessary, or if other components will use the same implementation. If not, keep the implementation in the test class developed.
  4. . Add JavaDocs to the methods that are going to be inherited or are difficult to understand. Try documenting the method execution before writing the test case as you will understand the scope of the test better. Next section will provide a good understanding on how to write those supporting documentation.

Running Functional Tests

As described in Grails functional tests "mini bible", the only thing needed to run a functional test case is the following command under the directory CSVN_DEV:

grails test-app -functional OPTIONAL_CLASS_NAME

The command will start the current version of Grails installed using the functional tests environment. If you don't provide the optional parameter "OPTIONAL_CLASS_NAME", grails executes all the functional tests defined. However, since the execution of all current implementation of test classes takes more than 10 minutes, use the complete name of the test class (package name + name of the class - sufix "Tests"). For instance, the following command executes the functional Tests implemented in the class LoginFunctionalTests:

grails test-app -functional com.collabnet.svnedge.console.ui.LoginFunctional

The command selects the test suite class "CSVN_DEV/tests/functional/com/collabnet/svnedge/console/ui/LoginFunctionalTests.groovy" to be executed, as the output of the execution of the test cases identify the environment and the location where the test reports will be saved. The recommendation here is to keep using the Eclipse STS infrastructure to save your commands execution as shown below.


As shown below, the functional tests execution output is the same from executing the tests using the command line or the Eclipse command as shown in the output view. The tests are prepared to be executed and save the output logs and reports in the directory "CSVN_DEV/target/test-reports".

Welcome to Grails 1.3.4 - http://grails.org/
Licensed under Apache Standard License 2.0
Grails home is set to: /u1/svnedge/replica_admin/grails/grails-1.3.4/

Base Directory: /u1/development/workspaces/collabnet/svnedge-1.3.4/console
Resolving dependencies...
Dependencies resolved in 1565ms.
Running script /u1/svnedge/replica_admin/grails/grails-1.3.4/scripts/TestApp.groovy
Environment set to test
    [mkdir] Created dir: /u1/development/workspaces/collabnet/svnedge-1.3.4/console/target/test-reports/html
    [mkdir] Created dir: /u1/development/workspaces/collabnet/svnedge-1.3.4/console/target/test-reports/plain

Starting functional test phase ...

Once the functional tests execution finishes the execution, the test reports are written and can be accessed using a web browser. The following snippet shows the result of running the test case started above, which shows how long it took Grails to execute the 4 test cases defined in the LoginFunctionalTests test suite, the stats of how many tests passed or failed, as well as the location where the test reports are located along with the final result of PASSED or FAILED. Note that the directory "target/test-reports" is relative to the directory "CSVN_DEV" as described above.

Tests Completed in 12654ms ...
Tests passed: 4
Tests failed: 0
2010-09-28 12:19:11,334 [main] INFO  /csvn  - Destroying Spring FrameworkServlet 'gsp'
2010-09-28 12:19:11,350 [main] INFO  bootstrap.BootStrap  - Releasing resources from the discovery service.
2010-09-28 12:19:11,350 [main] INFO  bootstrap.BootStrap  - Releasing resources from the Operating System service.
2010-09-28 12:19:11,352 [main] INFO  /csvn  - Destroying Spring FrameworkServlet 'grails'
Server stopped
[junitreport] Processing /u1/development/workspaces/collabnet/svnedge-1.3.4/console/target/test-reports/TESTS-TestSuites.xml
                  to /tmp/null1620273079
[junitreport] Loading stylesheet jar:file:/home/mdesales/.ivy2/cache/org.apache.ant/ant-junit/jars/ant-junit-1.7.1.jar
[junitreport] Transform time: 2339ms
[junitreport] Deleting: /tmp/null1620273079

Tests PASSED - view reports in target/test-reports
Application context shutting down...
Application context shutdown.

Accessing the Test Results Report

Once the execution terminates, you can have access to the test reports. This is where you will find all the answers to the test results, including the detailed information of the entire HTTP payload transmitted between SvnEdge server and the Browser emulator that the Functional Tests use. As shown below, the location of the test cases reports is highlighted as a hyper-link to the index page of the test reports. Clicking on it results on opening the Eclipe's built-in browser view with the reports.


This report is generated per execution, and therefore, they are deleted before each new execution. In case you need keep information of a test run, copy the contents of the directory "CSVN_DEV/target/test-reports", as you will find reports in both HTML and XML. The report for each test suite includes the list of each test case run, the status and time of execution. The report includes 3 main output:

  • Properties: system properties used.
  • System.out: the output of the standout output of the process; same output print in the grails output, but more organized.
  • System.err: the output of the standard error of the process.

The most used output is the System.out. Clicking on this hyper-link takes you to the organized output of the traffic, highlighting the HTTP Headers, HTTP Body, redirects, test assersions and test results.

Identifying Test cases report scope

The link to the System.out output is the most important and used throughout the development of the test case, as the output of the execution of each test case is displayed in this area.


Each test case has its own test result scope, and you can easily identify the initialization of the execution of a test case by the key "Output from TEST_CASE_NAME", where "TEST_CASE_NAME" is the name of the method name that defines the test case. For instance, the log for the execution of the test cases for the LoginFunctionalTests includes the following strings:

--Output from testRootLogin--
--Output from testRegularLogin--
--Output from testDotsLogin--
--Output from testFailLogin--

The output of the execution of the HTTP Request Header of a test case is started with ">>>>>" shown as follows:

>>>>>>>>>>>>>>>>>>>> Making request to / using method GET >>>>>>>>>>>>>>>>>>>>
Initializing web request settings for http://localhost:8080/csvn/
Request parameters:
Request headers:
Accept-Language: en
Accept: */*

On the other hand, the output of the HTTP Response Header of a test case is started with "<<<<<<" as shown below. The HTTP Reponse Header Parameters are output for verification of anything used by the test cases. Note that following access to the "/csvn/" "root" context results in an HTTP Forward to the "Login Page" identified by the context "/csvn" controller "/login/auth" and, therefore, there is not "Content" available.

<<<<<<<<<<<<<<<<<<<< Received response from GET http://localhost:8080/csvn/ <<<<<<<<<<<<<<<<<<<<
Response was a redirect to
  http://localhost:8080/csvn/login/auth;jsessionid=hueqpw5eaq32 <<<<<<<<<<<<<<<<<<<<
Response was 302 'Found', headers:
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Set-Cookie: JSESSIONID=hueqpw5eaq32;Path=/csvn
Location: http://localhost:8080/csvn/login/auth;jsessionid=hueqpw5eaq32
Content-Length: 0
Server: Jetty(6.1.21)


#Following redirect to http://localhost:8080/csvn/login/auth;jsessionid=hueqpw5eaq32
>>>>>>>>>>>>>>>>>>>> Making request to http://localhost:8080/csvn/login/auth;jsessionid=hueqpw5eaq32
 using method GET >>>>>>>>>>>>>>>>>>>>

If the HTTP Response contains the body payload, it will be output as is in the Content section:

<<<<<<<<<<<<<<<<<<<< Received response from
  GET http://localhost:8080/csvn/login/auth;jsessionid=hueqpw5eaq32 <<<<<<<<<<<<<<<<<<<<
Response was 200 'OK', headers:
Expires: -1
Cache-Control: no-cache
max-age: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private
Content-Type: text/html; charset=utf-8
Content-Language: en
Content-Length: 4663
Server: Jetty(6.1.21)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">

    <title>CollabNet Subversion Edge Login</title>
    <link rel="stylesheet" href="/csvn/css/styles_new.css"
    <link rel="stylesheet" href="/csvn/css/svnedge.css"
    <link rel="shortcut icon"

Whenever a test case fails, the error message is output as follows:

"functionaltestplugin.FunctionalTestException: Expected content to loosely contain [user.new] but it didn't"

Looking deeper in the raw output for the string "Expected content to loosely contain user.new but it didn't", you see what HTML output was used for the evaluation of the test case. Sometimes an error case is related to the current UI or to an external test verification. This specific one is related to teamforge integration as the test server did not have a specific user named "user.new" located in the list of users.

Failed: Expected content to loosely contain [user.new] but it didn't
URL: http://cu082.cubit.sp.collab.net:80/sf/sfmain/do/listUsersAdmin

Advanced Functional Tests Techniques

Once you get used to the way to write automated test cases, you should be able to implement complex test cases that involves not only the local Subversion Edge server, but also external servers such as the TeamForge server used during the tests of conversion process. Don't forget to document the steps in a structured way inside the JavaDocs, as documentation later makes it easy to understand the purpose of the tests.

Note that the JavaDocs of the classes contain a more detailed specification of the execution of the test cases. For example, the sentences starting with "Verify" are related to the assertions necessary to verify the test case, while "Go to" are related to the HTTP Request method "get()". Each of the sections are identified so that the implementation of the methods setUp(), tearDown(), and the actual method are explicitly written using Groovy. The source code has more detailed implementation of the test cases.

Test Case 1: Successful conversion to TeamForge Mode

   * SetUp
        * Login to SvnEdge
        * Revert to Standalone Mode in case on TeamForge Mode

   * Steps to reproduce
         * Go to the Credentials Form
         * Enter correct credentials and existing CTF URL and try to convert;

   * Expected Results
         * Successful conversion message is shown
         * Login -> Logout as admin
         * Verify that the server is on TeamForge mode;
         * Login to CTF server and verify that the system ID
            from the SvnEdge server is listed on the list of integration servers

   * Tear Down
         * Revert conversion if necessary
         * Logout from the SvnEdge server

The implementation of complex test cases might require verification of different properties of local and external resources. The example of the conversion process was the first challenge of this nature we had to implement. The following code snippet is the implementation of assertions of the conversion as the Expected results. Note that the method custom assertion methods were written to support this implementation ("assertProhibitedAccessToStandaloneModeLinksWorks()" and "assertConversionSucceededOnCtfServer()".

     * Verify that the state of the conversion is persisted:
     * <li>The local server shows the TeamForge URL
     * <li>The CTF server shows the link to the server. This can be verified
     * by the current system ID on the list of integration servers.
    protected void assertConversionSucceeded() {
        // Step 1: verify that the conversion is persistent
        assertStatus 200

        assertStatus 200

        // verify that the software version is still shown

        assertStatus 200

        // verify that prohibited links work

        // Step 2: verify that the CTF server DOES list the system ID

Using the response object

As seen in some of the examples, the assertions are the way to verify that a given expected value exists in the HTTP Response payload received from the Server. However, whenever the test case needs to make a decision based on the contents of the response object, you can use the direct access to the response object. For instance, instead of failing a test that needs to have the user logged out, this code snippet verifies if the user is logged in and then performs the logout procedure. The same logic can be applied in different scenarios such as verifying if the server is started/stopped by verifying the status page button. Similarly, the test can verify if there are any created repositories in the file-system before creating a new test repository.

        if (this.response.contentAsString.contains(getMessage("layout.page.login"))) {

Dealing with external resources

The nature of Subversion Edge requires the integration with TeamForge, and how about testing the state of both systems in the same test case? Considering the Grails Plugin allows external HTTP requests during tests, why not performing the same steps an Admin would do to verify the state of the server? This was a bit tricky, but works like a charm. As we had designed before, reusing the configuration was the first step to define which remote TeamForge to use during tests. Then, the Test case could take care of automating the ways to generate the URL for the CTF server based on the configuration parameters during the tests of conversion. Here's the closure in the file "CSVN_DEV/grails-app/conf/Config.groovy" that one can change which TeamForge server to use (svnedge.ctfMaster).

    ctfMaster {
        ssl = false
        domainName = "cu082.cubit.sp.collab.net"
        username = "admin"
        password = "admin"
        port = 80
        systemId = "exsy1002"

Taking a closer look of what we needed, this is related to the assertions for the last expected result "Login to CTF server and verify that the system ID from the SvnEdge server is listed on the list of integration servers". So, the translation of this sentence into Groovy code originated the method call "AbstractConversionFunctionalTests.assertConversionSucceededOnCtfServer()", as the steps to perform this assertion are used by all different scenarios. As implemented, the first step requires that the login to TeamForge take the user to the Administration page "List Integrations" using the method " this.goToCtfListIntegrationsPage()" before verifying if the system ID saved by the conversion process exists in that page. However, observations on how the HTTP Request flow in TeamForge works was necessary to understand the forwards after the user is logged in. After building the necessary parameters in the method "loginToCtfServerIfNecessary()" was implemented with all the needed values from both the Grails Config.groovy and from the environment. As warned before, the clickable elements of forms can differ from Subversion Edge and TeamForm, and therefore, the grails element "click LABEL" was used here outside the form closure. Finally, don't be tempted to verify strings in TeamForge using i18n as they are different and Subversion Edge does not have direct access to them. Prefer validating steps using form elements or IDs produced by TeamForge as the UI can change on the remote server.

     * Verifies that the CTF server lists the current ctf server system ID.
    protected void assertConversionSucceededOnCtfServer() {

        assertContentContains("Site Administration")
        assertContentContains("SCM Integrations")
        def appServerPort = System.getProperty("jetty.port", "8080")
        def csvnHostAndPort = server.hostname + ":" + appServerPort

        // TeamForge removes any double-quotes (") submitted via the SOAP API.
        assertContentContains("This is a CollabNet Subversion Edge server in " +
            "managed mode from ${csvnHostAndPort}.")

     * Goes to the list of integrations on the CTF server
    private void goToCtfListIntegrationsPage() {
        // Goes to the list integrations page
        // http://cu073.cloud.sp.collab.net/sf/sfmain/do/listSystems
        get(this.makeCtfUrl() + "/sf/sfmain/do/listSystems")

    * Makes login to CTF server from a given point that connects to the server.
    * In case the response content DOES NOT contains the string "Logged in as",
    * then make the login. The resulting page is the redirected page requested
    * earlier.
    private void loginToCtfServerIfNecessary() {
        if (!this.response.contentAsString.contains("Logged in as")) {
            assertStatus 200
            def ctfUsername = config.svnedge.ctfMaster.username
            def ctfPassword = config.svnedge.ctfMaster.password
            form("login") {
                username = ctfUsername
                password = ctfPassword
            // the button is a link instead of a form button. Use it outside
            // the form closure.
            click "Log In"
            assertStatus 200

Test Case Suites Needed

A few test cases have been written for specific functionalities of the application. However, here's some of the test cases that can be developed.

* User Functional Tests
- Create User of each type
  - Login/Logout
  - Verify access to prohibited URLs
  - Access SVN and ViewVC Pages
- List Users
- Delete User
- Change User password
  - Logout and login with the new password.
  - Access SVN and ViewVC pages with new password
- View Self page
- Try changing the server settings, accessing other admin sections

* Repos Functional Tests
- Create Repo
- Discover Repos
- List Repos
- Edit Access Rules
  - Login with users without access to specific repos without access

* Statistics Functional Tests
- Access the pages for statistics

* Administration Functional Tests
- Changing server settings as Admin
- Changing the server Authentication settings
  - Login / Logout and verify changes.
  - Restart server after changing settings

* Server Logs Functional Tests
- Change log level
- View log Files
- View non-existing file
- View existing file
- View log files

* Packages Update Functional Tests
- Update the software packages
- Convert the server and try to update the server to new version

If you have any questions regarding the Functional Tests specification, please don't hesitate to send an email to dev-svnedge@ctf.open.collab.net.

Marcello de Sales - Software Engineer - CollabNet, Inc.


Here we will collect common questions and answers about Subversion Edge.

General Questions

What is Subversion Edge? Is it different from Subversion?

Subversion Edge is a packaging of a complete certified stack of Apache, Subversion and ViewVC along with a new browser-based graphical user interface for managing this stack. The installation is simple and all subsequent configuration is performed from the web browser. Subversion Edge keeps all of these components up to date through your web browser and makes sure they all work together nicely. In terms of Apache and Subversion it includes our certified binaries and these are the standard open-source released versions. The source code and scripts that we use to build the binaries can be viewed in our Subversion Repository

Can I upgrade from my current installation of Subversion?

Yes you can upgrade from your current Subversion installation relatively easily. We are tracking the documentation for this process in this wiki page - MigrationPath.

How many servers can I manage?

Subversion Edge can be used to manage a single Apache Subversion server. It lives on the same server as Subversion and sits beside it to provide a management console. If you have multiple Subversion servers to manage, consider upgrading to CollabNet TeamForge which allows you to manage several Subversion Edge servers all from a single UI.

How is the product licensed?

Subversion Edge is dual licensed under the open-source GNU Affero General Public License v3 (AGPLv3) and a commercial CollabNet license for partners that would like to integrate Subversion Edge into their proprietary offerings.

What is the cost?

Subversion Edge is free and available as open-source. Contact CollabNet if you are interested in a commercial license for Subversion Edge.

Do you offer support or training?

Yes, we provide support and training offerings for Subversion Edge.

Minimum requirements for installation?

Subversion Edge is written in Java and requires a Java 6 runtime environment. Other than that, it does not have high requirements. As a Java server app, it should ideally have about 512 MB of RAM available to it. Ultimately, the Apache Subversion server is likely to be a bigger driver of the hardware requirements of the server. Subversion Edge does not interfere with the performance of your Apache Subversion server, it simply automates the configuration and management of that server. Ideally, it makes it run a little more efficiently by configuring and managing it properly.

Do I have to use the whole bundle?

No, but we only offer a single install option that installs the whole bundle. Once it is installed, you do not have to run the Subversion Edge web application if you just want to use the Subversion binaries.

Does it work with TeamForge or other ALM applications?

Yes. Subversion Edge works with CollabNet TeamForge 5.4. Your Subversion Edge server can be converted into TeamForge mode where it becomes controlled and managed by TeamForge. This allows you to take advantage of the additional administrative capabilities of TeamForge as well as the additional ALM features it provides.

Does it work with other servers besides Apache?

No. Subversion Edge only supports the Apache Subversion option. There are no plans to support the svnserve server option. svnserve is a lightweight server that offers good performance, but it does not provide the features needed in an enterprise environment. If you do not want to use Apache, you could install Subversion Edge and then just use the binaries we provide.

Does it work with ScrumWorks?

Not yet, but that is something we are looking at on our combined product roadmaps.

How can I edit the Apache configuration files?

Subversion Edge will generate the httpd.conf from the web UI on your first use, after that, it never touches the httpd.conf file again so you are free to edit the file as you need. The settings in SVN Edge that relate to the Apache server are written into additional .conf files that are used in the httpd.conf file by an Include statement. If you need to edit something that lives in one of these generates files then you must copy and paste the contents of the file into httpd.conf and comment out the Include statement. You are then free to edit the directives as needed. Of course future changes in the SVN Edge web UI will be written to a file that is no longer being Included. So you will need to make the changes manually in httpd.conf.

To lessen the impact of this we try to split the content among several generated files. So hopefully you can limit the impact to one of the files and still use the web UI for some of the configuration tasks. That said, the Apache configuration tends to be fairly static. Once you define your settings there is rarely a need to change them in the future.

How do I use various Subversion hooks with Subversion Edge?

The Subversion hooks for your repositories are the same ones available for any Subversion server. As part of our release qualification process we tested how a user would setup and use some common Subversion hook scripts. These scripts all require the Subversion Python bindings and so this testing ensured we had packaged the bindings in a way they could be used easily from hooks. This information is provided as an example of setting up some fairly complicated hooks.

How do I report a problem or request a new feature? Where is your issue tracker?

We encourage users to post question and report problems in our user discussion forum. This is the best place to have a conversation and it allows other users to participate and benefit from the exchange of information. We also have a Tracker for User Requests that is part of this project. Bugs and enhancement requests can be filed in the tracker if desired. Anything that might best be described as a question, or if you just are not sure where to post, then it should go to the user discussion forum.

How can I reset my admin password?

Presumably your admin password has been changed to something else and you have forgotten it. The only way to reset this without deleting the database is to edit it directly (it's pretty easy).

  • Stop the Subversion Edge service on Windows or run the $ bin/csvn stop command on Linux/Solaris
  • Find your install directory (eg, c:\csvn). This will contain a folder named data which contains a file named "csvn-production-hsqldb.script". Open this file in a text editor.
  • Search for "'admin'" (with the single quotes) -- you should find a row that looks like this:
INSERT INTO USER VALUES(1,2,'admin user','admin@example.com',TRUE,
    '78989asdef7898abde4252aedcb4352','Super Administrator','admin')
  • Replace the long encrypted password field ("789...") with this: 21232f297a57a5a743894a0e4a801fc3
  • Save, and restart the Subversion Edge service.

admin/admin should work after that.

Windows-specific Questions

What versions of Windows do you support?

Subversion Edge is a server application, so we focus our certification process on Windows 2003 and 2008 Server editions. We support both 32 and 64-bit versions although we are currently only providing 32-bit binaries for Subversion and Apache. However, our installer is 64-bit and we are testing on 64-bit OS. A future update will deliver the native 64-bit binaries to users that use the 64-bit installer.

Our developers and team also test on Windows XP/Vista/7 but we recommend you deploy the application in production on the Server editions of Windows.

When I try to access ViewVC, why am I getting an Internal Server Error HTTP - 500?

This problem is typically caused because you have conflicting DLL's in your Windows system32 folder. We did not want our installer to mess around with this folder, so we do not try to fix your system. In our own testing, the most common cause of this problem was if you have previously installed ActiveState Python 2.5. Their installer puts some DLL's that begin with "py" in the system32 folder. Moving these to a temp folder immediately solves the problem. We are using the Python distribution from python.org and the DLL's appear to conflict with one another. A similar problem can occur if you have conflicting OpenSSL DLL's in the system32 folder. These are the files (libeay32.dll and sslway32.dll). Typically, rebooting the server after installing our application resolves this problem because we put our folder first in the PATH. You could also remove the DLL's.

Rebooting the computer after the install has also helped some users. We have not tracked down the exact scenarios where this helps, but we think there are situations where the Windows services we create do not pick up the change to the system PATH variable until after a reboot.

Linux-specific Questions

What versions of Linux do you support?

We officially certify the application on CentOS 5, RHEL 5 and SuSE 11 in both 32/64 bit. However, the application is packaged as a simple .tar.gz that you should be able to install and run successfully on any flavor of Linux. Our developers use a mixture of Ubuntu and Fedora and the application works fine on all of these OS. We endeavor to work properly on all of these OS but we can only officially certify the distributions that our QA and Support teams have access to and support.

LDAP Questions

How can I restrict logon to members of a particular group?

You can restrict the logon to one or more groups using the LDAP filter attribute. Here is an example that filters on a single group:


And here is an example that allows users from two different groups:


How can I configure Apache to validate the self-signed SSL certificate used by my LDAP server?

If your LDAP server uses a custom SSL certificate and you want Apache to validate that certificate, you can add this directive to httpd.conf:

Include "path/to/csvn_main_httpd.conf"
LDAPTrustedGlobalCert CA_BASE64 path/to/LDAP-Server.crt

Refer to the documentation of this directive in the Apache documentation.

How can I connect to my Microsoft Active Directory?

Active Directory can be connected using the LDAP support in Subversion Edge. Unfortunately there is no magic set of settings we can tell you that will work for every server and requirement. Here are the settings that work with the Active Directory server in our internal engineering lab. These settings work from Windows, Linux and Solaris servers:

LDAP Security Level:  NONE
LDAP Server Host:     xxx.yyy.collab.net
LDAP Server Port:     389
LDAP Base DN:         OU=Users,DC=xxx,DC=yyy,DC=collab,DC=net
LDAP Bind DN:         CN=my_user,OU=Users,DC=xxx,DC=yyy,DC=collab,DC=net
LDAP Bind Password:   xxxxxxx
LDAP Login Attribute: samAccountName
LDAP Search Scope:    sub
LDAP Filter:          (&(objectClass=user)(memberOf=CN=dev_group,OU=Groups,DC=xxx,DC=yyy,DC=collab,DC=net))

These settings also show how to use the LDAP Filter to restrict the login to a specific LDAP group. This example uses the default LDAP port of 389, but a lot of Active Directory users have better luck using port 3268 which causes the queries to go to the Active Directory Global Catalog.

Finally, I would also recommend reading this blog post on configuring Subversion for LDAP. It has a lot of good information as well:http://blogs.collab.net/subversion/2009/03/subversion-with-apache-and-ldap-updated/

How can I troubleshoot problems with LDAP configuration?

Setting the Apache server log level to DEBUG will cause the LDAP module to output information to the error log. You can set the log level from the Administration tab in the web console. Click on Server Logs and then Configure. You can also view the error log from this screen. For some types of problems this will give you more information to help know what is wrong. Also read the section Authentication Phase in the Apache docs. This explains how the LDAP module connects to the server and verifies the credentials. Understanding how it works can help you understand the values you need to enter. Finally, it can sometimes be easier to download a graphical LDAP client and use it to experiment with settings and explore your LDAP tree. We recommend the Apache Directory Studio client for this.