Lieven Govaerts <svnlgo@mobsol.be> wrote on 11/07/2006 04:08:24 AM:
> I've upgraded some Java scripts to support Subversion 1.4.2 (coming from
1.2.3).
> While executing the script, I find in the current working directory a
new empty
> folder structure:
> auth\
> svn.simple\
> svn.ssl.usr\
> svn.username\
>
> Stepping through the Java code, I found that these folders are created
from the
> 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
exist.
> try
> {
> // 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.
> setConfigDirectory("");
> }
> 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,
not in
> the current working folder.
> 2. Doing some non-trivial initialization in a constructor is against
best
> practice (in Java).
>
> Looking at the JavaHL code r20726 (which adds the setConfigDirectory
call) is
> most likely the reason of this behavior. If anyone can easily see the
cause of
> the problem and solve it that would be nice, otherwise I'll have a go
later
> this week.
I posted similar problems two weeks ago. See:
http://svn.haxx.se/dev/archive-2006-10/0773.shtml
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
same.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Nov 7 16:03:07 2006