SVNAdaptor from Tigris

[Rod Widdowson]

I spent today looking at this.

As far as I could see the safest way to get hold of this is to build it from
source in SVN.  The only distributables shipped on the
http://subclipse.tigris.org/ site are those which you would plug into
eclipse and it was not obvious what the correspondence between those jars
and what we need were - and in particular there were several jars in there
that we know we do not want to distribute.

Building was relatively easy once I remembered how to make ant work, but I
couldn't get the tests to pass and gave up on that.

Armed with the resultant jar I could do some poking around.

The good news is that it seems to be a pretty good match for the Spring
Resource abstraction and I coded up a prototype very quickly.  

Also on the good news side - and this seems like it might be very good news
- is that on its own it comes with an implementation which appears to fork
out to the command line "svn" and so all that you need to do is to make sure
that it appears on the path of the executable running the code.  I am not
sure what this means for Unix daemons and windows services, but it is very
encouraging.

The less good, but by no means show-stopping news concerns the integration
with svnKit.  It appears that SVNAdaptor really only speaks command line and
JavaHL (the native implementation).  But svnKit comes with a shim which
allows a JavaHL API to be presented.  This in turns requires a whole series
of extra jar files, all of which come with their own license restrictions.
However these are all bundles up with the distribution on the
http://www.svnkit.com/download.php download page.  AIUI, since we are not
shipping these jars, but just documenting how to download, this is not an
issue for us.

The SVNAdaptor code has, at least in theory, a way of automatically
selection the "best" implementation (JavaHL > svnKit > CommandLine), but I
could not get that to work, so we will need to investigate other mechanisms
to config either the command line (if we want to make that available) or
native java versions.

I did not get into complex setups such as svn+ssh: URLs, I did all my
testing against https://svn.shibboleth.net/.  The (poor) documentation seems
to indicate that you end up needing even more jar files, although some of
the jars in the svnKit download appears to indicate support for agentproxy
(which I guess is pageant in windows speak).

My recommendation is that:

1) I properly build a copy of the jar and make it available to someone to
upload to maven (I am very happy not having admin privs on maven right
now...)
2) We also add the svnkit shipped jars to maven (to be included in our poms
only with <scope>test</scope>
3) I complete and tidy up (for instance integrate with logging) my
SVNResource implementation and tests.  As I mentioned yesterday, I do want
to test this with property replacement, and I'd also like to understand what
the spring configuration looks like.

I can then look at ResourceLoaders and also what we want to do about V2.
For the latter, right now my instinct is that making something work would
not be hard (although it would be completely new code so as to fit in with
the V2 configuration), but that we may find that some of the richness
available via the V2 configuration will not be available.

All input welcome.

Rod