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

All,

 [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
    {
        try
        {
            return new PropertyData(path, name,
                    new String(aSVNClient.propertyGet(path, name,
                        revision == null ? null : revision.toApache(),
                        pegRevision == null ? null :
pegRevision.toApache())));
        }
        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.

Thanks,

Stuart

-- 
________________________________
Stuart Rossiter
stuart.p.rossiter_at_gmail.com
Research Fellow: EPSRC Care Life Cycle Project
http://www.southampton.ac.uk/clc