| ====================================== |
| INSTALLING SUBVERSION |
| A Quick Guide |
| ====================================== |
| |
| $LastChangedDate$ |
| |
| |
| Contents: |
| |
| I. INTRODUCTION |
| A. Audience |
| B. Dependency Overview |
| C. Documentation |
| |
| II. INSTALLATION |
| A. Building with autoconf and make (Unix only) |
| B. Building with CMake (Windows and Unix) |
| C. Building with vcproj/vcxproj (Windows only, deprecated) |
| D. Running the test suite |
| |
| III. BUILDING A SUBVERSION SERVER |
| A. Setting Up Apache Httpd |
| B. Making and Installing the Subversion Apache Server Module |
| C. Configuring Apache Httpd for Subversion |
| D. Running and Testing |
| E. Alternative: 'svnserve' and ra_svn |
| |
| IV. PROGRAMMING LANGUAGE BINDINGS (PYTHON, PERL, RUBY, JAVA) |
| |
| V. DEPENDENCIES IN DETAIL |
| |
| |
| |
| 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: |
| |
| https://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 and libtool 2.0 or later |
| (Unix only, for the autoconf-based build system) |
| |
| or |
| |
| * CMake 3.20 or later (Windows and Unix, for the |
| CMake-based build system) |
| |
| * a reasonable C compiler (gcc, Visual Studio, etc.) |
| |
| |
| Subversion also depends on the following third-party libraries: |
| |
| Required: |
| |
| * APR 1.4 or later and APR-util 1.3 or later -- the portability layer |
| that allows Subversion to run on different operating systems. |
| * Expat -- XML parsing. |
| * zlib -- compression of binary diffs, used everywhere. |
| * LZ4 r129 or later -- compression. A bundled copy can be used. |
| * SQLite 3.24.0 or later -- used for some internal databases. An |
| amalgamation file can be used instead of an installed library. |
| * utf8proc -- UTF-8 support, including Unicode normalization. A bundled |
| copy can be used. |
| |
| Optional: |
| |
| * Apache Serf 1.3.4 or later -- access to Subversion repositories over |
| http:// and https:// (client). Strongly recommended. |
| * Cyrus SASL 2 -- SASL authentication for svn:// (client and svnserve |
| server). |
| * libmagic -- MIME type detection for files added to Subversion. |
| * libsecret -- password storage in GNOME Keyring (client, Unix-only). |
| * KDE Frameworks 5 with Qt 5 and D-Bus -- password storage in KWallet |
| (client, Unix-only). |
| * Python, Perl, Java, Ruby (with py3c for Python) -- the language |
| bindings. |
| * Apache HTTP Server 2.2 or later -- the mod_dav_svn server module. |
| * Berkeley DB 4.0.14 or later -- the deprecated BDB repository backend, |
| to be removed in the future (server). |
| |
| |
| C. Documentation |
| |
| The primary documentation for Subversion is the free book |
| "Version Control with Subversion", a.k.a. "The Subversion Book", |
| obtainable from https://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 |
| ============ |
| |
| Subversion supports three different build systems: |
| - Autoconf/make, for Unix builds |
| - Visual Studio vcproj, for Windows builds |
| - CMake, for both Unix and Windows |
| |
| The first two have been in use since 2001. Sections A and C below describe |
| the classic build system. |
| |
| Subversion's CMake-based build system was created in 2024 and is still |
| under development. It will be included in Subversion 1.15 and is |
| expected to be the default build system for Windows platforms starting |
| with Subversion 1.16. Section B below describes the CMake build system. |
| |
| A. Building with autoconf and make (Unix only) |
| ------------------------------------------- |
| |
| A.1 Building From a Release Tarball |
| |
| Download the most recent distribution tarball from: |
| |
| https://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'. See the |
| section D for more information. |
| |
| A.2 Building from a Working Copy |
| |
| 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/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 'Dependency Overview' 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. |
| |
| A.3 Building In a Separate Build Directory |
| |
| 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. |
| |
| |
| B. Building using CMake (Windows and Unix) |
| --------------------------------------- |
| |
| Get the sources, either from a release tarball or by checking out the |
| official repository. |
| |
| The process for building on Unix and Windows is the same. |
| |
| $ python gen-make.py -t cmake |
| $ cmake -B out [build options] |
| $ cmake --build out |
| |
| Note: If you're using the tarball distribution, the first gen-make step |
| can be skipped. |
| |
| "out" in the commands above is the build directory used by CMake. |
| |
| Build options can be added, for example: |
| |
| $ cmake -B out -DCMAKE_INSTALL_PREFIX=/usr/local/subversion -DSVN_ENABLE_TESTS=ON |
| |
| Build options can be listed using: |
| |
| $ cmake -LH |
| |
| Windows tricks: |
| |
| - Modern versions of Microsoft Visual Studio provide support for |
| CMake projects out-of-box, including intellisense, integrated |
| options editor, test explorer, and more. |
| |
| In order to use it for Subversion, open the source directory with |
| Visual Studio, and the configuration should start automatically. |
| For editing the cache (options), do right-click to the CMakeLists.txt |
| file and clicking `CMake Settings for Subversion` will open the |
| editor. After the required settings are configured, hit `F7` in |
| order to build. For more info, check the article below: |
| |
| https://learn.microsoft.com/en-us/cpp/build/cmake-projects-in-visual-studio |
| |
| - There is a useful tool for bootstrapping the dependencies, |
| vcpkg. It provides ports for the most of the Subversion's |
| dependencies, which then could be installed via a single |
| command. |
| |
| To start using it, download the registry from GitHub, bootstrap |
| vcpkg, and install the dependencies: |
| |
| $ git clone https://github.com/microsoft/vcpkg |
| $ cd vcpkg && .\bootstrap-vcpkg.bat -disableMetrics |
| $ .\vcpkg install apr apr-util expat zlib sqlite3 serf [any other dependency] |
| |
| After this is done, vcpkg can be integrated into CMake by passing |
| the vcpkg toolchain to CMAKE_TOOLCHAIN_FILE option. In order to do |
| it with Visual Studio, open the CMake cache editor as explained in |
| the previous step, and put the following into `CMake toolchain |
| file` field, where VCPKG_ROOT is the path to vcpkg registry: |
| |
| <VCPKG_ROOT>/scripts/buildsystems/vcpkg.cmake |
| |
| |
| C. Building with vcproj/vcxproj (Windows only, deprecated) |
| ------------------------------------------------------- |
| |
| The vcproj/vcxproj-based build system is deprecated since Subversion 1.15 |
| and will be removed in a future release. See |
| |
| https://subversion.apache.org/docs/release-notes/1.15.html#vcproj |
| |
| Windows users should build Subversion using CMake (see section B above). |
| |
| The vcproj/vcxproj files for Visual Studio 2010 - 2022 can be generated |
| with gen-make.py. The required dependencies have to be present in the |
| system (built or installed) before generating the files. A minimal |
| gen-make.py command looks like this: |
| |
| C:\SVN\src>python gen-make.py --vsnet-version=2022 ^ |
| --with-apr "..\myvcpkg\x64-windows" ^ |
| --with-apr-util "..\myvcpkg\x64-windows" ^ |
| --with-zlib "..\myvcpkg\x64-windows" ^ |
| --with-sqlite "..\myvcpkg\x64-windows" |
| |
| The command generates the Visual Studio 2022 solution and project files |
| that can be used with Visual Studio and msbuild. |
| |
| The 'python gen-make.py --help' command prints the list of the options |
| available, some of which can be used when generating the project files. |
| |
| To run the test suite, build the target __ALL_TESTS__ and run |
| |
| C:\SVN\src>python win-tests.py -c -r |
| |
| The 'python win-tests.py --help' command prints the list of available |
| options. |
| |
| |
| D. Running the test suite |
| ---------------------- |
| |
| The test suite can be run using any of the build systems above. |
| |
| Each test may report PASS, XFAIL, FAIL or XPASS. |
| |
| The first two statuses are expected and "normal": |
| - PASS means a test completed with successful result. |
| - XFAIL means a test failed, but this is a known issue. |
| |
| The last two statuses are unexpected and indicate a failure: |
| - FAIL means a test returned an unexpected result. |
| - XPASS means a test which was expected to fail completed successfully. |
| |
| |
| D.1 Validating XML output |
| |
| Some Subversion commands can format their output as XML. The test suite |
| will always verify that the output is valid XML, however it is also |
| possible to check the output against the expected XML schema. To do |
| this, install the lxml and rnc2rng Python modules and start the tests |
| using the --check-xml-schema argument. |
| |
| |
| D.2 Running the test suite under the autoconf/make build system |
| |
| Tests can be started with either of the following commands |
| - make check [options] |
| Run the test suite using a local repository ("file://...") |
| - make davautocheck [options] |
| Run the test suite using a http:// repository on the local machine |
| - make svnserveautocheck [options] |
| Run the test suite using a svnserve:// repository on the local machine |
| - make check-javahl [options] |
| Test the javahl bindings |
| |
| For either command, the usual -j argument can be used to have make run |
| several tests concurrently. |
| |
| The following list are options commonly used: |
| - PARALLEL=n |
| Run n python based command line tests concurrently |
| - TESTS=[path to python based test in subversion/tests/cmdline/] |
| Run a specific Python based test |
| - APACHE_MPM=mpm type |
| Used for davautocheck, run the test using the specified Apache httpd |
| MPM engine |
| - CHECK_XML_SCHEMA |
| If this option is defined, full XML schema validation will be |
| performed, see the --check-xml-schema option above. |
| |
| |
| D.3 Running the test suite under the CMake build system |
| |
| Run the ctests command from the build directory. |
| |
| |
| III. BUILDING A SUBVERSION SERVER |
| ============================ |
| |
| Subversion has two servers you can choose from: svnserve and |
| Apache. svnserve is a small, lightweight server program that is |
| automatically compiled when you build Subversion's source. Apache |
| is a more heavyweight HTTP server, but tends to have more features. |
| |
| This section primarily focuses on how to build Apache and the |
| accompanying mod_dav_svn server module for it. If you plan to use |
| svnserve instead, jump right to section E for a quick explanation. |
| |
| |
| A. Setting Up Apache Httpd |
| ----------------------- |
| |
| 1. Obtaining and Installing Apache Httpd 2 |
| |
| Subversion tries to compile against the latest released version |
| of Apache httpd 2.2+. The easiest thing for you to do is download |
| a source tarball of the latest release and unpack that. |
| |
| If you have questions about the Apache httpd 2.2 build, please consult |
| the httpd install documentation: |
| |
| https://httpd.apache.org/docs-2.2/install.html |
| |
| At the top of the httpd tree: |
| |
| $ ./buildconf |
| $ ./configure --enable-dav --enable-so --enable-maintainer-mode |
| |
| The first arg says to build mod_dav. |
| |
| The second arg says to enable shared module support which is needed |
| for a typical compile of mod_dav_svn (see below). |
| |
| The third arg says to include debugging information. If you |
| built Subversion with --enable-maintainer-mode, then you should |
| do the same for Apache; there can be problems if one was |
| compiled with debugging and the other without. |
| |
| Note: if you have multiple db versions installed on your system, |
| Apache might link to a different one than Subversion, causing |
| failures when accessing the repository through Apache. To prevent |
| this from happening, you have to tell Apache which db version to |
| use and where to find db. Add --with-dbm=db4 and |
| --with-berkeley-db=/usr/local/BerkeleyDB.4.2 to the configure |
| line. Make sure this is the same db as the one Subversion uses. |
| This note assumes you have installed Berkeley DB 4.2.52 |
| at its default locations. |
| |
| You may also want to include other modules in your build. Add |
| --enable-ssl to turn on SSL support, and --enable-deflate to turn on |
| compression support, for example. Consult the Apache documentation |
| for more details. |
| |
| All instructions below assume you configured Apache to install |
| in its default location, /usr/local/apache2/; substitute |
| appropriately if you chose some other location. |
| |
| Compile and install apache: |
| |
| $ make && make install |
| |
| |
| B. Making and Installing the Subversion Apache Server Module |
| --------------------------------------------------------- |
| |
| Go back into your subversion working copy and run ./autogen.sh if |
| you need to. Then, assuming Apache httpd 2.2 is installed in the |
| standard location, run: |
| |
| $ ./configure |
| |
| Note: do *not* configure subversion with "--disable-shared"! |
| mod_dav_svn *must* be built as a shared library, and it will |
| look for other libsvn_*.so libraries on your system. |
| |
| If you see a warning message that the build of mod_dav_svn is |
| being skipped, this may be because you have Apache httpd 2.x |
| installed in a non-standard location. You can use the |
| "--with-apxs=" option to locate the apxs script: |
| |
| $ ./configure --with-apxs=/usr/local/apache2/bin/apxs |
| |
| Note: it *is* possible to build mod_dav_svn as a static library |
| and link it directly into Apache. Possible, but painful. Stick |
| with the shared library for now; if you can't, then ask. |
| |
| $ rm /usr/local/lib/libsvn* |
| |
| If you have old subversion libraries sitting on your system, |
| libtool will link them instead of the `fresh' ones in your tree. |
| Remove them before building subversion. |
| |
| $ make clean && make && make install |
| |
| After the make install, the Subversion shared libraries are in |
| /usr/local/lib/. mod_dav_svn.so should be installed in |
| /usr/local/libexec/ (or elsewhere, such as /usr/local/apache2/modules/, |
| if you passed --with-apache-libexecdir to configure). |
| |
| |
| Section II.C explains how to build the server on Windows. |
| |
| |
| C. Configuring Apache Httpd for Subversion |
| --------------------------------------- |
| |
| The following section is an abbreviated version of the |
| information in the Subversion Book |
| (https://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: |
| https://httpd.apache.org/docs-2.2/ |
| |
| First, your httpd.conf needs to load the mod_dav_svn module. |
| If you pass --enable-mod-activation to Subversion's configure, |
| 'make install' target should automatically add this line for you. |
| In any case, if Apache HTTPD 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: |
| |
| <Location /svn/repos> |
| DAV svn |
| SVNPath /absolute/path/to/repository |
| </Location> |
| |
| 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: |
| |
| <LimitExcept GET PROPFIND OPTIONS REPORT> |
| Require valid-user |
| </LimitExcept> |
| |
| c) For separate restricted read and write access: |
| |
| AuthGroupFile /my/svn/group/file |
| |
| <LimitExcept GET PROPFIND OPTIONS REPORT> |
| Require group svn_committers |
| </LimitExcept> |
| |
| <Limit GET PROPFIND OPTIONS REPORT> |
| Require group svn_committers |
| Require group svn_readers |
| </Limit> |
| |
| ### FIXME Tutorials section refers to old 2.0 docs |
| 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: |
| https://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: https://httpd.apache.org/docs-2.2/mod/directives.html. |
| |
| NOTE: Make sure that the user 'nobody' (or whatever UID the |
| httpd process runs as) has permission to read and write the |
| Berkeley DB files! This is a very common problem. |
| |
| |
| D. Running and Testing |
| ------------------- |
| |
| Fire up apache 2: |
| |
| $ /usr/local/apache2/bin/apachectl stop |
| $ /usr/local/apache2/bin/apachectl start |
| |
| Check /usr/local/apache2/logs/error_log to make sure it started |
| up okay. |
| |
| Try doing a network checkout from the repository: |
| |
| $ svn co http://localhost/svn/repos wc |
| |
| The most common reason this might fail is permission problems |
| reading the repository db files. If the checkout fails, make |
| sure that the httpd process has permission to read and write to |
| the repository. You can see all of mod_dav_svn's complaints in |
| the Apache error logfile, /usr/local/apache2/logs/error_log. |
| |
| To run the regression test suite for networked Subversion, see |
| the instructions in subversion/tests/cmdline/README. |
| For advice about tracing problems, see "Debugging the server" in |
| https://subversion.apache.org/docs/community-guide/. |
| |
| |
| E. Alternative: 'svnserve' and ra_svn |
| ----------------------------------- |
| |
| An alternative network layer is libsvn_ra_svn (on the client |
| side) and the 'svnserve' process on the server. This is a |
| simple network layer that speaks a custom protocol over plain |
| TCP (documented in libsvn_ra_svn/protocol): |
| |
| $ svnserve -d # becomes a background daemon |
| $ svn checkout svn://localhost/usr/local/svn/repository |
| |
| You can use the "-r" option to svnserve to set a logical root |
| for repositories, and the "-R" option to restrict connections to |
| read-only access. ("Read-only" is a logical term here; svnserve |
| still needs write access to the database in this mode, but will |
| not allow commits or revprop changes.) |
| |
| 'svnserve' has built-in CRAM-MD5 authentication (so you can use |
| non-system accounts), and can also be tunneled over SSH (so you |
| can use existing system accounts). It's also capable of using |
| Cyrus SASL if libsasl2 is detected at ./configure time. Please |
| read chapter 6 in the Subversion Book |
| (https://svnbook.red-bean.com) for details on these features. |
| |
| |
| |
| IV. PROGRAMMING LANGUAGE BINDINGS (PYTHON, PERL, RUBY, JAVA) |
| ======================================================== |
| |
| For Python, Perl and Ruby bindings, see the file |
| |
| ./subversion/bindings/swig/INSTALL |
| |
| For Java bindings, see the file |
| |
| ./subversion/bindings/javahl/README |
| |
| |
| |
| V. 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. |
| |
| The easiest way to install dependencies is via your operating system's |
| package management system. |
| |
| 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.A.2 before installing the following. |
| |
| |
| 1. Apache Portable Runtime and APR-util (REQUIRED) |
| |
| Subversion requires APR 1.4 or later and APR-util 1.3 or |
| later. |
| |
| Whenever you want to build any part of Subversion, you need the |
| Apache Portable Runtime (APR) and the APR Utility (APR-util) |
| libraries. |
| |
| 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. |
| |
| If you do not have a pre-installed APR and APR-util, you will need |
| to get these yourself: |
| |
| https://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 ... |
| |
| Notes on Windows platforms: |
| |
| * Do not use APR version 1.7.3 as that release contains a bug that |
| makes it impossible for Subversion to use it properly. This issue |
| only affects APR builds on Windows. This issue was fixed in APR |
| version 1.7.4. See: |
| https://lists.apache.org/thread/xd5t922jvb9423ph4j84rsp5fxks1k0z |
| |
| * If you check out APR and APR-util sources from their Subversion |
| repository, 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. Expat (REQUIRED for client and server) |
| |
| Subversion uses the Expat library for XML parsing. |
| |
| |
| 3. SQLite (REQUIRED) |
| |
| Subversion requires SQLite 3.24.0 or later. |
| |
| Subversion uses SQLite to manage some internal databases. 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. The amalgamation can be obtained |
| from the official SQLite website: |
| |
| https://www.sqlite.org/download.html |
| |
| |
| 4. Zlib (REQUIRED) |
| |
| 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. |
| |
| Most Unix systems have zlib pre-installed, but if you need it, you can |
| get it from |
| |
| http://www.zlib.net/ |
| |
| |
| 5. LZ4 (REQUIRED) |
| |
| Subversion requires LZ4 version r129 or later. |
| |
| Subversion uses the LZ4 library for compression. Configure will attempt |
| to locate the system library by default using pkg-config and known paths. |
| |
| If it is installed in a non-standard location, then use: |
| |
| --with-lz4=/path/to/liblz4 |
| |
| If configure should use the version bundled with the sources, use: |
| |
| --with-lz4=internal |
| |
| |
| 6. utf8proc (REQUIRED) |
| |
| Subversion uses utf8proc for UTF-8 support, including Unicode |
| normalization. |
| |
| Configure will attempt to locate utf8proc by default using pkg-config and |
| known paths. |
| |
| If it is installed in a non-standard location, then use: |
| |
| --with-utf8proc=/path/to/libutf8proc |
| |
| Alternatively, a copy of utf8proc comes bundled with the |
| Subversion sources. If configure should use the bundled copy, |
| use: |
| |
| --with-utf8proc=internal |
| |
| |
| 7. autoconf (Unix only) |
| |
| The minimum supported version is 2.59. |
| |
| This is required only if you plan to build from the latest source |
| (see section II.A.2). Generally only developers would be doing this. |
| |
| |
| 8. libtool (Unix only) |
| |
| The minimum supported version is 2.0. |
| |
| This is required only if you plan to build from the latest source |
| (see section II.A.2). |
| |
| |
| 9. Apache Serf library (OPTIONAL) |
| |
| The minimum supported version is 1.3.4. |
| |
| If you want your client to be able to speak to an Apache |
| server (via a http:// or https:// URL), you must link against |
| Apache Serf. Though optional, we strongly recommend this. |
| |
| Apache Serf uses OpenSSL for the encrypted https:// communication. |
| |
| In order to use ra_serf, you must install serf. Configure will |
| attempt to locate libserf by default using pkg-config. |
| |
| If you don't use pkg-config and serf is installed in a non-standard |
| location, then use: |
| |
| --with-serf=/path/to/serf/install |
| |
| Apache Serf can be obtained via your system's package distribution |
| system or directly from https://serf.apache.org/. |
| |
| |
| 10. 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: |
| |
| https://www.cyrusimap.org/sasl/ |
| |
| |
| 11. Apache Web Server (OPTIONAL) |
| |
| (https://httpd.apache.org/download.cgi) |
| |
| The minimum supported version is 2.2. |
| |
| 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. |
| |
| |
| 12. Python (https://www.python.org/) (OPTIONAL) |
| |
| Python version 3.x is supported and recommended. Support for Python 2.7 |
| is being phased out. |
| |
| Subversion does not require Python for its basic operation. |
| However, Python is required for building and testing Subversion |
| and for using Subversion's SWIG Python bindings or hook scripts |
| coded in Python. |
| |
| The majority of Subversion's test suite is written in Python, as |
| is part of Subversion's build system. |
| |
| In more detail, Python is required to do any of the following: |
| |
| * Use the SWIG Python bindings. |
| * Use hook scripts coded in Python. |
| * Build Subversion from a tarball on Unix-like systems and run |
| Subversion's test suite as described in section II.D. |
| * Build Subversion on Windows as described in section II.C. |
| * Build Subversion from a working copy checked out from |
| Subversion's own repository (whether or not running the test |
| suite). |
| * Build the SWIG Python bindings. |
| * Testing as described in section III.D. |
| |
| The Python bindings are used by: |
| |
| * Third-party programs (e.g., ViewVC) |
| * Scripts distributed with Subversion itself in the tools/ |
| subdirectory. |
| * Any in-house scripts you may have. |
| |
| Python is NOT required to do any of the following: |
| |
| * Use the core command-line binaries (svn, svnadmin, svnsync, |
| etc.) |
| * Use Subversion's C libraries. |
| * Use any of Subversion's other language bindings. |
| * Build Subversion from a tarball on Unix-like systems without |
| running Subversion's test suite |
| |
| Although this section calls for Python 3.x, Subversion still |
| technically works with Python 2.7. However, Support for Python |
| 2.7 is being phased out. As of 1 January 2020, Python 2.7 has |
| reached end of life. All users are strongly encouraged to move |
| to Python 3. |
| |
| Note: If you are using a Subversion distribution tarball and want |
| to build the Python bindings for Python 2, you should rebuild |
| the build environment in non-release mode by running |
| 'sh autogen.sh' before running the ./configure script; see |
| section II.A.2 for more about autogen.sh. |
| |
| |
| 13. pkg-config (Unix only, OPTIONAL) |
| |
| Subversion uses pkg-config to find appropriate options used |
| at build time. |
| |
| |
| 14. 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. |
| |
| |
| 15. Qt 5 or 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. |
| |
| |
| 16. KDE 5 Framework libraries or KDELibs 4 (Unix only, OPTIONAL) |
| |
| Subversion contains optional support for storing passwords in KWallet. |
| Subversion will look for KF5Wallet, KF5CoreAddons, KF5I18n APIs by default, |
| and needs kf5-config to find them. The KDELibs 4 api is also supported. |
| 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 |
| |
| |
| 17. 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. |
| |
| |
| 18. 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`. |
| |
| |
| 19. libmagic (OPTIONAL) |
| |
| 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. |
| |
| 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 |
| |
| |
| 20. py3c (OPTIONAL) |
| |
| Subversion uses the Python 3 Compatibility Layer for C |
| Extensions (py3c) library when building the Python language |
| bindings. |
| |
| As py3c is a header-only library, it is needed only to build the |
| bindings, not to use them. |
| |
| Configure will attempt to locate py3c by default using |
| pkg-config and known paths. |
| |
| If it is installed in a non-standard location, then use: |
| |
| --with-py3c=/path/to/py3c/prefix |
| |
| The library can be downloaded from GitHub: |
| |
| https://github.com/encukou/py3c |
| |
| |
| 21. Berkeley DB (DEPRECATED, TO BE REMOVED IN THE FUTURE) |
| |
| Needed only for the deprecated BDB repository backend. Support for |
| BDB is planned to be removed completely in the future. |
| |
| The CMake build system does not support building with BDB. |
