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

Re: JavaHL problem with 1.4

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-08-30 20:50:27 CEST

rooneg@gmail.com wrote on 08/30/2006 02:42:19 PM:

> On 8/30/06, Mark Phippard <markp@softlanding.com> wrote:
> > I have attached a patch that resolves the problem with using the 1.3
> > libraries, and looking at the code that was added in the referenced
> > commit, I believe it maintains the enhancement that was made in that
> > commit for 1.4.
> >
> > OK for me to commit and propose for backport? I can easily ship a
> > svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
> > release.
> No objection to the change, it seems trivial enough, I'm just
> wondering if it's really something we /have/ to worry about though.
> Why would the new jar file ever be expected to work with the old
> native lib? It's not like you can use a new libsvn_client with an old
> libsvn_wc...

I tried to explain that in my original message. Subclipse includes the
JAR file with our product, and I think this would be fairly common for
anyone using it. But you cannot really provide the native libraries for
platforms other than Windows. So in Subclipse I want to include the 1.4
JAR and the Windows 1.4 native libraries. But a Linux user cannot easily
get the 1.4 libraries unless they want to build from source. Only a very
small percentage of our users is willing to do this.

I realize this is not something we can count on. For example, 1.3 would
crash with 1.2 libraries because 1.3 was changed to call a new initialize
routine in the library. I do think we should strive to make the library
load without crashing. In 1.4, we added new methods that let you get the
version of the library. It would be nice if say in 1.5 I could call this
method, find out the user has 1.4 libraries, and gracefully give an error
that they need to update. The current situation of crashing the JVM is
pretty bad as it gives us zero ability to help the user and be friendly.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 30 21:48:22 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.