Alien-SVN
view release on metacpan or search on metacpan
src/subversion/INSTALL view on Meta::CPAN
======================================
INSTALLING SUBVERSION
A Quick Guide
======================================
$LastChangedDate: 2013-09-27 06:57:44 +0000 (Fri, 27 Sep 2013) $
Contents:
I. INTRODUCTION
A. Audience
B. Dependency Overview
C. Dependencies in Detail
D. Documentation
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.apache.org/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.59 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.
* SQLite (REQUIRED for client and server)
Subversion uses SQLite to manage some internal databases.
* 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.
* libserf (OPTIONAL for client)
The Serf library allows 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.
* OpenSSL (OPTIONAL for client and server)
OpenSSL enables your client to access SSL-encrypted https://
URLs (using 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.
* KDELibs, GNOME Keyring (OPTIONAL for client)
Subversion contains optional support for storing passwords in
KWallet (KDE 4) or GNOME Keyring.
* libmagic
If the libmagic library is detected at compile time,
it will be used to determine mime-types of binary files
which are added to version control. Note that mime-types
configured via auto-props or the mime-types-file option
take precedence.
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 script that downloads the minimal prerequisite
libraries (Apache Portable Runtime, Sqlite, and Zlib). The script,
'get-deps.sh', is available in the same directory as this file.
When run, it will place 'apr', 'apr-util', 'serf', 'zlib', and
'sqlite-amalgamation' directories directly into your unpacked Subversion
distribution. With the exception of sqlite-amalgamation, they will
still need to be configured, built and installed explicitly, and
Subversion's own configure script may need to be told where to find
them, if they were not installed in standard system locations.
Note: there are optional dependencies (such as openssl, swig, and httpd)
which get-deps.sh does not download.
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.X.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.
****************************************************************
** 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 distribution dependencies: |
| ------------------------------------- |
| |
| For a long time, Subversion's main distribution contained |
| APR and APR-UTIL (both 0.9.x), plus a few other things that |
| we couldn't count on the installation system having. But |
| nowadays, Subversion's requirements are no longer exotic, |
| and so our main distribution contains just the Subversion |
| source code itself -- people compiling Subversion are |
| expected to either have the APR libraries already installed |
| on their system, or to be capable of fetching them easily. |
| |
| Note that 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. |
| |
| 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 (and Apache httpd if |
| necessary) after upgrading APR! |
|______________________________________________________________|
If you do not have a pre-installed APR and APR-util, 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 try
to locate the libraries using 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 ...
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; ./configure ...; make; make install; cd ..
$ cd apr-util; ./buildconf; ./configure ...; make; make install; cd ..
Configure build and install both libraries before running Subversion's
configure script.
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. autoconf 2.59 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.
4. 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.
5. Serf library 1.2.1 or newer (OPTIONAL)
If you want your client to be able to speak to an Apache
server (via a http:// or https:// URL), you must link against
serf. Though optional, we strongly recommend this.
In order to use ra_serf, you must install serf, and run Subversion's
./configure with the argument --with-serf. If serf is installed in a
non-standard place, you should use
--with-serf=/path/to/serf/install
instead.
Serf can be obtained via your system's package distribution
system or directly from http://code.google.com/p/serf/.
For more information on serf and Subversion's ra_serf, see the file
subversion/libsvn_ra_serf/README.
6. OpenSSL (OPTIONAL)
### needs some updates. I think serf automagically handles
### finding OpenSSL, but we may need more docco here. and w.r.t
### zlib.
The Serf library has support for SSL encryption by relying on the
OpenSSL library.
a. Using OpenSSL on the client through Serf
On Unix systems, to build Serf with OpenSSL, you need OpenSSL
installed on your system, and you must add "--with-ssl" as a
"./configure" parameter. If your OpenSSL installation is hard
for Serf 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. You can also specify a path to the zlib library
using "--with-libs".
Under Windows, you can specify the paths to these libraries by
passing the options --with-zlib and --with-openssl to gen-make.py.
### Is that right? In-tree build of Neon was disabled in r875974.
This may now apply to Serf, or else gen-make.py should be
updated to remove such options.
c. Using OpenSSL on the Apache server
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/
7. 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 or newer, which brings
auto-recovery functionality to the Berkeley DB database
environment.
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=db.h:/usr/local/include/db4.7:/usr/local/lib/db4.7:db-4.7
to your `configure' switches, and the build process will use the
Berkeley DB header and library in the named directories. 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?folderID=688
Look in the "Releases > Windows > Windows BDB" section.
8. 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 abilities for various forms of
authentication. To learn more about SASL or to get the source
code, visit:
http://freshmeat.net/projects/cyrussasl/
9. 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.
10. Python 2.5 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.5 or higher on your system. The majority of the test
suite is written in Python, as is part of Subversion's build
system.
11. 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.
12. 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.com/
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).
13. SQLite (REQUIRED)
Subversion 1.8 requires SQLite version 3.7.12 or above. You can meet
this dependency several ways:
* Use an SQLite amalgamation file.
* Specify an SQLite installation to use.
* Let Subversion find an installed SQLite.
To use an SQLite-provided amalgamation, just drop sqlite3.c into
Subversion's sqlite-amalgamation/ directory, or point to it with the
--with-sqlite configure option. This file also ships with the Subversion
dependencies distribution, or you can download it from SQLite:
http://www.sqlite.org/download.html
14. pkg-config (Unix only, OPTIONAL)
Subversion uses pkg-config to find appropriate options used
at build time.
15. D-Bus (Unix only, OPTIONAL)
D-Bus is a message bus system. D-Bus is required for support for KWallet
and GNOME Keyring. pkg-config is needed to find D-Bus headers and library.
16. Qt 4 (Unix only, OPTIONAL)
Qt is a cross-platform application framework. QtCore, QtDBus and QtGui
modules are required for support for KWallet. pkg-config is needed
to find Qt headers and libraries.
17. KDELibs 4 (Unix only, OPTIONAL)
Subversion contains optional support for storing passwords in KWallet.
KDELibs contains core KDE libraries. Subversion uses libkdecore and libkdeui
libraries when support for KWallet is enabled. kde4-config is used to get
some necessary options. pkg-config, D-Bus and Qt 4 are also required.
If you want to build support for KWallet, then pass the '--with-kwallet'
option to `configure`. If KDE is installed in a non-standard prefix, then
use:
--with-kwallet=/path/to/KDE/prefix
18. GLib 2 (Unix only, OPTIONAL)
GLib is a general-purpose utility library. GLib is required for support
for GNOME Keyring. pkg-config is needed to find GLib headers and library.
19. GNOME Keyring (Unix only, OPTIONAL)
Subversion contains optional support for storing passwords in GNOME Keyring.
pkg-config is needed to find GNOME Keyring headers and library. D-Bus and
GLib are also required. If you want to build support for GNOME Keyring,
then pass the '--with-gnome-keyring' option to `configure`.
20. Ctypesgen (OPTIONAL)
Ctypesgen is Python wrapper generator for ctypes. It is used to generate
a part of Subversion Ctypes Python bindings (CSVN). If you want to build
CSVN, then pass the '--with-ctypesgen' option to `configure`. If ctypesgen.py
is installed in a non-standard place, then use:
--with-ctypesgen=/path/to/ctypesgen.py
For more information on CSVN, see subversion/bindings/ctypes-python/README.
21. libmagic (OPTIONAL)
Subversion's configure script attempts to find libmagic automatically.
If it is installed in a non-standard location, then use:
--with-libmagic=/path/to/libmagic/prefix
The files include/magic.h and lib/libmagic.so.1.0 (or similar)
are expected beneath this prefix directory. If they cannot be
found Subversion will be compiled without support for libmagic.
If libmagic is installed but support for it should not be compiled
in, then use:
--with-libmagic=no
If configure should fail when libmagic is not present, but only
the default locations should be searched, then use:
--with-libmagic
D. 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.apache.org/download/
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)
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/libserf*
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.59 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.59 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 'https://svn.apache.org/repos/asf/subversion/trunk'
It probably means that the dynamic loader/linker can't find all
of the libsvn_* libraries.
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 https://svn.apache.org/repos/asf/subversion/trunk svn
$ cd svn
$ # get SQLite amalgamation if 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.apache.org/packages#windows
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
( run in 1.422 second using v1.01-cache-2.11-cpan-39bf76dae61 )