Tarball conversion

1 files changed, 1521 insertions, 0 deletions

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