Lieven Govaerts <email@example.com> wrote on 11/07/2006 04:08:24 AM:
> I've upgraded some Java scripts to support Subversion 1.4.2 (coming from
> While executing the script, I find in the current working directory a
> folder structure:
> Stepping through the Java code, I found that these folders are created
> constructor of org.tigris.subversion.javahl.SVNClient:
> * Standard empty contructor, builds just the native peer.
> public SVNClient()
> cppAddr = ctNative();
> // Ensure that Subversion's config file area and templates
> // Passing an empty string instead of null (which would be
> // more appropriate) prevents earlier versions of the
> // native library (mismatched from the Java bytecode
> // version) from crashing.
> catch (ClientException suppressed)
> // Not an exception-worthy problem, continue on.
> I see two problems with the code:
> 1. These folders are supposed to be created in the users home directory,
> the current working folder.
> 2. Doing some non-trivial initialization in a constructor is against
> practice (in Java).
> Looking at the JavaHL code r20726 (which adds the setConfigDirectory
> most likely the reason of this behavior. If anyone can easily see the
> the problem and solve it that would be nice, otherwise I'll have a go
> this week.
I posted similar problems two weeks ago. See:
We are having a lot of recent problems with Subclipse users that manifest
as the user not being able to permanently accept an SSL certificate or
have their passwords cached. It is starting to come up so often that I
think the problem is broader than I originally wrote.
I do not know why that setConfigDir() call was added, but I am responsible
for changing it from a null to an empty string. It did not seem likely
that could cause any problems as they appeared to have been treated the
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 7 16:03:07 2006