Improvement #1918
Replace SVNClientAdapter based implementation
Start date:
29.08.2015
Due date:
% Done:
100%
Estimated time:
origin:
Description
The approach to use the subversion client adapter API ultimately failed due to
- Unnecessary complexity in class path arithmetics and side-constraints like requiring svn client adapter jar and javahl jar in the same class loader as both would independently look for the same native libs.</li>
- A major-minor version matching requirement of the client adapter API with the javaHL API. This pretty much renders the use of svn client adapter as a commercially usable SVN API effectively useless as java hl and svn client adapter API would be subject to independent application life cycles.
Instead, we will implement the SVN client abstraction, that is used by the SVN CR and came into existence as a side-product, twice, once for the case SVNKit is found on the classpath and once for the case that only JavaHL is found.
Related issues