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

Pretty definite bug in 1.7.0 and beyond for JavaHL SVNClient propertyGet (legacy tigris package)

From: Stuart Rossiter <stuart.p.rossiter_at_gmail.com>
Date: Fri, 7 Nov 2014 13:05:20 +0000


 [Not subscribed; please cc me.]

Posting directly here (rather than users) since I'm pretty sure of this.

org.tigris.subversion.javahl.SVNClient has a bug: propertyGet wraps a call
to the same method for the Apache package equivalent, but doesn't handle
nulls in the response, so the caller can never receive a null response
(which it should do if the property doesn't exist).

public PropertyData propertyGet(String path, String name,
                                    Revision revision, Revision pegRevision)
            throws ClientException
            return new PropertyData(path, name,
                    new String(aSVNClient.propertyGet(path, name,
                        revision == null ? null : revision.toApache(),
                        pegRevision == null ? null :
        catch (org.apache.subversion.javahl.ClientException ex)
            throw new ClientException(ex);

The String constructor throw a NullPointerException if the aSVNClient class
returns null. (Not sure why the String constructor was used to copy an
immutable string anyway, unless there are JNI-specific reasons.)

This bug has persisted since 1.7.0 (when the 'real' code switched to the
Apache package, with the Tigris one as a legacy wrapper); I checked and
it's still there in the current HEAD (r1600990).

To reproduce, just try to retrieve a non-existent property from an
SVN-controlled file using the legacy Tigris package API.

If you need me to raise an issue from this let me know.



Stuart Rossiter
Research Fellow: EPSRC Care Life Cycle Project
Received on 2014-11-07 23:04:07 CET

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