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

Re: Possible Problem with JavaHL in 1.3.0 RC2

From: Mark Phippard <markp_at_softlanding.com>
Date: 2005-11-04 02:38:27 CET

> If you have to go as far as implementing your own isAdminDirectoryName
> then that would suggest threading is totally broken, and that it's not
> just an initialisation problem. Given that you now have a thread-safe
> call to JNIInit (the first getAdminDirectoryName call) does your code
> work if you continue to make that call but stop using your own
> isAdminDirectoryName?
>
> If that works the next step is to replace the first, thread-safe, call
> to getAdminDirectoryName with some other function that calls JNIInit,
> say 'singleStatus("fake", false)'. If that works it indicates that
> the problem is not the SVN_ASP_DOT_NET_HACK code itself, but that it's
> an initialisation problem that happens to be triggered by the way you
> are using the SVN_ASP_DOT_NET_HACK code.

I was going to make that change but then remembered I have likely already
done this in testing. For example, I have done tests were I did stuff that
would have run "ls" and "st -u -v" where they all work. Then as soon as I
do a checkout/update/commit it crashes. In some cases, I even did
checkouts from multiple repositories successfully before it would crash.

I would be happy to try to do more to help shake out the problem, but
assuming this works, I am happy with the workaround. I was most likely
never going to call isAdminDirectory anyway because JNI calls are way too
expensive and we would be calling this a lot. So I have to cache the
directory and check myself. This is my Java code which seems simple
enough:

    public boolean isAdminDirectory(String name) {
      if (".svn".equals(name) || getAdminDirectoryName().equals(name))
            return true;
      else
            return false;
     }

The only reason to call the library method would be if svn someday allowed
other directory names beyond the two it does today. However, Subclipse is
always going to be tightly tied to the latest Subversion library since
JavaHL does not handle compatability issues. Keeping in synch with what
you are doing in this area is likely to be the least of our problems.

Thanks

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 4 02:39:21 2005

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