Setting up SVN on IS: Works smoothly with IS v9.12, but not with IS v9.8

Hello Tech Community,
I have successfully set up SVN support on a local IS v9.12 running on a Windows computer according to the “Configuring the VCS Integration Feature”. So I know the procedure and know that the SVN repository is set up properly.

Then, I wanted to configure SVN on our central development IS v9.8 which is running on RHEL. However, when I come to the step where I have to enter the location of the SVN repository (chapter “Connecting to Subversion for the First Time”) and click “Save Changes”, the browser sends the request to the web server and then waits for a reponse (“Waiting for response …”) literally for hours (I waited approx. 2 hours since the IS hosts about 100 packages; this step took only about 3-4 minutes on my local IS, but it hosts only about 30 packages). Neither the error log nor the server log contain any related records. Additionally, I checked the following prerequisites:

  • the Apache SVN client version 1.7.14 is installed (/usr/bin/svn)
  • the path to the SVN client is included in the user’s path variable (/usr/bin)
  • connectivity from IS to SVN server verified

I have searched the forums and KB articles, but didn’t find any applicable hint.

Hence, I don’t know why it is not working. Has anybody an idea?

Best regards,

Hi Marcus,

please check for Fixes for the VCS feature itself as well as for the Subversion integration package.
These should be listed under IntegrationServer in UpdateManager.


Hello Holger,
sorry, I forgot to mentioned that we had checked for fixes in the Update Manager too, but did not find any related fixes.

Any other ideas?

Best regards,

Hello again,
I wanted to share how I solved the issue since there were still some obstacles to overcome, which were not mentioned in the manual, and I had to rely on guessing since the IS didn’t redirect neither the standard output stream nor the error output stream from the SVN client to the error/server log.

  • SVN client: Disable Kerberos authentication
    Unless you have removed the negotiate option from the http-auth-types settings in the servers configuration file, any credentials passed from IS to the SVN client via command line arguments (as configured in the user mapping) will be ignored.
  • SVN client: Do not store plaintext passwords
    Unless the setting store-plaintext-passwords is set no in the servers config file, the SVN client will ask again and again which might prevent it from running silently on the command line and might cause the VCS integration to get stuck.
  • SVN client: Permanently accept invalid SSL certificates
    If a company has deployed self-signed certificates or has not properly deployed the PKI on the servers, it would result in SVN client prompting an invalid certificate. In order to catch this issue, run the SVN client at least once manually as the same user who is running IS and then permanently accept such server certificate.

I hope someone else might find these hints useful in the future when setting up Subversion support on IS.

Best regards,

Thanks, Marcus, for sharing what you learned. I’d like to warn you though: the WmVCS + WmSubversion method of integrating with Subversion is very limited and it has some substantial flaws. That’s one reason why Software AG invested in the local development solution. If you can avoid using WmVCS, I would.

If you cannot adopt local development 100%, then there are other options for committing assets from the central server that you may find more worthwhile. For example, some customers use mapped drives on developers’ workstations so they can do commits and checkouts from their machine leveraging SVN clients they are comfortable with. Now, that option is not without fault. For example, the performance hit of having to pull the assets over the network to your machine, just so you can push them over the network again to Subversion, can be substantial. However, I find that the benefits outweigh the challenges.


1 Like

Hi Pierco,
thank you for your advise! Unfortunately, we cannot fully employ local development due to certain circumstances in our current setup, but we are about to migrate to such a architecture again in order to allow for it.

Anyway, I will check the option of mapping server folders to local drives, though I guess it is not allowed.

Best regards,