[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] Pure JavaSVN adapter for svnClientAdapter

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-09-01 01:35:41 CEST

scott.haug@gmail.com wrote on 08/31/2006 05:54:00 PM:

> I understand the difference, and what javasvn provides. I'm not
> (anymore!) you write your own version. I guess I'm asking if the
> JhlClientAdapter works with the javasvn implementation of the javahl
> or does it only support the native implementation? If JhlClientAdapter
> with javasvn as the SVNClient implementation, why have an explicit
> JavaSvnClientAdapter?

No, it doesn't. Which is not to say that it would have been impossible to
have made one that could do both. If you compare the two classes, the
differences are fairly obvious. The point of creating the Abstract class
was to keep the common parts in one place. That is what makes sense to

> Maybe I'm missing something in the svnclientadapter API, then. As I
> understand it, there's a JavaSvnClientAdapter, a JhlClientAdapter, and a

> separate factory for each. The adapters both extend the same base class,
> one is not a subclass of the other. So, clearly, there is some
> in the functionality they provide, even though the vast bulk of their
> implementation is provided by the AbstractJhlClientAdapter base class.
> question, then, is would it make sense to have a single factory that
> detect whether javasvn or the native impl is in use, and return the
> appropriate adapter? Is this functionality already in place somewhere
> I'm missing it, or is there a reason I'm not understanding for
> enabling these two clients separately?

I fail to see the benefit of that approach. How could explicitly pick the
implementation you wanted if they were both available? The current
approach seems like the proper OO-way to do this. As an example,
Subclipse operates under the assumption that all of the adapters might be
available and you can pick the one you want. If you have chosen a
default, we try to load it and have some fallback options if it fails. But
if it doesn't fail, startup is faster since only one adapter is
initialized. If you do not have a default chosen we try to load JavaHL,
if it is not available we try to load JavaSVN etc..

In our Eclipse proposal, we have changed this to be done with Eclipse
extension points. So the extension point will tell us which adapters are


To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Fri Sep 1 01:35:48 2006

This is an archived mail posted to the Subclipse Dev mailing list.