[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: Daniel Rall <dlr_at_collab.net>
Date: 2006-09-11 20:24:36 CEST

On Wed, 30 Aug 2006, David James wrote:

> On 8/30/06, Mark Phippard <markp@softlanding.com> wrote:
> >Mark Phippard <markp@softlanding.com> wrote on 08/30/2006 11:53:18 AM:
> >
> >> Sorry to be bringing this up late in the cycle. The JavaHL changes
> >> between 1.3 and 1.4 are fairly minor and I was not anticipating any
> >> problems.
> >>
> >> The problem I am running into is that I cannot use the JavaHL JAR file
> >> produced with 1.4, with the Subversion 1.3 libraries.

When using mismatched libraries (e.g. 1.4.x JAR files with < 1.4.0
native libraries), this problem should occur only when instantiating a
SVNClient (or SVNClientSynchronized) instance. Due to the problem's
occurrence in native code, I don't believe that it can be worked
around without making modifications to the Java source (exactly as
Mark's patch does).

> >> I think that this is something we should try to support.

Past a certain point (e.g. allow the library to load enough to spit
out a "version mismatch" error or something), I don't agree. Trying
to support mismatched library versions which were never intended to
work with each other is an uphill battle that is going to lead to a
matrix of unanticipated problems, and is definitely more trouble than
it's worth.

Rather than continue down this route, in the future I would prefer to
detect mismatched library versions, and output some type of warning
(at least). It would certainly be safer and simpler to do this
straight-away, but alternately, we could hold off until we know of a
show-stopper incompatibility.

> >> We include the Java JAR file with Subclipse, but we rely on the user to
> >> get the native libraries using whatever OS-specific distribution
> >> mechanism
> >> is appropriate. During the release candidate phase the only way to get
> >> these is to build from source, and even after GA it will not be easy to
> >> get the 1.4 libraries on a lot of platforms for quite a while.
> >>
> >> This creates an impossible chick and egg problem for us with Subclipse.
> >We
> >> want to take advantage of 1.4, but if we start including the JAR file,
> >> someone just trying to start Eclipse when they have the Subversion 1.3
> >> libraries installed will just have their JVM crash.
> >>
> >> I have debugged and the problem was caused by r20652. Here is the log
> >> message:
> >>
> >> JavaHL: Improve handling of the Subversion client's configuration
> >> directory during native library initialization, and API manipulation.
> >>
> >> Depends on r20648's bug fix to svn_config_ensure().
> >
> >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.

Yup, it does.

> >OK for me to commit and propose for backport? I can easily ship a custom
> >svnjavahl.jar with Subclipse if this does not get in until a 1.4.1
> >release.
> Hi Mark,
> The patch looks good. +0 to commit and backport to 1.4.x.

I've backported this change to 1.4.x, so it will show up in 1.4.1.

  • application/pgp-signature attachment: stored
Received on Mon Sep 11 20:57:14 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.