On 07.11.2014 14:05, Stuart Rossiter wrote:
> 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:
The org.tigrs namespace in JavaHL has been deprecated for quite a while now.
> 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.)
Because ISVNClient.propertyGet does not return a string, it returns a
byte array (which is more correct, since Subversion property values are
not limited to parseable strings). So there's another bug right there
... and not one that's all that easy to fix.
> 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.
Personally I'd prefer if people used the JavaHL APIs from the org.apache
namespace. They're far better maintained.
-- Brane
Received on 2014-11-07 23:23:22 CET