serf is a library for HTTP and WebDAV which is an alternative to
Neon for accessing Subversion repositories over http:// and
https:// URLs. serf is designed as an asynchronous library
which can take advantage of HTTP pipelining, so ra_serf may be
more efficient than the Neon-based ra_dav. The serf library can
be found at:
In order to use ra_serf instead of ra_dav, you must install
ra_serf, and run Subversion's ./configure with the arguments
--with-serf and --without-neon. (The latter isn't required if
you don't actually have Neon.) If serf is installed in a
non-standard place, you should use
--with-serf=/path/to/serf/install
instead.
For more information on serf and Subversion's ra_serf, see the
file subversion/libsvn_ra_serf/README.
12. Libraries for our libraries
Some of the libraries that Subversion depends on themselves have
optional dependencies that can add features to what Subversion
can do. Here are some examples.
The Neon library has support for SSL encryption by relying on the
OpenSSL library. When Neon is created with this dependency, then
the Subversion client inherits the ability to support SSL
connections. Neon also has support for sending compressed data
using the zlib library which a Subversion client can take
advantage of.
On Unix systems, if you are building neon as part of the Subversion
build process (as described in section I.4 above), you can pass flags
to Subversion's "./configure", and they will be passed on to neon's
"./configure". You need OpenSSL installed on your system, and you
must add "--with-ssl" as a "./configure" parameter. If your OpenSSL
installation is hard for Neon to find, you may need to use
"--with-libs=/path/to/lib" in addition. In particular, on Red Hat
(but not Fedora Core) it is necessary to specify
"--with-libs=/usr/kerberos" for OpenSSL to be found. The zlib library
is included in the Subversion dependencies package, but if you are compiling
Neon from a different source you can also specify a path to the
library using "--with-libs". Consult the Neon documentation for more
information on how to use these parameters and versions of libraries
you need.
Under Windows, you can specify the paths to these libraries by
passing the options --with-zlib and --with-openssl to gen-make.py.
You can also add support for these features to an Apache httpd server
to be used for Subversion using the same support libraries. The
Subversion build system will not provide them, however. You add them
by specifying parameters to the "./configure" script of the Apache
Server instead.
For getting SSL on your server, you would add the "--enable-ssl"
or "--with-ssl=/path/to/lib" option to Apache's "./configure"
script. Apache enables zlib support by default, but you can
specify a nonstandard location for the library with the
"--with-z=/path/to/dir" option. Consult the Apache documentation
for more details, and for other modules you may wish to install
to enhance your Subversion server.
If you don't already have it, you can get a copy of OpenSSL,
including instructions for building and packaging on both Unix
systems and Windows, at:
The Windows build scripts will compile the ZLib sources.
13. Documentation
The primary documentation for Subversion is the free book
"Version Control with Subversion", a.k.a. "The Subversion Book",
obtainable from http://svnbook.red-bean.com/.
Various additional documentation exists in the doc/ subdirectory of
the Subversion source. See the file doc/README for more information.
II. INSTALLATION
============
A. Building from a Tarball or RPM
------------------------------
1. Building from a Tarball
Download the most recent distribution tarball from:
Unpack it, and use the standard GNU procedure to compile:
$ ./configure
$ make
# make install
You can also run the full test suite by running 'make check'.
2. Building from an RPM
If you are using Linux (or any OS that can use RPM) then another
possibility is to download the binary RPM from the http://summersoft.fay.ar.us/pub/subversion directory.
Currently only Linux on the i386 platform is supported
using this method. You might also require additional RPMS
(which can be found in the above mentioned directory) to use the
subversion RPM depending on what packages you already have installed:
subversion*.i386.rpm
apache*.i386.rpm (Version 2.0.49 or greater)
db*.i386.rpm (Version 4.0.14 or greater; version 4.3.27 or
4.2.52 is preferred however)
expat (Comes with RedHat)
neon (Version 0.25.5)
After downloading, install it (as root user):
# rpm -ivh subversion*.386.rpm (add other packages as necessary)
Note: For an easy way to generate a new version of the RPM
source and binary package from the latest source code you
just checked out, see the packages/rpm/README file for a
one-line build procedure.
B. Building the Latest Source under Unix
-------------------------------------
These instructions assume you have already installed Subversion
and checked out a working copy of Subversion's own code --
either the latest /trunk code, or some branch or tag. You also
need to have already installed whatever prerequisites that
version of Subversion requires (if you haven't, the ./configure
step should complain).
You can discard the directory created by the tarball; you're
about to build the latest, greatest Subversion client. This is
the procedure Subversion developers use.
First off, if you have any Subversion libraries lying around
from previous 'make installs', clean them up first!
This script will make sure you have all the necessary components
available to build Subversion. If any are missing, you will be
told where to get them from. (See the 'Build Requirements' in
section I.)
Note: if the command "autoconf" on your machine does not run
autoconf 2.50 or later, but you do have a new enough autoconf
available, then you can specify the correct one with the
AUTOCONF variable. (The AUTOHEADER variable is similar.) This
may be required on Debian GNU/Linux, where "autoconf" is
actually a Perl script that attempts to guess which version is
required -- because of the interaction between Subversion's and
APR's configuration systems, the Perl script may get it wrong.
So for example, you might need to do:
$ AUTOCONF=autoconf2.50 sh ./autogen.sh
Once you've prepared the working copy by running autogen.sh,
just follow the usual configuration and build procedure:
$ ./configure
$ make
# make install
(Optionally, you might want to pass --enable-maintainer-mode to
the ./configure script. This enables debugging symbols in your
binaries (among other things) and most Subversion developers use it.)
Since the resulting binary depends on shared libraries, the
destination library directory must be identified in your
operating system's library search path. That is in either
/etc/ld.so.conf or $LD_LIBRARY_PATH for Linux systems and in
/etc/rc.conf for FreeBSD, followed by a run of the 'ldconfig'
program. Check your system documentation for details. By
identifying the destination directory, Subversion will be able
to dynamically load repository access plugins. If you try to do
a checkout and see an error like:
It probably means that the dynamic loader/linker can't find all
of the libsvn_* libraries.
Note that if you commonly build with the -jN option to make and
have unpacked a dependency tarball into your checkout, the make
step above may fail, because we don't ensure that third party
libraries in our source tree will finish building before
subversion itself. If you want to use -jN, use the following
instead:
$ ./configure
$ make -jN external-all
$ make -jN local-all
$ make check
# make install