Native support for SVN
This page describes an advanced feature of Fisheye's Subversion support. It explores the technical background, and some of the issues you may encounter, if you wish to use the native JavaHL access feature.
For most users we recommend that you use the default SVNKit Subversion access client that is bundled with Fisheye. You are only likely to need the native JavaHL access described on this page for certain edge case repositories.
Fisheye Subversion access
Fisheye interacts with Subversion repositories though a layer, defined by the Apache Subversion project, known as JavaHL. This is the high-level Java language binding for Subversion. There are two implementations of the JavaHL interface available:
Bundled SVNKit
The SVNKit implementation is a largely Java-based implementation provided by the SVNKit project. It is bundled with Fisheye and is the default JavaHL implementation used. As a Java implementation it operates on all of Fisheye's supported platforms.
Native JavaHL
The JNI-based implementation, coupled with a shared dynamic library, is referred to here as native JavaHL. As a native library, native JavaHL is platform-dependent. The shared library is C-based and must be compatible with the remaining Subversion client components installed on the platform. It varies across each platform and distribution.
On this page:
Native vs. bundled
Given that Fisheye bundles the SVNKit implementation, why might you want to use the native implementation of JavaHL? In general our recommendation is to stick with the bundled SVNKit implementation. It is the simplest to use and works in the widest variety of scenarios. Nevertheless, there are some scenarios where it may be desirable to use the native implementation, if it is available.
The two implementations have quite different characteristics – these can affect the decision about which to use. Here is a high-level list of some of the considerations we have encountered over the years:
| Aspect | SVNKit - bundled with Fisheye | Native JavaHL - platform dependent |
|---|---|---|
| Memory Usage | SVNKit uses the Java Heap. It therefore shares the heap that is being used for all Fisheye's operations. It does benefit, however, from Java's garbage collection mechanism and we have not seen any memory leaks. | The native JavaHL implementation uses the native process heap and not the Java heap. It can increase the overall process memory usage but does not interfere with the Java heap usage. In some rare instances, we have seen memory leaks in the C-based JavaHL code. As Fisheye is a long running service, these can cause problems over the life of the Fisheye process. |
| Speed | In general, when using any of the Subversion network protocols, the JavaHL implementation speed is not a significant factor in the overall speed of Subversion operations as they are dominated by the network latency. Even for file:// access SVNKit is rarely the bottleneck. | If you are using file:// access to talk to a Subversion repository on the same server, then native JavaHL will most likely give the highest performance. |
| Compatibility | SVNKit has proven to be highly compatible with Subversion across all releases. The project is very responsive to bug reports when any differences become apparent. As an alternative implementation of JavaHL there will be differences between the SVNKit and the native Subversion JavaHL. This may affect some edge case repositories. | JavaHL uses predominantly the same code as Subversion itself so it is virtually 100% compatible. |
| Availability | SVNKit works on all of Fisheye's supported platforms | It can be difficult to get an install of the JavaHL jar and shared library that is compatible with the version of Subversion installed on your platform. |
Native JavaHL support
The native JavaHL interface and implementation naturally change with every release of Subversion. Normally these changes are incremental and backward compatible. The compatibility matrix for Fisheye 4.1 and higher is as follows:
| Fisheye 4.1 and higher | Native JavaHL 1.7 client | Native JavaHL 1.8 client | Native JavaHL 1.9 client | SVNKit (bundled) |
|---|---|---|---|---|
| Subversion server 1.9 |  | | | |
| Subversion server 1.8 | | | | |
| Subversion server 1.7 | | | | |
| Subversion server 1.6 | | | | |
Legend: supported, 
deprecated, 
unsupported.
Installing JavaHL for your platform
Atlassian Fisheye bundles the SVNKit library to make connecting to your Subversion repository a painless process out of the box. If you do wish to use native JavaHL, it is your responsibility to install it onto your platform. Different organizations have different operating procedures and policies regarding how and what packages they are able to install on production servers.
In some cases the distribution you use will not provide a compatible JavaHL from an official package. In this case you will either need to build everything from source yourself (hard) or use a package from a Subversion vendor. We have used packages from two vendors over time, CollabNet and Wandisco. More recently, we have found it easier to use the Wandisco packages for JavaHL support.
The following sections detail our experiences when we investigated deploying JavaHL 1.7 on a variety of platforms. This is not a definitive list or guide. It is to give you an idea of the some of the issues you are likely to encounter getting a compatible JavaHL install working on a range of platforms and distributions.
32-bit / 64-bit: The DLL file is platform dependent so it needs to match the architecture of your VM. The JAR file however, contains only metadata for the JVM about how to load the DLL so the same JAR will work across 32-bit and 64-bit operating systems as long as the subversion binaries match.
Windows 7
Windows does not include a Subversion client by default so you will need to install a Subversion package. We installed the 1.7.11 "client only" install from Wandisco.This installs Subversion, including the javahl components, in C:\Program Files\WANdisco\Subversion. It is interesting to note that the JavaHL package in this install does not include the org.tigris package adapter layer.
Ubuntu 12
Ubuntu provides pckages for both core subversion and the JavaHL library for Subversion. We installed these for Subversion 1.7.5 as follows:
- sudo apt-get install subversion
- sudo apt-get install libsvn-java
Unfortunately the version installed seems to have a consistent assertion failue:
java: /build/buildd/subversion-1.7.5/subversion/libsvn_subr/dirent_uri.c:1519: uri_skip_ancestor: Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed.
We then removed the two Subversion packages from Ubuntu itself:
sudo apt-get remove libsvn-javasudo apt-get remove subversion
We installed the Wandisco packages by downloading and running the Wandisco installer:
svn1.7_ubuntu_wandisco-precise.sh
This configures the Wandisco servers as a source of packages and installs the core Subversion install. At the time of writing this installed 1.7.11. Once installed, reinstall the javahl package:
sudo apt-get install libsvn-java
This will now come from the Wandisco package repository. The location of the shared library and JavaHL jar is:
/usr/lib/jni/libsvnjavahl-1.so
/usr/share/java/svn-javahl.jarCentOS 6.4
If you install the Subversion packages (subversion and subversion-javahl) using yum, you will have a 1.6.11 install of Subversion which is not compatible with Fisheye if you wish to use JavaHL as descibed above.
If you have previously upgraded to a version of SVN 1.7 before 1.7.11 you may see the message below in your logs. If you do, please upgrade to the Wandisco SVN 1.7 as described below:
java: /build/buildd/subversion-1.7.5/subversion/libsvn_subr/dirent_uri.c:1519: uri_skip_ancestor: Assertion `svn_uri_is_canonical(child_uri, ((void *)0))' failed.
You will need to remove the standard yum packages and use a Wandisco install, svn1.7_centos6_wandisco.sh. This installs plain subversion and configures the Wandisco servers as a source of packages. You can then use yum to install subversion-javahl. The following files are installed:
$ repoquery --list subversion-javahl
/usr/lib/libsvnjavahl-1.so
/usr/lib/svn-javahl/svn-javahl.jar
/usr/lib64/libsvnjavahl-1.so
/usr/lib64/svn-javahl/svn-javahl.jarIf you are using a 64bit JVM, use the /usr/lib64 library, otherwise use the 32bit library in /usr/lib.
JavaHL considerations when upgrading Fisheye
If you are currently using SVNKit with Fisheye (the default), then you do not have to do anything when upgrading to Fisheye 3.1 and later. Fisheye will continue to use the bundled SVNKit library.
Fisheye's Admin UI now displays information about the Subversion client in use – click Server, under 'Global Settings'. With no native client, configured, the display would look like:
If you have been using native JavaHL prior to Fisheye 3.1, Fisheye will detect that you have configured a pre-1.7 version of JavaHL and fallback to the bundled SVNKit client and start up normally. You will see the following in the Server section of the admin UI:
You can use the Fisheye admin UI to update the JavaHL client information to point Fisheye to a 1.7 or later JavaHL jar and shared library. Fisheye will perform some checks that the configured library supplies the correct classes. You will need to restart for the changes to take effect. If there are problems with the JavaHL library on restart, Fisheye will again fallback to SVNKit. Once you have updated the configuration, Fisheye will show a message that the configuration has been changed and a restart is required:
Upon restart, the display will show the operation of the native library and its version:
