scott.haug@gmail.com wrote on 08/31/2006 04:08:03 PM:
> I don't have a problem with the javahl APIs. If they're available, by
all
> means. It wasn't an issue of jar size or confusion as to the need (or
lack
> thereof) of the native APIs. I just found the javahl dependency on a
javasvn
> implementation unexpected.
>
> svnClientAdapter, as I understand it, supports 3 clients explicitly:
command
> line, javahl, and javasvn. I had assumed that enabling one of those
clients
> would mean that the dependencies of the other clients wouldn't be
required.
> I mean, if javasvn is going to use javahl anyway, why bother with an
> explicit 'javasvn' client type? Just include the javasvn-javahl.jar file
and
> let the classloader sort it out.
Because JavaHL is really two things:
1) A set of interfaces that define a high-level API for Subversion
2) An implementation that uses JNI to call the native Subversion
libraries
JavaSVN provides an alternative to #2 written in pure Java. It makes
sense for us to use that simply because they are providing and maintaining
it. It does not make sense for us to do our own version.
> Anyway, it's not that big a deal. I totally understand why you're not
> interested. I would like to know what explicit javasvn client support
> provides on top of the standard javahl functionality? Are there features
> javasvn has that aren't adequately exposed through javahl, or are there
> limitations in javasvn vs the native version that need to be
accomodated?
JavaSVN includes things that native Subversion does not currently. It
kind of does not matter though. svnClientAdapter is ultimately based on
what can be done with JavaHL and mostly just mirrors that API and
interface. There are some places where we have added options to use a
custom feature of JavaSVN but there are not a lot of areas that lend
themselves to that.
> Would it be possible to discover automatically that javasvn was being
used
> as the javahl implementation and have the factory adjust according to
which
> implementation it provided?
I'd say that we already do, do this.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Thu Aug 31 22:29:56 2006