The aforementioned problem happens if you have two copies of libneon -- one in /usr/lib, and the other in /usr/local/lib. This is because SVN's new Makefile in 1.6.2 is written such that GCC will blithely ignore your specified library path and link against whatever is in /usr/lib.

If you run
otool -L /usr/local/lib/libsvn_ra_neon-1.0.dylib, you'll find that the library was linked against /usr/lib/libneon.26.dylib . This is odd, because I'm sure you'd remember that you'd specified:
--with-neon=/usr/local when you ran configure. Unfortunately, if you look in the Makefile:

LDFLAGS = ... -L/usr/lib -L/usr/lib $(EXTRA_LDFLAGS)
... and a bunch of other places where the -L/usr/lib is explicitly specified in front of everything else.

When specifying load order using -L, GCC searches for libraries to link against in the order that they were given. It just so happens that Apple ships an older libneon in /usr/lib. Since /usr/lib is up first, its dynamic library will always win, no matter what you put in --with-neon=. So GCC links against old libneon and goes merrily on its way. Since Apple ships a dynamic library, this particular code path won't run until you access the features of libneon -- that is, network access. And so all is fine until the first time you run svn update.

If you change the leading -L to -L/usr/local/lib (or wherever your newer libneon is), it'll link correctly, and you'll have SVN back without the explosions.

MacPorts actually tries to fix this by disabling the neon version check for some reason. I'm concerned that all that really means is that you get to link against the Apple neon instead, and some features end up being missing, but I can't be sure about that.