For example to pull the latest WordPress.

$ svn co http://core.svn.wordpress.org/trunk/
svn: OPTIONS of 'http://core.svn.wordpress.org/trunk': could not connect to server (http://core.svn.wordpress.org)

Definitely not a network issue as every single Subversion repository over HTTP is returning the same problem. A bit of gooling seems to suggest that neon is to blame (neon is the HTTP/WebDAV client library used by Subversion). Doing strace shows that:

...
close(4)                                = 0
socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid argument)
write(2, "svn: OPTIONS of 'http://core.svn."..., 115svn: OPTIONS of 'http://core.svn.wordpress.org/trunk': could not connect to server (http://core.svn.wordpress.org)
) = 115
exit_group(1)                           = ?

Well. According to /usr/include/bits/socket.h, 0×80000 is SOCK_CLOEXEC (Atomically set close-on-exec flag for the new descriptor(s).), which is not supported on Linux kernel older than 2.6.27. Here comes the problem of para-virtualisation and operating system jails — you are still running the virtualised kernel supplied by your vendor. Almost all of my VPS — Xen or OpenVZ — runs on Linux kernel 2.6.18 as it’s the kernel of choice for RHEL 5 where many virtualisation vendors want to support.

D’oh.

Well. Instead of rebuilding subversion with an older neon library, here is a much simpler work-around posted on Debian’s mailing list.

$ echo 'http-library=self' >> ~/.subversion/servers

Done! Subversion should now be working on the older kernels.