======================================
INSTALLING SUBVERSION
A Quick Guide
======================================
$LastChangedDate$
Contents:
I. INTRODUCTION
A. Audience
B. Dependency Overview
C. Dependencies in Detail
II. INSTALLATION
A. Building from a Tarball or RPM
B. Building the Latest Source under Unix
C. Building under Unix in Different Directories
D. Installing from a Zip or Installer File under Windows
E. Building the Latest Source under Windows
III. BUILDING A SUBVERSION SERVER
A. Setting Up Apache
B. Making and Installing the Subversion Server
C. Configuring Apache for Subversion
D. Running and Testing
E. Alternative: 'svnserve' and ra_svn
IV. PLATFORM-SPECIFIC ISSUES
A. Windows XP
B. Mac OS X
V. PROGRAMMING LANGUAGE BINDINGS (PYTHON, PERL, RUBY, JAVA)
I. INTRODUCTION
============
A. Audience
This document is written for people who intend to build
Subversion from source code. Normally, the only people who do
this are Subversion developers and package maintainers.
If neither of these labels fits you, we recommend you find an
appropriate binary package of Subversion and install that.
While the Subversion project doesn't officially release binary
packages, a number of volunteers have made such packages
available for different operating systems. Most Linux and BSD
distributions already have Subversion packages ready to go via
standard packaging channels, and other volunteers have built
'installers' for both Windows and OS X. Visit this page for
package links:
http://subversion.tigris.org/project_packages.html
For those of you who still wish to build from source, Subversion
follows the Unix convention of "./configure && make", but it has
a number of dependencies.
B. Dependency Overview
You'll need the following build tools to compile Subversion:
* autoconf 2.58 or later (Unix only)
* libtool 1.4 or later (Unix only)
* a reasonable C compiler (gcc, Visual Studio, etc.)
Subversion also depends on the following third-party libraries:
* libapr and libapr-util (REQUIRED for client and server)
The Apache Portable Runtime (APR) library provides an
abstraction of operating-system level services such as file
and network I/O, memory management, and so on. It also
provides convenience routines for things like hashtables,
checksums, and argument processing. While it was originally
developed for the Apache HTTP server, APR is a standalone
library used by Subversion and other products. It is a
critical dependency for all of Subversion; it's the layer
that allows Subversion clients and servers to run on
different operating systems.
* libz (REQUIRED for client and server)
Subversion uses zlib for compressing binary differences.
These diff streams are used everywhere -- over the network,
in the repository, and in the client's working copy.
* SQLite (REQUIRED for client and server)
SQLite is a lightweight, embeddable SQL library. The
Subversion repository uses a SQLite database to track merge
data.
* libneon or libserf (OPTIONAL for client)
The Neon and Serf libraries both allow the Subversion client
to send HTTP requests. This is necessary if you want your
client to access a repository served by the Apache HTTP
server. There is an alternate 'svnserve' server as well,
though, and clients automatically know how to speak the
svnserve protocol. Thus it's not strictly necessary for your
client to be able to speak HTTP... though we still recommend
that your client be built to speak both HTTP and svnserve
protocols. Your client can be compiled against either
libneon or libserf (or both), as they offer competing
implementations.
* OpenSSL (OPTIONAL for client and server)
OpenSSL enables your client to access SSL-encrypted https://
URLs (using either libneon or libserf) in addition to
unencrypted http:// URLs. To use SSL with Subversion's
WebDAV server, Apache needs to be compiled with OpenSSL as
well.
* Berkeley DB (OPTIONAL for client and server)
There are two different repository 'back-end'
implementations. One implementation stores data in a flat
filesystem (known as FSFS); the other implementation stores
data in a Berkeley DB database (known as BDB). When you
create a repository, you have the option of specifying a
storage back-end. The Berkeley DB back-end will only be
available if the BDB libraries are discovered at compile
time.
* libsasl (OPTIONAL for client and server)
If the Cyrus SASL library is detected at compile time, then
the svn client (and svnserve server) will be able to utilize
SASL to do various forms of authentication when speaking the
svnserve protocol.
* Python, Perl, Java, Ruby (OPTIONAL)
Subversion is mostly a collection of C libraries with
well-defined APIs, with a small collection of programs that
use the APIs. If you want to build Subversion API bindings
for other languages, you need to have those languages
available at build time.
C. Dependencies in Detail
Subversion depends on a number of third party tools and libraries.
Some of them are only required to run a Subversion server; others
are necessary just for a Subversion client. This section explains
what other tools and libraries will be required so that Subversion
can be built with the set of features you want.
On Unix systems, the './configure' script will tell you if you are
missing the correct version of any of the required libraries or
tools, so if you are in a real hurry to get building, you can skip
straight to section II. If you want to gather the pieces you will
need before starting out, however, you should read the following.
If you're just installing a Subversion client, the Subversion
team has created a package containing the minimal prerequisite
libraries (Apache Portable Runtime, Neon, and Zlib) called the
"dependency package" tarball or zipfile. You should be able to
find it at the same place that you downloaded the Subversion
tarball itself from. (Note that this is new as of Subversion
1.4.0; previous releases packaged the dependencies in the same
tarball as Subversion itself.) If you don't have these
libraries installed already, you can simply unpack the
dependency package "on top of" the Subversion package; for
example, if you are using a .tar.gz bundle on Unix, you could
type:
$ tar xzvf subversion-1.x.x.tar.gz
$ tar xzvf subversion-deps-1.x.x.tar.gz
$ cd subversion-1.x.x
This will place 'apr', 'apr-util', 'neon', and 'zlib'
directories directly into your unpacked Subversion distribution,
where they will be automatically configured and built by
Subversion's build process.
Note: Because previous builds of Subversion may have installed older
versions of these libraries, you may want to run some of the cleanup
commands described in section II.B before installing the following.
1. Apache Portable Runtime 0.9.7 or 1.2.X (REQUIRED)
Whenever you want to build any part of Subversion, you need the
Apache Portable Runtime (APR) and the APR Utility (APR-util)
libraries. These are included in the Subversion dependency package -
if you are building from a source tarball and wish to use the versions
of APR and APR-util included there, just unpack the dependency package
and skip ahead to the next requirement.
****************************************************************
** IMPORTANT ISSUE ABOUT APR VERSIONS: READ THIS. **
** **
****************************************************************
| |
| APR 0.9.X and 1.X are binary-incompatible. |
| |
| This means: |
| |
| - if you are already using Subversion with APR 0.9.X, and |
| then upgrade your libapr to 1.X without rebuilding |
| Subversion, things will break and segfault. |
| |
| - if your Subversion server libraries are linked to one |
| version of APR, but your Apache server is linked to a |
| different version, things will break and segfault. |
| |
| Subversion 1.0 originally shipped with APR 0.9. Even |
| though APR 1.X has been available for many years, we |
| continue to ship APR 0.9 so as not to accidentally break |
| binary compatibility in Subversion upgrades. |
| |
| However, it's *perfectly* safe to use APR 1.X from the |
| beginning. In fact, we recommend it. If you're building |
| Subversion for the first time, there's no compatibility |
| issue to worry about, so grab the latest version of APR |
| (rather than the 0.9.X version we distribute.) |
| |
| If you already have a Subversion installation using APR |
| 0.9.x, it's still possible to move to APR 1.X safely. Just |
| be sure to recompile Subversion after upgrading APR! |
|______________________________________________________________|
If you are not building from a tarball with the dependency
package, you will need to get these yourself:
http://apr.apache.org/download.cgi
On Unix systems, if you already have the APR libraries compiled and do
not wish to regenerate them from source code, then Subversion needs to
be able to find them.
There are a couple of options to "./configure" that tell it where
to look for the APR and APR-util libraries. By default, it will first
look for bundled versions of APR and APR-util, and then try to locate
already installed versions of the libraries using the apr-config and
apu-config scripts. These scripts provide all the relevant information
for the APR and APR-util installations.
If you want to specify the location of the APR library, you can use
the "--with-apr=" option of "./configure". It should be able to find
the apr-config script in the standard location under that directory
(e.g. ${prefix}/bin).
Similarly, you can specify the location of APR-util using the
"--with-apr-util=" option to "./configure". It will look for the
apu-config script relative to that directory.
For example, if you want to use the APR libraries you built
with the Apache httpd server, you could run:
$ ./configure --with-apr=/usr/local/apache2 \
--with-apr-util=/usr/local/apache2 ...
If you want Subversion to build the APR libraries from source
code as part of the Subversion build process, you can put their
source code into the "./apr" and "./apr-util" directories.
Be sure to use a native Windows SVN client (as opposed to
Cygwin's version) so that the .dsp files get carriage-returns at
the ends of their lines. Otherwise Visual Studio will complain
that it doesn't recognize the .dsp files.
If you use APR libraries checked out from svn in an Unix
environment, you need to run the 'buildconf' script in each
library's directory, to regenerate the configure scripts and
other files required for compiling the libraries:
$ cd apr; ./buildconf; cd ..
$ cd apr-util; ./buildconf; cd ..
2. Zlib (REQUIRED)
Subversion's binary-differencing engine depends on zlib for
compression. Most Unix systems have libz pre-installed, but
if you need it, you can get it from
http://www.zlib.net
3. SQLite 3.x or newer (REQUIRED for client and server)
SQLite is a lightweight, embeddable SQL library necessary to
build any repository-related code.
You can get sqlite 3.5.3 from:
http://www.sqlite.org/sqlite-3.5.3.tar.gz
SQLite must be built in thread-safe mode (with 'configure
--enable-threadsafe'). If building SQLite yourself, you
have the option of unpacking the archive into the top of the
Subversion source tree and renaming the resulting directory
within the Subversion source code from ./sqlite-3.5.3/ to
./sqlite/. Subversion will then build and install it for
you.
4. autoconf 2.58 or newer (Unix only)
This is required only if you plan to build from the latest source
(see section II.B). Generally only developers would be doing this.
5. libtool 1.4 or newer (Unix only)
This is required only if you plan to build from the latest source
(see section II.B).
Note: Some systems (Solaris, for example) require libtool 1.4.3 or
newer. The autogen.sh script knows about that.
6. An HTTP client libary: either neon or serf. (OPTIONAL)
neon and serf are competing implementations of HTTP client
libraries. If you want your client to be able to speak to an
Apache server (via a http:// or https:// URL), you must link
against at least one of these libraries. Though optional, we
strongly recommend this.
(If you link against both, you can configure which one is used
in your ~/.subversion/servers configuration file.)
a. Neon library 0.25, 0.26 or 0.27 (http://www.webdav.org/neon/)
The Neon library allows a Subversion client to interact
with remote repositories over the Internet via a WebDAV
based protocol.
The source code is included with the Subversion
dependencies package, and it can also be obtained from:
http://www.webdav.org/neon/neon-0.25.5.tar.gz
http://www.webdav.org/neon/neon-0.26.4.tar.gz
http://www.webdav.org/neon/neon-0.27.2.tar.gz
Building Neon inside the subversion build:
The Neon library source code can be placed in "./neon" if
you want Subversion to build it as part of the Subversion
build process.
Unpack the archive using tar/gunzip. Rename the resulting
directory from ./neon-0.XX.Y to just "./neon", inside the
top level of your Subversion source tree. (This is what
unpacking the Subversion dependencies package does, too.)
Using Neon as an external library:
We recommend that you keep the neon installation out of the
Subversion working copy. This is because most developers
have multiple working copies of Subversion, and it is
easier to use a single instance of the Neon library for all
instances. To do this, just unzip/untar Neon, and build
and install it according to its own standard installation
instructions. Then follow the steps below to use the
installed Neon when building.
Subversion's configuration mechanism should auto-detect the
installed Neon. If it does not, you may need to set the
LDFLAGS environment variable when you run "./configure", or
specify Neon's location by passing the "--with-neon="
option to "./configure". Look for the "neon-config" script
in a "bin/" subdirectory of the target of "--with-neon".
For example, if you pass "--with-neon=/usr/local/myneon/",
then there should be a file
"/usr/local/myneon/bin/neon-config".
b. Serf library 0.1.2 (http://code.google.com/p/serf/)
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 ra_neon
and better for HTTP proxy caches. The serf library can be
found at:
http://code.google.com/p/serf/
In order to use ra_serf instead of ra_neon, you must install
serf, and run Subversion's ./configure with the argument
--with-serf. (To only use ra_serf and not ra_neon, you
should also use --without-neon.) If serf is installed in a
non-standard place, you should use
--with-serf=/path/to/serf/install
instead. If you build with both ra_neon and ra_serf,
Subversion will use ra_neon by default; add "http-library =
serf" to the [global] section of your ~/.subversion/servers
file to use ra_serf instead.
For more information on serf and Subversion's ra_serf, see
the file subversion/libsvn_ra_serf/README.
7. OpenSSL (OPTIONAL)
The Neon and Serf libraries have 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:
http://www.openssl.org/
8. Berkeley DB 4.X (OPTIONAL)
Berkeley DB is needed to build a Subversion server that supports
the BDB repository filesystem, or to access a BDB repository on
local disk. If you will only use the FSFS repository filesystem,
or if you are building a Subversion client that will only speak
to remote (networked) repositories, you don't need it.
The current recommended version is 4.4.20, which brings
auto-recovery functionality to the Berkeley DB database
environment. (Preliminary testing indicates that Subversion
will also work with Berkeley DB 4.5 once APR grows support for
that release.)
If you must use an older version of Berkeley DB, we *strongly*
recommend using 4.3 or 4.2 over the 4.1 or 4.0 versions. Not
only are these significantly faster and more stable, but they
also enable Subversion repositories to automatically clean up
database journal files to save disk space.
You'll need Berkeley DB installed on your system. You can
get it from:
http://www.oracle.com/technology/software/products/berkeley-db/index.html
If you have Berkeley DB installed in a place not searched by default
for includes and libraries, add something like this:
--with-berkeley-db=/usr/local/BerkeleyDB.4.4
to your `configure' switches, and the build process will use the
Berkeley library in the named directory. You may need to use a
different path, of course. Note that in order for the detection
to succeed, the dynamic linker must be able to find the libraries
at configure time.
If you are on the Windows platform and want to build Subversion,
a precompiled version of the Berkeley DB library is available for
download at the Subversion web site "Documents & files" area:
http://subversion.tigris.org/servlets/ProjectDocumentList
Look in the "Releases > Windows > Windows BDB" section.
9. Cyrus SASL library (OPTIONAL)
If the Simple Authentication and Security Layer (SASL) library
is detected on your system, then the Subversion client and
svnserve server can utilize its abliities for various form of
authentication. To learn more about SASL or to get the source
code, visit:
http://freshmeat.net/projects/cyrussasl/
10. Apache Web Server 2.X (OPTIONAL)
(http://httpd.apache.org/download.cgi)
The Apache httpd server is one of two methods to make your Subversion
repository available over a network - the other is a custom server
program called svnserve, which requires no extra software packages.
Building Subversion, the Apache server, and the modules that Apache
needs to communicate with Subversion are complicated enough that there
is a whole section at the end of this document that describes how it
is done: See section III for details.
11. Python 2.0 or newer (http://www.python.org/) (OPTIONAL)
If you want to run "make check" or build from the latest source
under Unix as described in section II.B and III.D, install
Python 2.0 or higher on your system. The majority of the test
suite is written in Python, as is part of Subversion's build
system. Note that compiling under Windows requires Python 2.2
or newer.
12. Perl 5.8 or newer (Windows only) (OPTIONAL)
To build Subversion under any of the MS Windows platforms, you
will also need Perl 5.8 or newer to run apr-util's w32locatedb.pl
script.
13. MASM 6 or newer (Windows only, OPTIONAL)
The Windows build scripts for Subversion can use the Microsoft
Macro Assembler (MASM) to build an optimized version of the ZLib
library. Make sure that the version of MASM you use is compatible
with the C compiler. If you're using MSVC 6, and don't have MASM 6,
a free MASM-compatible assembler is available here:
http://www.masm32.org/
You only need ML.EXE and ML.ERR from this distribution.
The VS.NET installation already contains MASM (but note, that
version if MASM is not compatible with MSVC 6).
14. 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:
http://subversion.tigris.org/servlets/ProjectDocumentList
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!
# rm -f /usr/local/lib/libsvn*
# rm -f /usr/local/lib/libapr*
# rm -f /usr/local/lib/libexpat*
# rm -f /usr/local/lib/libneon*
Start the process by running "autogen.sh":
$ sh ./autogen.sh
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.58 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.58 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:
subversion/libsvn_ra/ra_loader.c:209: (apr_err=170000)
svn: Unrecognized URL scheme 'http://svn.collab.net/repos/svn/trunk'
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
C. Building under Unix in Different Directories
--------------------------------------------
It is possible to configure and build Subversion on Unix in a
directory other than the working copy. For example
$ svn co http://svn.collab.net/repos/svn/trunk svn
$ cd svn
$ # get neon/apr as required
$ chmod +x autogen.sh
$ ./autogen.sh
$ mkdir ../obj
$ cd ../obj
$ ../svn/configure [...with options as appropriate...]
$ make
puts the Subversion working copy in the directory svn and builds
it in a separate, parallel directory obj.
Why would you want to do this? Well there are a number of
reasons...
* You may prefer to avoid "polluting" the working copy with
files generated during the build.
* You may want to put the build directory and the working
copy on different physical disks to improve performance.
* You may want to separate source and object code and only
backup the source.
* You may want to remote mount the working copy on multiple
machines, and build for different machines from the same
working copy.
* You may want to build multiple configurations from the
same working copy.
The last reason above is possibly the most useful. For instance
you can have separate debug and optimized builds each using the
same working copy. Or you may want a client-only build and a
client-server build. Using multiple build directories you can
rebuild any or all configurations after an edit without the need
to either clean and reconfigure, or identify and copy changes
into another working copy.
D. Installing from a Zip or Installer File under Windows
--------------------------------------------------------
Of all the ways of getting a Subversion client, this is the
easiest. Download a Zip (*.zip) or self-extracting installer
(*-setup.exe) file from:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91
For a Zip file, run your unzipping utility (WinZIP, ZipGenius,
UltimateZIP, FreeZIP, whatever) and extract the DLLs and EXEs to
a directory of your choice. Included in the download is the SVN
client, the SVNADMIN administration tool, and the SVNLOOK
reporting tool.
Note that if you need support for non-English locales you'll have
to set the APR_ICONV_PATH environment variable to the path of the
iconv directory in the folder that contains the Subversion install.
You may also want to add the bin directory in the Subversion folder
to your PATH environment variable so as to not have to use the full
path when running Subversion commands.
To test the installation, open a DOS box (run either "cmd" or
"command" from the Start menu's "Run..." menu option), change to
the directory you installed the executables into, and run:
C:\test>svn co http://svn.collab.net/repos/svn/trunk svn
This will get the latest Subversion sources and put them into the
"svn" subdirectory.
If using a self-extracting .exe file, just run it instead of
unzipping it, to install Subversion.
E. Building the Latest Source under Windows
----------------------------------------
E.1 Prerequisites
* Visual Studio 6 and service pack. It can be built with later versions
of Visual Studio (Visual Studio.NET 2002, 2003, 2005 and Visual C++
Express 2005) but these instructions assume VS6.
* A recent Windows SDK if you are using Visual Studio 6.
You can get it from MSDN if you have it or from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ if you
don't.
* Python 2.2 or higher, downloaded from http://www.python.org/ which is
used to generate the project files.
* Perl 5.8 or higher from http://www.activestate.com/
* Awk (from http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe) is
needed to compile Apache or APR. Note that this is the actual awk
program, not an installer - just rename it to awk.exe and it is
ready to use.
* Neon 0.26.1 or higher, downloaded from
http://www.webdav.org/neon/neon-0.26.1.tar.gz which is required
for building the client components. Neon is included in the zip file
distribution. (0.25.0+ compiles, but does not properly support all
HTTP auth types.)
* Apache apr, apr-util, and apr-iconv libraries, version 0.9.12.
Included in both the Subversion dependencies ZIP file and the
Apache 2.058 source zip. If you are building from a Subversion
checkout and have not downloaded Apache 2, then get these 3
libraries from http://www.apache.org/dist/apr/. Note that
the 1.x APR releases are not yet functional with Subversion --
see the note on '[Optional] Apache 2 source' below.
* ZLib 1.2 or higher is required and is included in the Subversion
dependencies zip file or can be obtained from http://www.zlib.org
* Either a Subversion client binary from http://subversion.tigris.org/ to
do the initial checkout of the Subversion source or the zip file
source distribution. See the section "Bootstrapping from a Zip or
Installer File under Windows" above for more.
* A means of unpacking the files, e.g., WinZIP or similar.
Additional Options
* [Optional] Apache 2 source, downloaded from
http://httpd.apache.org/download.cgi, these instructions assume
version 2.0.58. This is only needed for building the Subversion
server Apache modules. Note that although Subversion will compile
against Apache 2.2.3 and APR 1.2.7, there is a bug that causes
runtime failures with Subversion on Windows. The fix is included in
APR 1.2.8 and will be bundled in the next HTTP Server release
(likely to be 2.2.4).
* [Optional] Apache 2 msi install file, also from
http://httpd.apache.org/download.cgi (required for running the
tests). Only needed for testing the server dso modules and if
you are using Visual Studio 6.
Note that if you are not using Visual Studio 6 (and you want to
run and test the server modules) then you must rebuild Apache
from source -- do not use the stock MSI since mixing C runtime
libraries is not supported.
* [Optional] Berkeley DB for backend support of the server
components -- versions 4.3.27 and 4.4.20 are available from
http://subversion.tigris.org/servlets/ProjectDocumentList as
db-4.3.27-win32.zip and db-4.4.20-win32.zip.
For more information see Section I.5.
* [Optional] Openssl 0.9.7f or higher can be obtained from
http://www.openssl.org/source/openssl-0.9.7f.tar.gz
* [Optional] A modified version of GNU libintl, called
svn-win32-libintl.zip, can be used for displaying localized
messages. Available at:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=2627
* [Optional] GNU gettext for generating message catalog (.mo)
files from message translations. You can get the latest
binaries from http://gnuwin32.sourceforge.net/. You'll need the
binaries (gettext-0.14.1-bin.zip) and dependencies
(gettext-0.14.1-dep.zip).
* [Optional] An assembler, e.g., MASM32 from http://www.masm32.com/
or nasm which is available from
http://www.kernel.org/pub/software/devel/nasm/binaries/win32/
E.2 Notes
The Neon library supports secure connections with OpenSSL and
on-the-wire compression with zlib. If you want to use the
secure connections feature, you should pass the option
"--with-openssl" to the gen-make.py script. See Section I.11 for
more details.
If you are installing under Win9x or NT4 (and do not have Internet
Explorer 5 or later) and svn.exe doesn't run, try installing
shfolder.dll from here (wrapped url):
http://download.microsoft.com/download/platformsdk/Redist/
5.50.4027.300/W9XNT4/EN-US/shfinst.EXE
E.3 Preparation
This section describes how to unpack the files to make a build tree.
* Make a directory SVN and cd into it.
* Either checkout Subversion:
svn co http://svn.collab.net/repos/svn/trunk/ src-trunk
or unpack the zip file distribution and rename the directory to
src-trunk.
* Install Visual Studio 6. You either have to tell the installer to
register environment variables or run VCVARS32.BAT before building
anything. If you are using a newer Visual Studio, use the
'Visual Studio 200x Command Prompt' on the Start menu.
* Install and register a recent Windows Core SDK if you are using
Visual Studio 6. This is a quote from the Microsoft February 2003
SDK documentation:
"To register the SDK bin, include, and library directories with
Microsoft Visual StudioŽ version 6.0 and Visual Studio .NET,
click Start, point to All Programs, point to Microsoft Platform
SDK February 2003, point to Visual Studio Registration, and then
click Register PSDK Directories with Visual Studio. This
registration process places the SDK bin, include, and library
directories at the beginning of the search paths, which ensures
that the latest headers and libraries are used when building
applications in the IDE. Note that for Visual Studio 6.0
integration to succeed, Visual Studio 6.0 must run at least once
before you select Register PSDK Directories with Visual
Studio. Also note that when this option is run, the IDEs should
not be running."
* Install Python and add it to your path
* Install Perl (it should add itself to the path)
* Copy AWK (awk95.exe) to awk.exe (e.g. SVN\awk\awk.exe) and add
the directory containing it (e.g. SVN\awk) to the path.
* Install Apache 2 using the msi file if you are going to test the
server dso modules and are using Visual Studio 6. You must build
and install it from source if you are not using Visual Studio 6 and
want to build and/or test the server modules.
* If you checked out Subversion from the repository then extract neon
into SVN\src-trunk\neon, the zip file source distribution includes
neon.
* If you want BDB backend support, extract the Berkeley DB files
into SVN\src-trunk\db4-win32. It's a good idea to add
SVN\src-trunk\db4-win32\bin to your PATH, so that Subversion can find
the Berkeley DB DLLs.
[NOTE: This binary package of Berkeley DB is provided for
convenience only. Please don't address questions about
Berkeley DB that aren't directly related to using Subversion
to the project mailing list.]
If you build Berkeley DB from the source, you will have to copy
the file db-x.x.x\build_win32\db.h to
SVN\src-trunk\db4-win32\include, and all the import libraries to
SVN\src-trunk\db4-win32\lib. Again, the DLLs should be somewhere in
your path.
* If you want to build the server modules, extract Apache source into
SVN\httpd-2.x.x.
* If you are building from a checkout of Subversion, and you are NOT
building Apache, then you will need the APR libraries. Depending
on how you got your version of APR, either:
- Extract the APR, APR-util and APR-iconv source distributions into
SVN\apr, SVN\apr-util, and SVN\apr-iconv respectively.
Or:
- Extract the apr, apr-util and apr-iconv directories from the
srclib folder in the Apache httpd source into SVN\apr,
SVN\apr-util, and SVN\apr-iconv respectively.
* Extract the ZLib sources into SVN\zlib if you are not using the zlib
included in the dependencies zip file.
* If you want secure connection (https) client support, extract openssl
into SVN\openssl-x.x.x
* If you want localized message support, extract svn-win32-libintl.zip
into SVN\svn-win32-libintl and extract gettext-x.x.x-bin.zip and
gettext-x.x.x-dep.zip into SVN\gettext-x.x.x-bin.
Add SVN\gettext-x.x.x-bin\bin to your path.
* [Optional] Extract MASM32 (only the ML.EXE and ML.ERR files) into
SVN\asm (or extract nasm into SVN\asm) and put it in your path.
E.4 Building the Binaries
To build the binaries either follow the instructions here or use
build\win32\vc6-build.bat.in after editing its default paths to match
yours and saving it as vc6-build.bat. The vc6-build.bat does a full build
using all options so it requires Apache 2 source and the other optional
components.
Start in the SVN directory you created.
Set up the environment (commands should be one line even if wrapped here).
C:>set VER=trunk
C:>set DIR=trunk
C:>set DRIVE=C
C:>set PYTHONDIR=C:\Python22
C:>set AWKDIR=C:\SVN\Awk
C:>set ASMDIR=C:\SVN\asm
C:>set SDKINC=C:\Program Files\Microsoft SDK\include
C:>set SDKLIB=C:\Program Files\Microsoft SDK\lib
C:>set GETTEXTBIN=C:\SVN\gettext-0.14.1-bin\bin
C:>PATH=%PATH%;%DRIVE%:\SVN\src-%DIR%\db4-win32;%ASMDIR%;
%PYTHONDIR%;%AWKDIR%;%GETTEXTBIN%
C:>set INCLUDE=%SDKINC%;%INCLUDE%
C:>set LIB=%SDKLIB%;%LIB%
OpenSSL
C:>cd openssl-0.9.7f
C:>perl Configure VC-WIN32
[*] C:>call ms\do_masm
C:>nmake -f ms\ntdll.mak
C:>cd out32dll
C:>call ..\ms\test
C:>cd ..\..
*Note: Use "call ms\do_nasm" of you have nasm instead of MASM, or
"call ms\do_ms" if you don't have an assembler.
Apache 2
This step is only required for building the server dso modules.
The Subversion gen-make.py script must be run before building Apache or
Apache and Subversion will be running incompatible versions of apr.
C:>cd src-%DIR%
C:>python gen-make.py -t dsp --with-httpd=..\httpd-2.0.58
--with-berkeley-db=db4-win32 --with-openssl=..\openssl-0.9.7f
--with-zlib=..\zlib --with-libintl=..\svn-win32-libintl
C:>cd ..
C:>set APACHEDIR=C:\Program Files\Apache Group\Apache2
C:>msdev httpd-2.0.58\apache.dsw /MAKE "BuildBin - Win32 Release"
Subversion
Things to note:
* If you don't want to build mod_dav_svn, omit the --with-httpd
option. The zip file source distribution contains apr, apr-util and
apr-iconv in the default build location. If you have downloaded the
apr files yourself you will have to tell the generator where to find
the APR libraries; the options are --with-apr, --with-apr-util and
--with-apr-iconv.
* If you would like a debug build substitute Debug for Release in
the msdev commands.
* There have been rumors that Subversion on Win32 can be built
using the latest cygwin, you probably don't want the zip file source
distribution though. ymmv.
* The /USEENV switch to msdev makes it take notice of the INCLUDE and
LIB environment variables, it also makes it ignore its own lib and
include settings so you need to have the Windows SDK lib and include
directories in the LIB and INCLUDE environment variables. Do *not*
use this switch when starting up the msdev Visual environment. If you
wish to build in the Visual environment the SDK lib and include
directories must be in the Tools/Options/Directories settings (if you
followed the 'Register the SDK with Visual Studio 6' instructions
above this has been done for you).
* If you are using Visual Studio .NET change -t dsw into -t vcproj and
add the --vsnet-version=200x option on the gen-make.py command.
In this case you will also have to distribute the C runtime dll with
the binaries. Also, since Apache/APR do not provide .vcproj files,
you will need to convert the Apache/APR .dsp files to .vcproj files
with Visual Studio before building -- just open the Apache .dsw file
and answer 'Yes To All' when the conversion dialog pops up, or you
can open the individual .dsp files and convert them one at a time.
The Apache/APR projects required by Subversion are:
apr-util\libaprutil.dsp, apr\libapr.dsp,
apr-iconv\libapriconv.dsp, apr-util\xml\expat\lib\xml.dsp,
apr-util\uri\gen_uri_delims.dsp (for APR 0.9.x),
apr-iconv\ccs\libapriconv_ccs_modules.dsp, and
apr-iconv\ces\libapriconv_ces_modules.dsp.
* If the server dso modules are being built and tested Apache must not
be running or the copy of the dso modules will fail.
C:>cd src-%DIR%
If Apache 2 has been built and the server modules are required then
gen-make.py will already have been run. If the source is from the zip
file, Apache 2 has not been built so gen-make.py must be run:
C:>python gen-make.py -t dsp --with-berkeley-db=db4-win32
--with-openssl=..\openssl-0.9.7f --with-zlib=..\zlib
--with-libintl=..\svn-win32-libintl
Then build subversion:
C:>msdev subversion_msvc.dsw /USEENV /MAKE "__ALL_TESTS__ - Win32 Release"
C:>cd ..
Or, with Visual C++.NET 2002, 2003, 2005:
C:>devenv subversion_vcnet.sln /build "Release" /project "__ALL_TESTS__"
C:>cd ..
Or, with Visual C++ Express 2005:
C:>msbuild subversion_vcnet.sln /t:__ALL_TESTS__ /p:Configuration=Release
C:>cd ..
The binaries have now been built.
E.5 Packaging the binaries
You now need to copy the binaries ready to make the release zip
file. You also need to do this to run the tests as the new binaries
need to be in your path. You can use the build/win32/make_dist.py
script in the Subversion source directory to do that.
[TBD: Describe how to do this. Note dependencies on zip, jar, doxygen.]
E.6 Testing the Binaries
[TBD: It's been a long, long while since it was necessary to move
binaries around for testing. win-tests.py does that automagically.
Fix this section accordingly, and probably reorder, putting
the packaging at the end.]
The build process creates the binary test programs but it does not
copy the client tests into the release test area.
C:>cd src-%DIR%
C:>mkdir Release\subversion\tests\cmdline
C:>xcopy /S /Y subversion\tests\cmdline Release\subversion\tests\cmdline
If the server dso modules have been built then copy the dso files and
dlls into the Apache modules directory.
C:>copy Release\subversion\mod_dav_svn\mod_dav_svn.so "%APACHEDIR%"\modules
C:>copy Release\subversion\mod_authz_svn\mod_authz_svn.so
"%APACHEDIR%"\modules
C:>copy svn-win32-%VER%\bin\intl.dll "%APACHEDIR%\bin"
C:>copy svn-win32-%VER%\bin\iconv.dll "%APACHEDIR%\bin"
C:>copy svn-win32-%VER%\bin\libdb42.dll "%APACHEDIR%\bin"
C:>cd ..
Put the svn-win32-trunk\bin directory at the start of your path so
you run the newly built binaries and not another version you might
have installed.
Then run the client tests:
C:>PATH=%DRIVE%:\SVN\svn-win32-%VER%\bin;%PATH%
C:>cd src-%DIR%
C:>python win-tests.py -c -r -v
If the server dso modules were built configure Apache to use the
mod_dav_svn and mod_authz_svn modules by making sure these lines appear
uncommented in httpd.conf:
LoadModule dav_module modules/mod_dav.so
LoadModule dav_fs_module modules/mod_dav_fs.so
LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so
And further down the file add location directives to point to the
test repositories. Change the paths to the SVN directory you created
(paths should be on one line even if wrapped here):
DAV svn
SVNParentPath C:/SVN/src-trunk/Release/subversion/tests/cmdline/
svn-test-work/repositories
DAV svn
SVNPath c:/SVN/src-trunk/Release/subversion/tests/cmdline/
svn-test-work/local_tmp/repos
Then restart Apache and run the tests:
C:>python win-tests.py -c -r -v -u http://localhost
C:>cd ..
III. BUILDING A SUBVERSION SERVER
============================
Subversion has two servers you can choose from: svnserve and
Apache. svnserve is a small, lightweight server program that is
automatically compiled when you build Subversion's source. Apache
is a more heavyweight HTTP server, but tends to have more features.
This section primarily focuses on how to build Apache and the
accompanying mod_dav_svn server module for it. If you plan to use
svnserve instead, jump right to section E for a quick explanation.
A. Setting Up Apache
-----------------
(Following the BOOTSTRAPPING FROM RPM procedures above will install and
build the latest Subversion server for Linux RedHat 7.1, 7.2, and PPC
Linux systems *IF* the apache-devel-2.0.41 or greater package is already
installed when the SUBVERSION RPM is built.)
1. Obtaining and Installing Apache 2
Subversion tries to compile against the latest released version
of Apache httpd 2.X. The easiest thing for you to do is download
a source tarball of the latest release and unpack that.
****************************************************************
** IMPORTANT ISSUE ABOUT APACHE VERSIONS: READ THIS. **
** **
****************************************************************
| |
| First, be sure to read the APR version warning box, back in |
| section I.C.1, which explains that APR 0.9.x and 1.X are |
| binary-incompatible. |
| |
| Apache HTTPD 2.0 uses APR 0.9.x. |
| Apache HTTPD 2.2 uses APR 1.2.x. |
| |
| We recommend using the latest Apache. However, whatever |
| version you choose, you *must* ensure that Subversion |
| and Apache are using the same version of APR. If you don't, |
| things will segfault and break. |
|______________________________________________________________|
If you have questions about the Apache httpd 2.0 build, please consult
the httpd install documentation:
http://httpd.apache.org/docs-2.0/install.html
At the top of the httpd tree:
$ ./buildconf
$ ./configure --enable-dav --enable-so --enable-maintainer-mode
The first arg says to build mod_dav.
The second arg says to enable shared module support which is needed
for a typical compile of mod_dav_svn (see below).
The third arg says to include debugging information. If you
built Subversion with --enable-maintainer-mode, then you should
do the same for Apache; there can be problems if one was
compiled with debugging and the other without.
Note: if you have multiple db versions installed on your system,
Apache might link to a different one than Subversion, causing
failures when accessing the repository through Apache. To prevent
this from happening, you have to tell Apache which db version to
use and where to find db. Add --with-dbm=db4 and
--with-berkeley-db=/usr/local/BerkeleyDB.4.2 to the configure
line. Make sure this is the same db as the one Subversion uses.
This note assumes you have installed Berkeley DB 4.2.52
at its default locations. For more info about the db requirement,
see section I.5.
You may also want to include other modules in your build. Add
--enable-ssl to turn on SSL support, and --enable-deflate to turn on
compression support, for example. Consult the Apache documentation
for more details.
All instructions below assume you configured Apache to install
in its default location, /usr/local/apache2/; substitute
appropriately if you chose some other location.
Compile and install apache:
$ make && make install
B. Making and Installing the Subversion Apache Server Module
---------------------------------------------------------
Go back into your subversion working copy and run ./autogen.sh if
you need to. Then, assuming Apache httpd 2.0 is installed in the
standard location, run:
$ ./configure
Note: do *not* configure subversion with "--disable-shared"!
mod_dav_svn *must* be built as a shared library, and it will
look for other libsvn_*.so libraries on your system.
If you see a warning message that the build of mod_dav_svn is
being skipped, this may be because you have Apache httpd 2.X
installed in a non-standard location. You can use the
"--with-apxs=" option to locate the apxs script:
$ ./configure --with-apxs=/usr/local/apache2/bin/apxs
Note: it *is* possible to build mod_dav_svn as a static library
and link it directly into Apache. Possible, but painful. Stick
with the shared library for now; if you can't, then ask.
$ rm /usr/local/lib/libsvn*
If you have old subversion libraries sitting on your system,
libtool will link them instead of the `fresh' ones in your tree.
Remove them before building subversion.
$ make clean && make && make install
After the make install, the Subversion shared libraries are in
/usr/local/lib/. mod_dav_svn.so should be installed in
/usr/local/apache2/modules/.
Section II.E explains how to build the server on Windows.
C. Configuring Apache for Subversion
---------------------------------
The following section is an abbreviated version of the
information in the Subversion Book
(http://svnbook.red-bean.com). Please read chapter 6 for more
details.
The following assumes you have already created a repository.
For documentation on how to do that, see README.
The following also assumes that you have modified
/usr/local/apache2/conf/httpd.conf to reflect your setup.
At a minimum you should look at the User, Group and ServerName
directives. Full details on setting up apache can be found at:
http://httpd.apache.org/docs-2.0/
First, your httpd.conf needs to load the mod_dav_svn module.
Subversion's 'make install' target should automatically add this
line for you. But if apache gives you an error like "Unknown
DAV provider: svn", then you may want to verify that this line
exists in your httpd.conf:
LoadModule dav_svn_module modules/mod_dav_svn.so
NOTE: if you built mod_dav as a dynamic module as well, make sure
the above line appears after the one that loads mod_dav.so.
Next, add this to the *bottom* of your httpd.conf:
DAV svn
SVNPath /absolute/path/to/repository
This will give anyone unrestricted access to the repository. If
you want limited access, read or write, you add these lines to
the Location block:
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /my/svn/user/passwd/file
And:
a) For a read/write restricted repository:
Require valid-user
b) For a write restricted repository:
Require valid-user
c) For separate restricted read and write access:
AuthGroupFile /my/svn/group/file
Require group svn_committers
Require group svn_committers
Require group svn_readers
These are only a few simple examples. For a complete tutorial
on Apache access control, please consider taking a look at the
tutorials found under "Security" on the following page:
http://httpd.apache.org/docs-2.0/misc/tutorials.html
In order for 'svn cp' to work (which is actually implemented as a
DAV COPY command), mod_dav needs to be able to determine the
hostname of the server. A standard way of doing this is to use
Apache's ServerName directive to set the server's hostname. Edit
your /usr/local/apache2/conf/httpd.conf to include:
ServerName svn.myserver.org
If you are using virtual hosting through Apache's NameVirtualHost
directive, you may need to use the ServerAlias directive to specify
additional names that your server is known by.
If you have configured mod_deflate to be in the server, you can enable
compression support for your repository by adding the following line
to your Location block:
SetOutputFilter DEFLATE
NOTE: If you are unfamiliar with an Apache directive, or not exactly
sure about what it does, don't hesitate to look it up in the
documentation: http://httpd.apache.org/docs-2.0/mod/directives.html.
NOTE: Make sure that the user 'nobody' (or whatever UID the
httpd process runs as) has permission to read and write the
Berkeley DB files! This is a very common problem.
D. Running and Testing
-------------------
Fire up apache 2:
$ /usr/local/apache2/bin/apachectl stop
$ /usr/local/apache2/bin/apachectl start
Check /usr/local/apache2/logs/error_log to make sure it started
up okay.
Try doing a network checkout from the repository:
$ svn co http://localhost/svn/repos wc
The most common reason this might fail is permission problems
reading the repository db files. If the checkout fails, make
sure that the httpd process has permission to read and write to
the repository. You can see all of mod_dav_svn's complaints in
the Apache error logfile, /usr/local/apache2/logs/error_log.
To run the regression test suite for networked Subversion, see
the instructions in subversion/tests/cmdline/README.
For advice about tracing problems, see "Debugging the server" in
www/hacking.html.
E. Alternative: 'svnserve' and ra_svn
-----------------------------------
An alternative network layer is libsvn_ra_svn (on the client
side) and the 'svnserve' process on the server. This is a
simple network layer that speaks a custom protocol over plain
TCP (documented in libsvn_ra_svn/protocol):
$ svnserve -d # becomes a background daemon
$ svn checkout svn://localhost/usr/local/svn/repository
You can use the "-r" option to svnserve to set a logical root
for repositories, and the "-R" option to restrict connections to
read-only access. ("Read-only" is a logical term here; svnserve
still needs write access to the database in this mode, but will
not allow commits or revprop changes.)
'svnserve' has built-in CRAM-MD5 authentication (so you can use
non-system accounts), and can also be tunneled over SSH (so you
can use existing system accounts). It's also capable of using
Cyrus SASL if libsasl2 is detected at ./configure time. Please
read chapter 6 in the Subversion Book
(http://svnbook.red-bean.com) for details on these features.
IV. PLATFORM-SPECIFIC ISSUES
========================
A. Windows XP
----------
There is an error in the Windows XP TCP/IP stack which causes
corruption in certain cases. This problem is exposed only
through ra_dav.
The root of the matter is caused by duplicating file handles
between parent and child processes. The httpd Apache group
explains this a lot better:
http://www.apache.org/dist/httpd/binaries/win32/#xpbug
And there's an item about this in the Subversion FAQ:
http://subversion.tigris.org/faq.html#windows-xp-server
The only known workaround for now is to update to Windows XP
SP1 (or higher).
B. Mac OS X
--------
[TBD: Describe BDB 4.0.x problem]
V. PROGRAMMING LANGUAGE BINDINGS (PYTHON, PERL, RUBY, JAVA)
========================================================
For Python, Perl and Ruby bindings, see the file
./subversion/bindings/swig/INSTALL
For Java bindings, see the file
./subversion/bindings/javahl/README