Do you have svn-devel installed?

Not that I know of, no.

Well install subversion-devel again via yum and give it a go.

If that fixes it let me know and I'll look into adjusting the 
configure script.

Still no luck.
A question though. The script could not find my apr-1-config and I had to specify it (its in /usr/local/apr/bin). What about svn? Even if I specify the 2 locations I have the bins (one of each version: 1.4.4 in /usr/bin and 1.5.0 in /usr/local/bin) it stops at the same error. Is this a legitimate error about identifying the version or is it more of a catch all error? I might have a "1.6.0 dev build" lurking somewhere in my server I had installed in April and was wondering if it that is what is causing it.

Can you try the config.m4 from cvs, there is a better version check performed within it.

http://cvs.php.net/viewvc.cgi/pecl/svn/config.m4?view=log

Still the same error. I checked the config log and there are 96 undefined references for neon:

...
configure:4120: gcc -o conftest -g -O2  -Wl,-rpath,/usr/local/lib -L/usr/local/lib  conftest.c -lsvn_client-1   >&5
/usr/local/lib/libsvn_ra_neon-1.so.0: undefined reference to `X509_NAME_entry_count'
...
/usr/local/lib/libsvn_ra_neon-1.so.0: undefined reference to `X509_STORE_add_cert'
/usr/local/lib/libsvn_ra_neon-1.so.0: undefined reference to `SSLeay'
/usr/local/lib/libsvn_ra_neon-1.so.0: undefined reference to `SSL_get_peer_cert_chain'
collect2: ld returned 1 exit status
configure:4126: $? = 1
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| /* end confdefs.h.  */
| 
| /* Override any GCC internal prototype to avoid an error.
|    Use char because int might match the return type of a GCC
|    builtin and then its argument prototype would still apply.  */
| #ifdef __cplusplus
| extern "C"
| #endif
| char svn_client_move3 ();
| int
| main ()
| {
| return svn_client_move3 ();
|   ;
|   return 0;
| }
configure:4144: result: no
configure:4167: error: failed to determine svn version or less than 1.3
...

Might neon be the cause?

It looks related to SSL.

Can you use ldd to check to see if libsvn_ra_neon-1.so is linked against an ssl library.

I checked on my 1.4 and I see that libsvn_ra_dav-1.so was linked against libssl.

[root@demoserv ~]# ldd /usr/lib/libsvn_ra_neon-1.so
        linux-gate.so.1 =>  (0x00110000)
        libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x0014c000)
        libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x00156000)
        libaprutil-1.so.0 => /usr/local/apr/lib/libaprutil-1.so.0 (0x0019a000)
        libexpat.so.1 => /lib/libexpat.so.1 (0x001b6000)
        libapr-1.so.0 => /usr/local/apr/lib/libapr-1.so.0 (0x001d7000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x001fc000)
        librt.so.1 => /lib/librt.so.1 (0x00200000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00250000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00209000)
        libdl.so.2 => /lib/libdl.so.2 (0x00222000)
        libc.so.6 => /lib/libc.so.6 (0x00282000)
        /lib/ld-linux.so.2 (0x00233000)
[root@demoserv ~]# ldd /usr/local/lib/libsvn_ra_neon-1.so
        linux-gate.so.1 =>  (0x00110000)
        libsvn_delta-1.so.0 => /usr/local/lib/libsvn_delta-1.so.0 (0x0014c000)
        libsvn_subr-1.so.0 => /usr/local/lib/libsvn_subr-1.so.0 (0x00156000)
        libaprutil-1.so.0 => /usr/local/apr/lib/libaprutil-1.so.0 (0x0019a000)
        libexpat.so.1 => /lib/libexpat.so.1 (0x001b6000)
        libapr-1.so.0 => /usr/local/apr/lib/libapr-1.so.0 (0x001d7000)
        libuuid.so.1 => /lib/libuuid.so.1 (0x001fc000)
        librt.so.1 => /lib/librt.so.1 (0x00200000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x00250000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00209000)
        libdl.so.2 => /lib/libdl.so.2 (0x00222000)
        libc.so.6 => /lib/libc.so.6 (0x00282000)
        /lib/ld-linux.so.2 (0x00233000)

Strange, I had compiled with the openssl option. I'll try to recompile neon to double check.

I had to clean before rebuilding the package with the new version check and it worked this time. The first time I tried the new config.m4 I probably didn't clean.