404 on SQLite dependency in get-deps.sh

2011-07-22 Thread Conor
Problem:

The URL used by get-deps.sh from subversion-1.6.17.tar.gz to get SQLite,
http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz, is 404.

Proposed Solution:

It looks like sqlite.org has changed (?) their filename format, as the
latest version of the amalgamation file is 3.7.7.1, and the URL is:
http://sqlite.org/sqlite-amalgamation-3070701.zip

Need to change:
 Line 31:   SQLITE_VERSION=3.7.5 to SQLITE_VERSION=3070701
 Line 53:   wget -nc http://www.sqlite.org/$SQLITE.tar.gz to wget -nc
http://www.sqlite.org/$SQLITE.zip
 Line 61:   gzip -dc $TEMPDIR/$SQLITE.tar.gz | tar -xf -   to unzip
$TEMPDIR/$SQLITE.zip
 Line 67:   mv sqlite-$SQLITE_VERSION sqlite-amalgamation to mv
$SQLITE.zip sqlite-amalgamation


-Conor


Re: 404 on SQLite dependency in get-deps.sh

2011-07-22 Thread Conor
Looks like the same issue, thanks for the response.

I tried to search for this at
http://subversion.apache.org/issue-tracker.html, but came up empty.

-Conorr

On Fri, Jul 22, 2011 at 2:10 PM, Daniel Shahaf wrote:

> The following changes will be included in the next release:
>
>  * r1134734
>   Fix sqlite-amalgamation location and archive format.
>   Branch:
> 1.6.x-r1134734
>   Justification:
> Users report get-deps.sh of sqlite is currently broken.
>   Notes:
> r1134734 also bumped dependency versions; the backport branch excludes
> those bumps.
>   Votes:
> +1: danielsh, arfrever, julianfoad
>
> Without looking into the details, I guess you're reporting the same
> issue?
>
> Conor wrote on Fri, Jul 22, 2011 at 11:37:25 -0400:
> > Problem:
> >
> > The URL used by get-deps.sh from subversion-1.6.17.tar.gz to get SQLite,
> > http://www.sqlite.org/sqlite-amalgamation-3.7.5.tar.gz, is 404.
> >
> > Proposed Solution:
> >
> > It looks like sqlite.org has changed (?) their filename format, as the
> > latest version of the amalgamation file is 3.7.7.1, and the URL is:
> > http://sqlite.org/sqlite-amalgamation-3070701.zip
> >
> > Need to change:
> >  Line 31:   SQLITE_VERSION=3.7.5 to SQLITE_VERSION=3070701
> >  Line 53:   wget -nc http://www.sqlite.org/$SQLITE.tar.gz to wget
> -nc
> > http://www.sqlite.org/$SQLITE.zip
> >  Line 61:   gzip -dc $TEMPDIR/$SQLITE.tar.gz | tar -xf -   to unzip
> > $TEMPDIR/$SQLITE.zip
> >  Line 67:   mv sqlite-$SQLITE_VERSION sqlite-amalgamation to mv
> > $SQLITE.zip sqlite-amalgamation
> >
> >
> > -Conor
>


JavaHL propertyGet handling in org.tigris.subversion package

2012-11-19 Thread Conor MacNeill
Hi,

I've been having a problem with the 1.7 JavaHL implementation in the
org.tigris.subversion package. As I understand the code, this has been
written as a wrapper around the new org.apache.subversion package. The
propertyGet method is calling new String() around the byte[] value returned
from the new interface's equivalent method. The problem is that when this
returns null, the old interface method throws a NullPointerException rather
than returning null.

This is somewhat related to the discussion in

http://subversion.tigris.org/issues/show_bug.cgi?id=3770

although it's of a slightly different character.

I suggest the following change:

Index: SVNClient.java
===
--- SVNClient.java(revision 1411518)
+++ SVNClient.java(working copy)
@@ -2110,10 +2110,10 @@
 {
 try
 {
-return new PropertyData(path, name,
-new String(aSVNClient.propertyGet(path, name,
-revision == null ? null : revision.toApache(),
-pegRevision == null ? null :
pegRevision.toApache(;
+byte[] propertyBytes = aSVNClient.propertyGet(path, name,
+revision == null ? null : revision.toApache(),
+pegRevision == null ? null : pegRevision.toApache());
+return propertyBytes == null ? null : new PropertyData(path,
name, new String(propertyBytes));
 }
 catch (org.apache.subversion.javahl.ClientException ex)
 {

What do you think?

Cheers
Conor