Brane,
Comments below.
On 7 November 2014 22:20, Branko Čibej <br...@wandisco.com> wrote:
> 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.
>
Yeah I know, but I was using it to retain SVN 1.6 client compatibility
since, for example, this is still the default even in fairly recent distros
like Ubuntu 12.04LTS (and I didn't want my users to have to play around
with backports, etc.)
>
> > 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.
>
Ah, sorry, wasn't paying attention and missed the byte[] returns...
>
> > 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.
>
So is that a "won't fix since package is deprecated"? Do you want me to
raise a bug report in any case for tracking purposes (or in case you might
flag it as a very low priority fix)?
>
> -- Brane
>
>
--
________________________________
Stuart Rossiter
stuart.p.rossi...@gmail.com
Research Fellow: EPSRC Care Life Cycle Project
http://www.southampton.ac.uk/clc
