Re: [Subclipse-users] Could SVNKit be the default SVN implementation instead of JavaHL?

Apologies for what I now see as multiple duplicates sent to the list
-- I assumed they were rejected as they didn't appear until AFTER I
regsitered and submitted via the website rather than a direct email.

Comments inline below.

On Tue, Jun 11, 2013 at 10:24 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Mon, Jun 10, 2013 at 3:18 PM, Nick Boldt <nboldt_at_redhat.com> wrote:
>> So I have two suggestions which could improve the user experience:
>> a) default to SVNKit when JavaHL is unavailable, or
> We already do this. However, if JavaHL is the chosen default we do
> not so it silently. We will first give you notification that the
> library is not available. This is intentional. We want you to use
> JavaHL and if it is installed and the chosen default, then we are
> going to notify you that it is not setup.

When I install the features here [1] into Eclipse or JBDS, Subclipse
and SVNKit are installed, but SVNKit isNOT selected as the default -
rather, even though it's unavailable, JavaHL is set as the default SVN
implementation, and the warning message re: JavaHL is thrown.

[1] http://download.jboss.org/jbosstools/updates/requirements/subclipse/1.8.20_1.7.9.1/features/

So, yes, JavaHL is selected as default but as you say, it's not done
silently. My point is that OOTB, that means a user can't simply use
Subclipse w/o having to then go install something else.

I suppose a better approach then would be to tell a user that...

i) JavaHL, while harder to install as it's platform-centric, is the
PREFERRED (and SUPPORTED) way to work with SVN, BUT
ii) since it's not already available in the user's installation,
you've defaulted them to use SVNKit instead (which they HAVE
installed), AND
iii) to switch to JavaHL, they can go to Preferences > Team > SVN >
SVN Interface after first installing JavaHL

> 1) If you do not want to support JavaHL by providing the libraries it
> requires, then why do you provide the plugin? You could just provide
> the SVNKit adapter and library and users will never see this message.
> If only SVNKit adapter is installed, it will be the default.

We're trying to make it simpler to install SVN tooling into Eclipse
(aside: we used to include Subversive but it was determined that
Subclipse is just better), so with a few clicks and no reading of
install guides, you can connect to an SVN server to browse code,
checkout projects, and commit changes back. Relying on JavaHL, which
is arguably a better implementation that SVNKit, simply makes the
setup process more convoluted.

I suppose the ideal setup would be to be able to install JavaHL
directly from within a Subclipse plugin (eg., a wizard linked from the
warning dialog), with platform detection and license agreement
confirmation, but I realize that's a lot more work. It would of course
improve the ease of use and it easier for users to adopt JavaHL
instead of SVNKit.

> 2) The change you made to set the preference ought to work, however,
> you should remove that preference you set about the JavaHL commit
> hack. It will no impact on this and it is just turning off a feature
> that almost all users would want.

I'll remove that then. Wasn't entirely sure what it does but as it
referred to JavaHL and our usecase is "Subclipse for all platforms",
figured it wouldn't be needed.

Thanks for the reply, and apologies again for polluting your forum
with dupe posts.

Nick

-- 
Nick Boldt :: Productization Lead :: JBoss Tools & Dev Studio :: Red Hat, Inc.
http://nick.divbyzero.com
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3057659
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].