====================================== 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/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 SCRIPTING LANGUAGE BINDINGS (PYTHON, PERL) 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 (APR-util) libraries. These are included in Subversion source tarball releases - if you are building from a source tarball, and wish to use the included versions, you may skip ahead to the next requirement. If you are not building from a tarball, you will need to get these yourself. Visit this page, and be sure to download the 0.9.x version: 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 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. You don't need the latest development versions, since Subversion is guaranteed to compile against the latest released APR and APR-util. However, if you really want to, 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: $ svn co \ http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x apr $ svn co \ http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x apr-util NOTE: On Windows you will also need apr-iconv. Check it out next to the apr and apr-util directories: $ svn co \ http://svn.apache.org/repos/asf/apr/apr-iconv/branches/0.9.x apr-iconv 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. 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. 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). 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.7 (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 as part of the Subversion build process. 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.7.tar.gz Unpack the archive using tar/gunzip and rename the resulting directory from "./neon-0.24.7/" 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 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.2.52. Version 4.3 has been recently released, but APR-util 0.9.x has not been updated to support it. We *strongly* recommend using 4.2 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/index.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 "Documents & files" area: http://subversion.tigris.org/servlets/ProjectDocumentList Look in the "Releases > Windows > Windows BDB" section. 6. Apache Web Server 2.0.49 or newer (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. 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. Note that compiling under Windows requires Python 2.2 or newer. 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. 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 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 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/ 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 which requires it 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.7) 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 (aka Visual Studio.NET aka Visual Studio.NET 2002) 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/ * Awk, from http://cm.bell-labs.com/cm/cs/who/bwk/awk95.exe This 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.24.7 or higher, downloaded from http://www.webdav.org/neon/neon-0.24.7.tar.gz which is required for building the client components. Neon is included in the zip file distribution. * 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.50. Only needed for building the server dso modules. * 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. * Apache apr, apr-util, and apr-iconv libraries, version 0.9.5. Included in both the Subversion ZIP file and the Apache 2 source tarball. 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/ * ZLib 1.1.4 or higher (version 1.1.x) binaries http://www.winimage.com/zLibDll/zlib114dll.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 available from http://www.kernel.org/pub/software/devel/nasm/binaries/win32/ * For localization gnu gettext is needed. Get gettext-runtime-0.13.bin.woe32.zip, gettext-tools-0.13.bin.woe32.zip, and libiconv-1.9.1.bin.woe32.zip from http://mirrors.kernel.org/gnu/gettext/ and http://mirrors.kernel.org/gnu/libiconv/. * 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. The Subversion tar.gz file uses the POSIX.1 standard for file names which exceed 100 characters. This format is not understood by all programs which claim to be able to unpack .tar.gz files. Notable examples of this are WinZip and the utilities which can be found at http://unxutils.sourceforge.net/. The version of tar at http://gnuwin32.sourceforge.net/ is derived from GNU tar, so it can handle POSIX.1. However, it is *not* able to unpack gzip files, although it is able to read a pipe from gzip. Cygwin can unpack this file, however cygwin is a large package to install such just to unpack the tarball on Windows. To avoid these problems use the Subversion zip file source distribution. The other required package which is packaged as a tar file (openssl) can be unpacked with any of the utilities mentioned. 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 (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. * 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 (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. * If you checked out Subversion from the repository then extract neon into SVN\src-trunk\neon, the zip file source distribution includes neon. * 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-4.2.52\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. * Extract Apache source into SVN\http-2.0.50 if you wish to build the server dso modules. * 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 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 * Make a directory SVN\gettext and unpack gettext-runtime-0.13.bin.woe32.zip, gettext-tools-0.13.bin.woe32.zip, and libiconv-1.9.1.bin.woe32.zip into it. Add SVN\gettext\bin to your path, SVN\gettext\include to your INCLUDE path and SVN\gettext\lib to your LIB path environment variables. You can add these on the command line as shown below. E.4 Building the Binaries To build the binaries either follow the instructions here or use build\win32\vc6-build.bat.in after editing it's default paths to match yours and saving it as vc6-build.bat. The vc6-build.bat does a full build so it requires Apache 2 source and if the tests are to be run the Apache 2 install. 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 NASMDIR=C:\SVN\nasm C:>set SDKINC=C:\Program Files\Microsoft SDK\include C:>set SDKLIB=C:\Program Files\Microsoft SDK\lib C:>set GETTEXTINC=C:\SVN\gettext\include C:>set GETTEXTLIB=C:\SVN\gettext\lib C:>set GETTEXTBIN=C:\SVN\gettext\bin C:>PATH=%PATH%;%DRIVE%:\SVN\src-%DIR%\db4-win32;%NASMDIR%; %PYTHONDIR%;%AWKDIR%;%GETTEXTBIN% C:>set INCLUDE=%SDKINC%;%INCLUDE%;%GETTEXTINC% C:>set LIB=%SDKLIB%;%LIB%;%GETTEXTLIB% 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 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.50 --with-berkeley-db=db4-win32 --with-openssl=..\openssl-0.9.7d --with-zlib=..\zlib --enable-nls --enable-bdb-in-apr-util C:>cd .. C:>set APACHEDIR=C:\Program Files\Apache Group\Apache2 C:>msdev httpd-2.0.50\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 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 change -t dsw into -t vcproj on the gen-make.py command. In this case you will also have to distribute the C runtime dll with the binaries. * 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.7d --with-zlib=..\zlib --enable-nls --enable-bdb-in-apr-util Then build subversion: C:>msdev subversion_msvc.dsw /USEENV /MAKE "__ALL_TESTS__ - Win32 Release" C:>cd .. Or, with Visual C++.NET: C:>devenv subversion_vcnet.sln /USEENV /build "Debug" /project "__ALL_TESTS__" 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 gettext\bin\intl.dll svn-win32-%VER%\bin C:>copy gettext\bin\iconv.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 If Apache 2 and the server modules were built: C:>copy httpd-2.0.50\srclib\apr\Release\libapr.dll svn-win32-%VER%\bin C:>copy httpd-2.0.50\srclib\apr-iconv\Release\libapriconv.dll svn-win32-%VER%\bin C:>copy httpd-2.0.50\srclib\apr-util\Release\libaprutil.dll svn-win32-%VER%\bin C:>copy httpd-2.0.50\srclib\apr-iconv\Release\iconv\*.so svn-win32-%VER%\iconv If the source is from the zip file, Apache 2 has not been built and the server modules are not required: C:>copy src-%DIR%\apr\Release\libapr.dll svn-win32-%VER%\bin C:>copy src-%DIR%\apr-iconv\Release\libapriconv.dll svn-win32-%VER%\bin C:>copy src-%DIR%\apr-util\Release\libaprutil.dll svn-win32-%VER%\bin 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 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/clients/cmdline/ repositories DAV svn SVNPath c:/SVN/src-trunk/Release/subversion/tests/clients/cmdline/ 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 ============================ 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 SVN versions of everything, checkout the "httpd 2.0.x" branch from apache.org. 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 Place this module wherever you wish; it's an independent project. $ svn co \ http://svn.apache.org/repos/asf/httpd/httpd/branches/2.0.x httpd-2.0 Checkout the "apr" and "apr-util" modules into the srclib/ directory: $ cd httpd-2.0/srclib $ svn co \ http://svn.apache.org/repos/asf/apr/apr/branches/0.9.x apr $ svn co \ http://svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x 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 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.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/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 SCRIPTING LANGUAGE BINDINGS (PYTHON, PERL) =============================================== See the file ./subversion/bindings/swig/INSTALL.