On Tue, 7 Nov 2006, Lieven Govaerts wrote:
> 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\
I can reproduce these symptoms with the following code:
public class test
{
public static void main(String[] args)
{
SVNClientInterface client = new SVNClient();
}
}
...compiled and run like so:
javac -cp $HOME:/usr/local/subversion/lib/svn-javahl/svn-javahl.jar test.java
java -Djava.library.path=/usr/local/subversion/lib -cp $HOME:/usr/local/subversion/lib/svn-javahl/svn-javahl.jar test
> Stepping through the Java code, I found that these folders are
> created from the constructor of
> org.tigris.subversion.javahl.SVNClient:
...
> public SVNClient()
> {
...
> // 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.
Yup.
> 2. Doing some non-trivial initialization in a constructor is against
> best practice (in Java).
Performing this initialization in the constructor is an improvement
over performing the initialization in JavaHL's native library
(e.g. libsvnjavahl-1.so), as it allows SVNClient sub-classes to
determine where the config directory should be (rather than always
attemting to create it in the user's home directory, which is not
always possible). Having the native code always create the config
directory in the same place is rather at odds with the purpose of a
setConfigDirectory() API, and causes serious problems in some
deployment scenarios.
I'm totally open to other options, so long as they don't regress this
functionality.
> 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.
r20726 was a merge of r20652 from trunk into the 1.4.x branch. r20652
moved a call to svn_config_ensure() from JavaHL's native library --
where it always ran, a behavior which could not be overridden -- into
the SVNClient class's constructor. And so it was Good.
r21316 altered the way SVNClient's constructor made that call to
attempt to allow newer versions of JavaHL's Java libraries to
inter-operate with older versions of Subversion's own core libraries
(a dependency probably created by r20648). In doing so, it introduced
this (mis-)behavior.
Reverting r21316 -- and first r21429, a follow-up -- fixes this
problem, but removes the possibility of inter-op between 1.4.x Java
code and <= 1.3.x Subversion libraries. Unless someone has a better
suggestion, I think we should go ahead make this change on trunk, and
backport it to the 1.4.x line, as it's definitely the lesser of two
evils.
On Fri, 27 Oct 2006, Mark Phippard wrote:
> These could be expected behavior, or they could be JavaHL bugs.
> This is tested on Windows with 1.4.0
>
> 1) JavaHL has a method named setConfigDirectory(String name) that
> allows you to override the location of the directory containing the
> runtime configuration information. From my testing on Windows, it
> appears that this feature works for settings in the config file,
> such as auto props. However, things like the SSL and password cache
> appear to still store in the default location. I would have
> expected all of the configuration area info to be pointed to the new
> location, but it is entirely possible that the feature is only
> intended to let you override the config file.
>
> Does anyone know if this should also work for the cache?
Mike Pilato replied:
> setConfigDirectory() was, I thought, supposed to be the equivalent
> of running --config-dir on the commandline.
>
> So I would expect that, as the auth cache is but one component of
> the .subversion runtime configuration directory, the cache employed
> would follow the recommendation of --config-dir or
> setConfigDirectory().
Mark, I agree with Mike -- SVNClientInterface.setConfigDirectory()
should be dictating the home for the auth cache directory as well as
the config files.
Mark also wrote:
> 2) If the Subversion config area does not exist, then it is created
> automatically when the JavaHL library is loaded. However, if the
> folder does exist, or has incomplete contents, then no attempt is
> made to fill the folder with the correct contents. The way this
> manifests is that when the user is prompted to accept SSL
> credentials, the Accept Permanent does not work because the
> auth/svn.ssl.server folder does not exist. I did not test if
> password cache has same problem, but I'd expect that it would.
>
> I tested scenario #2 with the command line, and it created the
> necessary folders to store the cache info. JavaHL does not.
Mark, is this caused by the bug injected by r21316? Or is this a
different problem?
- application/pgp-signature attachment: stored
Received on Wed Dec 20 00:27:49 2006