======================================
INSTALLING SUBVERSION
A Quick Guide
======================================
$LastChangedDate$
"Is Subversion stable enough for me to use for my own projects?"
We think so! Read the full FAQ answer on the website:
http://subversion.tigris.org/project_faq.html#stable
Contents:
I. BUILD REQUIREMENTS
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. SWIG LANGUAGE BINDINGS
I. BUILD REQUIREMENTS
==================
Subversion depends on a number of third party tools and libraries.
If you are bootstrapping from a tarball, zipfile or an RPM then
you will already have everything you require to get a Subversion
client. So long as you don't plan to build a new client from the
latest source or to build a Subversion server, you can go directly
to section II.A.
Otherwise, you need to read the following so that you can determine
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.
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.5 (http://apr.apache.org/)
Whenever you want to build any part of Subversion, you need the
Apache Portable Runtime (APR) and the APR Utility (APRUTIL)
libraries. At the time of this writing, there were no official
release versions of APR/APRUTIL available, but Subversion tries
to stay compatible with the versions bundled within the latest
httpd-2.0 release.
Therefore, the easiest way to get apr/apr-util is to download
the latest release of the httpd source, and use the apr/apr-util
trees contained within.
$ tar zxvf httpd-2.X.YY.tar.gz
$ cd httpd-2.X.YY/srclib
$ cp -a apr apr-util /path/to/svn_wc
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 APRUTIL libraries. By default, it will look
for and use the apr-config and apu-config scripts. These scripts
provide all the relevant information for the APR and APRUTIL
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 APRUTIL 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 HTTP 2.0 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. The
Subversion tarball comes with copies of the libraries' source
code stored in these subdirectories which you could copy or link
to.
You probably don't need the latest CVS versions, since Subversion
is only guaranteed to compile against the latest released httpd-2.0
or APR and APRUTIL. However, just in case, you can use the
following two commands. If you run them from the directory where
you've checked out Subversion, then the APR source code will be
in "./apr" and "./apr-util", where Subversion wants it:
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
(password: 'anoncvs')
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic \
co -r APR_0_9_BRANCH apr
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic \
co -r APU_0_9_BRANCH apr-util
The "./apr" and "./apr-util" directories will not be considered
if the search for apr-config and apu-config scripts is successful.
NOTE: On Windows you will also need apr-iconv. Check it out next to
the apr and apr-util directories:
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic \
co -r API_0_9_BRANCH apr-iconv
Be sure to use a native Windows CVS 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.
2. autoconf 2.50 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,
but at this stage in Subversion's development you'll probably
want to do this as well.
3. libtool 1.4 or newer (Unix only)
This is required only if you plan to build from the latest source
(see section II.B), which you probably want to do. See above.
Note: Some systems (Solaris, for example) require libtool 1.4.3 or
newer. The autogen.sh script knows about that.
4. Neon library 0.24.6 (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. If you
want to use Subversion to connect to a server over ra_dav (via a
http:// or https:// url), you will require Neon.
The Neon library source code can be installed in "./neon" if you
want Subversion to build it. The source code is included with the
latest Subversion tarball, and it can also be obtained from:
http://www.webdav.org/neon/neon-0.24.6.tar.gz
Unpack the archive using tar/gunzip and rename the resulting
directory from "./neon-0.24.6/" to "./neon/".
Without source code, a previously compiled library can be picked up
from the standard locations. If you want to specify a nonstandard
location, you need to use the LDFLAGS environment variable when
you run "./configure". You may also have to specify where the
neon-config script (which identifies various features of the Neon
library) is kept by giving the "--with-neon=" option to
"./configure". Note that the script should be kept in a "bin"
subdirectory beneath wherever "--with-neon" is pointed.
5. Berkeley DB 4.X
Berkeley DB is needed to build a Subversion server, or to access
a repository on local disk. If you are only interested in
building a Subversion client that speaks to a remote (networked)
repository, you don't need it.
You should try to use the latest version of BerkeleyDB 4.X. At
the time of writing, 4.2.52 is the latest version; we *strongly*
recommend using it over 4.1 or 4.0. Not only is the fastest and
most stable version we've seen, but it also enables 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.sleepycat.com/download/patchlogs.shtml
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.2
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.
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:
http://subversion.tigris.org/servlets/ProjectDocumentList
6. Apache Web Server 2.0.49 or newer
(http://httpd.apache.org/download.cgi)
The Apache HTTP server is required if you wish to offer your
Subversion repository over the Internet. 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.
7. Python 2.0 (http://www.python.org/)
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.
8. Visual C++ 6.0 or newer (Windows Only)
To build Subversion under any of the MS Windows platforms, you
will need a copy of Microsoft Visual C++. You can generate the
project files using the gen-make.py script.
9. Perl 5.8 or newer (Windows only)
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.
10. 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.
With Unix-based systems, you can enable support for SSL from the
Subversion build provided that you are building Neon in the
"./neon/" directory as described above in section I.4. You also
need OpenSSL installed on your system. Just add "--with-ssl" as
a parameter when you run Subversion's "./configure", and it will
be passed on to the Neon build system. If your OpenSSL
installation is hard for Neon to find, you may need to use
"--with-libs=/path/to/lib" in addition. The zlib library is
included in Neon by default, but 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 a Subversion server
and you can even use 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/
Many Unix systems already come with zlib, but if you need it, it
is available from:
http://www.gzip.org/zlib/
Windows users should just get the pre-built package:
http://www.gzip.org/zlib/contrib/zlib113-win32.zip
The neon build scripts on Windows are set up to use those
libraries.
11. Building The Documentation
The master source format for Subversion's documentation is
Docbook Lite. See doc/book/README for instructions how to
compile the book into a useful format.
The preferred documentation source format used to be Texinfo. We are
in the process of migrating all texinfo files to DocBook Lite. The
online documentation for texinfo is at
http://www.gnu.org/manual/texinfo-4.0/html_chapter/texinfo_toc.html
Depending on exactly which doc targets you make, you'll need one
or more of:
* the `makeinfo' program from the latest texinfo package in
ftp://ftp.gnu.org/pub/gnu/texinfo/
* the `texi2dvi' or `texi2html' programs
* the `dvipdf' script from Ghostscript (pipes dvi | ps |
Ghostscript)
If `makeinfo' is not installed before `configure' is run, then
the documentation will not be created and installed.
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.2.52 is
preferred however)
expat (Comes with RedHat)
neon (Version 0.24.6)
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 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.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.)
Unlike the pre-packaged tarball (which includes apr, apr-util,
and neon subdirectories), ./configure will fail if it cannot
find apr, apr-util, and neon libraries already installed on your
system.
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, 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 optimised 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.
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 Visual Studio
7 but these instructions assumes VS6.
* A recent Windows SDK, the one provided with Visual Studio 6 is
too old. You only need the 'Core SDK'. 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/
* Neon 0.24.6 or higher, downloaded from
http://www.webdav.org/neon/neon-0.24.6.tar.gz which is required
for building the client components.
* Berkeley DB is required for support for local server components,
version 4.2.52 is available from
http://subversion.tigris.org/servlets/ProjectDocumentList as
db-4.2.52-win32.zip. For more information see Section I.5.
* Apache 2 source, downloaded from
http://httpd.apache.org/download.cgi, these instructions assume
version 2.0.49.
* Apache 2 msi install file, also from
http://httpd.apache.org/download.cgi (required for running the
tests)
* ZLib 1.1.4 or higher (version 1.1.x) binaries
http://www.winimage.com/zLibDll/zlib114dll.zip and sources
http://www.gzip.org/zlib/zlib114.zip
* Openssl 0.9.7d or higher obtained from
http://www.openssl.org/source/openssl-0.9.7d.tar.gz
* An assembler, e.g., nasm which is avaliable from
http://www.kernel.org/pub/software/devel/nasm/binaries/win32/
* The latest version of apr-util (see Section I.1) must be told
where to find the Berkeley DB include files and libraries. You
can do this with the w32locatedb.pl script (located in the
"build" directory in the apr-util sources), which modifies
apr-util's header and DSP files. The instructions at the top of
the script file explain how to use the script.
If your copy of apr-util does not contain build\w32locatedb.pl,
you can download a recent version from here:
http://subversion.tigris.org/files/documents/15/8705/w32locatedb.pl
You will need Perl 5.8 to run this script.
* A Subversion client binary from http://subversion.tigris.org/ to
do the initial checkout of the Subversion source. See the section
"Bootstrapping from a Zip or Installer File under Windows" above
for more.
* A means of unpacking the files. Native Win32 versions of gunzip,
tar and unzip can be found at http://unxutils.sourceforge.net/ or
http://gnuwin32.sourceforge.net/.
If you have WinZip that will also unpack the files.
E.2 Notes
The neon library supports secure connections with OpenSSL and
on-the-wire compression with zlib. If you want to use those
features, you should pass the options "--with-zlib" and
"--with-openssl" to the gen-make.py script. See Section I.10 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:
http://download.microsoft.com/download/platformsdk/Redist/5.50.4027.300/W9XNT4/EN-US/shfinst.EXE
E.3 Preparation
This section descibes how to unpack the files to make a build tree.
* Make a directory SVN and cd into it.
* Checkout the version of Subversion you require:
For the 1.0.x development branch:
svn co http://svn.collab.net/repos/svn/branches/1.0.x src-1.0.x
For version 1.0.2:
svn co http://svn.collab.net/repos/svn/tags/1.0.2/ src-1.0.2
The rest of these instructions assume the 1.0.x development branch.
* Install Visual Studio 6. You either have to tell the installer to
register environment variables or run VCVARS32.BAT before building
anything.
* Install a recent Windows Core SDK
* Register the SDK with 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
* Install Apache 2 using the msi file
* Extract neon into SVN\src-1.0.x\neon
* Extract the Berkeley DB files into SVN\src-1.0.x\db4-win32. It's a
good idea to add SVN\src-1.0.x\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-4.2.52\build_win32\db.h to
SVN\src-1.0.x\db4-win32\include, and all the import libraries to
SVN\src-1.0.x\db4-win32\lib. Again, the DLLs should be somewhere in
your path.
* Extract Apache source into SVN\http-2.0.49
* Extract the pre-built zlib into SVN\zlib and copy
SVN\zlib\static32\zlibstat.lib into SVN\zlib
* Extract openssl into SVN\openssl-0.9.7d
* Extract nasm into SVN\nasm and put it in your path
* Put the w32locatedb.pl script in
httpd-2.0.49\srclib\apr-util\build\w32locatedb.pl if it isn't already
there.
E.4 Building the Binaries
Start in the SVN directory you created.
Set up the environment.
C:>set VER=1.0.x
C:>set DIR=1.0.x
C:>set DRIVE=C
C:>set PYTHONDIR=C:\Python22
C:>set SDKINC=C:\Program Files\Microsoft SDK\include
C:>set SDKLIB=C:\Program Files\Microsoft SDK\lib
C:>set APACHEMODDIR=C:\Program Files\Apache Group\Apache2\modules
C:>PATH=%PATH%;%DRIVE%:\SVN\src-%DIR%\db4-win32;%DRIVE%:\SVN\nasm;%PYTHONDIR%
C:>set INCLUDE=%SDKINC%;%INCLUDE%
C:>set LIB=%SDKLIB%;%LIB%
OpenSSL
C:>cd openssl-0.9.7d
C:>perl Configure VC-WIN32
C:>call ms\do_nasm
C:>nmake -f ms\ntdll.mak
C:>cd out32dll
C:>call ..\ms\test
C:>cd ..\..
Apache 2
C:>perl httpd-2.0.49\srclib\apr-util\build\w32locatedb.pl dll src-%DIR%\db4-win32\include src-%DIR%\db4-win32\lib
C:>msdev httpd-2.0.49\apache.dsw /MAKE "BuildBin - Win32 Release"
Subversion
Things to note:
* gen-make.py is supposed to configure the build to use apr* from
the Apache build, it doesn't work so the built apr* files have to
be copied from the Apache build to the src-1.0.x directory.
* The generated dsw file doesn't build all of the tests so there
are explicit msdev commands to build test_utf and test_ra_local.
* If you don't want to build mod_dav_svn, omit the --with-httpd
option. In this case, 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. ymmv.
* The /USEENV switch to msdev makes it take notice of the INCLUDE and
LIB environment variables, it also makes it ignore it's 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 add -t vcproj to the gen-make.py
command, you will also have to distribute the C runtime dll with the
binaries.
* Apache must not be running or the copy of the modules will fail.
C:>mkdir src-%DIR%\apr
C:>mkdir src-%DIR%\apr-iconv
C:>mkdir src-%DIR%\apr-util
C:>xcopy /S /Y httpd-2.0.49\srclib\apr src-%DIR%\apr
C:>xcopy /S /Y httpd-2.0.49\srclib\apr-iconv src-%DIR%\apr-iconv
C:>xcopy /S /Y httpd-2.0.49\srclib\apr-util src-%DIR%\apr-util
C:>cd src-%DIR%
C:>python gen-make.py -t dsp --with-httpd=..\httpd-2.0.49 --with-berkeley-db=db4-win32 --with-openssl=..\openssl-0.9.7d --with-zlib=..\zlib
C:>msdev subversion_msvc.dsw /USEENV /MAKE "__ALL_TESTS__ - Win32 Release"
C:>msdev subversion_msvc.dsw /USEENV /MAKE "test_utf - Win32 Release"
C:>msdev subversion_msvc.dsw /USEENV /MAKE "test_ra_local - Win32 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.
From within the SVN directory copy these files:
C:>mkdir svn-win32-%VER%
C:>mkdir svn-win32-%VER%\bin
C:>mkdir svn-win32-%VER%\httpd
C:>mkdir svn-win32-%VER%\iconv
C:>copy src-%DIR%\db4-win32\bin\libdb42.dll svn-win32-%VER%\bin
C:>copy openssl-0.9.7d\out32dll\libeay32.dll svn-win32-%VER%\bin
C:>copy openssl-0.9.7d\out32dll\ssleay32.dll svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\clients\cmdline\svn.exe svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\svnadmin\svnadmin.exe svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\svndumpfilter\svndumpfilter.exe svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\svnlook\svnlook.exe svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\svnserve\svnserve.exe svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\svnversion\svnversion.exe svn-win32-%VER%\bin
C:>copy src-%DIR%\Release\subversion\mod_authz_svn\mod_authz_svn.so svn-win32-%VER%\httpd
C:>copy src-%DIR%\Release\subversion\mod_dav_svn\mod_dav_svn.so svn-win32-%VER%\httpd
C:>copy src-%DIR%\apr-iconv\Release\iconv\*.so svn-win32-%VER%\iconv
E.6 Testing the Binaries
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\clients
C:>xcopy /S /Y subversion\tests\clients Release\subversion\tests\clients
Copy the dso files into the Apache modules directory.
C:>copy Release\subversion\mod_dav_svn\mod_dav_svn.so "%APACHEMODDIR%"
C:>copy Release\subversion\mod_authz_svn\mod_authz_svn.so "%APACHEMODDIR%"
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.
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:
DAV svn
SVNParentPath C:/SVN/src-1.0.x/Release/subversion/tests/clients/cmdline/repositories
DAV svn
SVNPath c:/SVN/src-1.0.x/Release/subversion/tests/clients/cmdline/local_tmp/repos
Then restart Apache and run the tests:
C:>PATH=%DRIVE%:\SVN\svn-win32-%VER%\bin;%PATH%
C:>cd src-%DIR%
C:>python win-tests.py -c -r -v
C:>python win-tests.py -c -r -v -u http://localhost
C:>cd ..
III. BUILDING A SUBVERSION SERVER
============================
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.0
Subversion tries to compile against the latest released version
of Apache httpd-2.0. The easiest thing for you to do is
download a source tarball of the latest release and unpack that.
Alternately, if you'd rather use the latest CVS versions of
everything, checkout the "httpd-2.0" cvs module from apache.org.
If you have questions about the Apache 2.0 build, please consult
the HTTPD install documentation:
http://httpd.apache.org/docs-2.0/install.html. Place this
module wherever you wish; it's an independent project.
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
(password 'anoncvs')
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic \
co -r APACHE_2_0_BRANCH httpd-2.0
Checkout the "apr" and "apr-util" modules into the srclib/ directory:
$ cd httpd-2.0/srclib
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr
$ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr-util
At the top of the httpd-2.0 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 Server
-------------------------------------------
Go back into your subversion working copy and run ./autogen.sh if
you need to. Then, assuming Apache HTTP 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 HTTP 2.0 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.0:
$ /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/clients/cmdline/README.
For advice about tracing problems, see "Debugging the server" in
the HACKING file.
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). 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/project_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. SWIG LANGUAGE BINDINGS
======================
(See the file ./subversion/bindings/swig/INSTALL.)