               ======================================
                      INSTALLING SUBVERSION
                          A Quick Guide
               ======================================

$LastChangedDate$

   *** Note: Subversion is PRE-ALPHA code.  Don't use it on real data. ***

Contents:

     I. BUILD REQUIREMENTS

    II. INSTALLATION
     A. Bootstrapping from a Tarball or RPM
     B. Building the Latest Source under Unix
     C. Building under Unix in Different Directories
     D. Bootstrapping from a Zip 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


I.    BUILD REQUIREMENTS
      ==================

      Subversion depends on a number of third party tools and libraries.
      If you are bootstrapping from a tarball, zipfile or an RPM then
      you will already have everything you require to get a Subversion
      client.  So long as you don't plan to build a new client from the
      latest source or to build a Subversion server, you can go directly
      to section II.A.

      Otherwise, you need to read the following so that you can determine
      what other tools and libraries will be required so that Subversion
      can be built with the set of features you want.

      On Unix systems, the './configure' script will tell you if you are
      missing the correct version of any of the required libraries or
      tools, so if you are in a real hurry to get building, you can skip
      straight to section II.  If you want to gather the pieces you will
      need before starting out, however, you should read the following.

      Note: Because previous builds of Subversion may have installed older
      versions of these libraries, you may want to run some of the cleanup
      commands described in section II.B before installing the following.

      1.  Apache Portable Runtime

      Whenever you want to build any part of Subversion, you need the
      Apache Portable Runtime (APR) and the APR Utility (APRUTIL)
      libraries. At the time of this writing, there were no official
      release versions of APR/APRUTIL available.

      If you want Subversion to build the APR libraries from source code
      as part of the Subversion build process, you can put their source
      code into the "./apr" and "./apr-util" directories. The Subversion
      tarball comes with copies of the libraries' source code stored in
      these subdirectories which you could copy or link to. To be safe,
      however, you should check out the latest version from the Apache CVS
      repository, since the latest Subversion may well rely on the latest
      changes to APR and APRUTIL.

      You can get the latest version of APR and APRUTIL with the following
      two commands. If you run them from the directory where you've
      checked out Subversion, then the APR source code will be in "./apr"
      and "./apr-util", where Subversion wants it:

          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
          (password: 'anoncvs')

          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr
          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr-util

      If you already have the APR libraries compiled and do not wish to
      regenerate it from source code, then Subversion needs to be
      able to find it.

      There are a couple of options for Subversion to find where the APR
      libraries are. By default, it will look for and use the apr-config
      and apu-config scripts. These scripts provide all the relevant
      information for the APR and APRUTIL installations.

      If you want to specify the location of the APR library, you can use
      the "--with-apr=" option of "./configure". It should be able to find
      the apr-config script in the standard location under that directory
      (e.g. ${prefix}/bin).

      Similar, you can specify the location of APRUTIL using the
      "--with-apr-util=" option to "./configure". It will look for the
      apu-config script relative to that directory.

      For example, if you wanted to use the APR libraries you had built
      with the Apache HTTP 2.0 server, you could run:

          $ ./configure --with-apr=/usr/local/apache2 \
            --with-apr-util=/usr/local/apache2  ...


      2.  autoconf 2.50 or newer (Unix only)

      This is required only if you plan to build from the latest source
      (See section II.B). Generally only developers would be doing this,
      but at this stage in Subversion's development chances are you'll
      want to do this as well.


      3.  libtool 1.4 or newer (Unix only)

      This is required only if you plan to build from the latest source
      (See section II.B), which you probably want to do. See above.


      4.  bison or yacc (Unix only)

      This is required only if you plan to build from the latest source
      (See section II.B), which you probably want to do. See above.

      The reason one of these programs is required is that it will
      generate the code which parses complex date formats, so that
      Subversion can work with dates like "yesterday" and "last month"
      and "four hours ago". Note that most modern Unices come with one
      or the other of these programs, and only one is required.

      The reason you don't need one of these programs on a Windows
      platform is that the date parsing file has been pregenerated
      and will automatically be copied into place by the Windows
      Build.


      5.  Neon library 0.19.[2-3]

      The Neon library allows a Subversion client to interact with remote
      repositories over the Internet. Although in theory you could have
      the client interact only with local repositories, currently the
      build system requires Neon to be present. Hopefully, this will be
      fixed in the future.

      The Neon library source code can be installed in "./neon" if you
      want Subversion to build it. The source code is included with the
      latest Subversion tarball, and it can also be obtained from:

          http://www.webdav.org/neon/neon-0.19.3.tar.gz

      Unpack the archive using tar/gunzip and rename the resulting
      directory from "./neon-0.19.3/" to "./neon/".

      Without source code, a previously compiled library can be picked up
      from the standard locations. If you want to specify a nonstandard
      location, you need to use the LDFLAGS environmental variable when
      you run "./configure". You may also have to specify where the
      neon-config script (which identifies various features of the Neon
      library) is kept by giving the "--with-neon=" option to
      "./configure". Note that the script should be kept in a "bin"
      subdirectory beneath whereever "--with-neon" is pointed.


      6.  Berkeley DB 4.0.14

      Berkeley DB is needed to build a Subversion server, or to access
      a repository on local disk.  If you are only interested in
      building a Subversion client that speaks to a remote (networked)
      repository, you don't need it.

      You'll need Berkeley DB 4.0.14 installed on your system.  You can
      get it from:

          http://www.sleepycat.com/.

      If you already have another version of Berkeley DB installed and
      don't want to downgrade, you can unpack the Berkeley 4.0.14
      distribution into a subdir named `db' in the top-level of the
      Subversion source tree.  Then Subversion will ignore the system
      DB and use the one it found in its own source tree.

      Alternatively, you can add this flag

          --with-berkeley-db=/usr/local/BerkeleyDB.4.0

      to your `configure' switches, and the build process will use the
      Berkeley library in the named directory.  You may need to use a
      different path, of course.

      If you are on the Windows platform and want to build Subversion,
      a precompiled version of the Berkeley DB library is available for
      download at the Subversion web site:

          http://subversion.tigris.org/servlets/ProjectDownloadList


      7.  Apache Web Server 2.0.31 or newer

      The Apache HTTP server is required if you wish to offer your
      Subversion repository over the Internet. Building Subversion, the
      Apache server, and the modules that Apache needs to communicate
      with Subversion are complicated enough that there is a whole
      section at the end of this document that describes how it is
      done. See section III for details.


      8.  Python 2.0

      If you want to run "make check" or build from the latest source
      under Unix as described in section II.B, install Python 2.0 or
      higher on your system. The majority of the test suite is written
      in Python, as is part of Subversion's build system.  Get it from
      http://www.python.org/.


      9.  Visual C++ 6.0 or newer (Windows Only)

      To build Subversion under any of the MS Windows platforms, you
      will need a copy of Microsoft Visual C++. The project files are
      provided for you.


      10. A gnu-like diff and patch

      Many of the features of the Subversion client require the ability
      to call out to an external diff or patch program, one that
      conforms to the behaviour of the GNU versions of these programs.

      On some versions of Unix, this may involve getting a replacement
      for your already existing diff and patch program. On FreeBSD
      systems, for example, it requires getting gdiff and gpatch.

      On a Windows platform, Subversion also requires a GNU diff.exe
      and patch.exe. One implementation is provided by the Cygwin
      project:

          http://sources.redhat.com/cygwin

      Note that the diff.exe and patch.exe must be installed into the
      "C:\Program Files\cygnus\cygwin\bin" directory in order for
      Subversion to find them at this time. If you have Cygwin
      installed somewhere else, you should create this directory
      path and copy those two files to it. You'll also need to copy
      the cygwin1.dll file into the same directory.


      11. Libraries for our libraries

      Some of the libraries that Subversion depends on themselves have
      optional dependencies that can add features to what Subversion
      can do.  Here are some examples.

      The Neon library has support for SSL encryption by relying on the
      OpenSSL library.  When Neon is created with this dependency, then
      the Subversion client inherits the ability to support SSL
      connections.  Neon also has support for sending compressed data
      using the zlib library which a Subversion client can take
      advantage of.

      With Unix-based systems, you can enable support for SSL from the
      Subversion build provided that you are building Neon in the
      "./neon/" directory as described above in section I.5.  You also
      need OpenSSL installed on your system.  Just add "--with-ssl" as
      a parameter when you run Subversion's "./configure", and it will
      be passed on to the Neon build system.  If your OpenSSL
      installation is hard for Neon to find, you may need to use
      "--with-ssl=/path/to/lib" instead.  The zlib library is included
      in Neon by default, but you can also specify a path to the
      library using "--with-zlib".  Consult the Neon documentation for
      more information on how to use these parameters and versions of
      libraries you need.

      Under Windows, you have to edit a batch file available in your
      Subversion source tree (the root of which is labelled <SVN>
      below):

          <SVN>\build\win32\build_neon.bat

      and point it to the appropriate directories.

      You can also add support for these features to a Subversion server
      and you can even use the same support libraries.  The Subversion
      build system will not provide them, however.  You add them by
      specifying parameters to the "./configure" script of the Apache
      Server instead.

      For getting SSL on your server, you would add the "--enable-ssl"
      or "--with-ssl=/path/to/lib" option to Apache's "./configure"
      script.  Apache enables zlib support by default, but you can
      specify a nonstandard location for the library with the
      "--with-z=/path/to/dir" option.  Consult the Apache documentation
      for more details, and for other modules you may wish to install
      to enhance your Subversion server.

      If you don't already have it, you can get a copy of OpenSSL,
      including instructions for building and packaging on both Unix
      systems and Windows, at:

          http://www.openssl.org/

      Many Unix systems already come with zlib, but if you need it it
      is available from:

          http://www.gzip.org/zlib/

      Windows users should just get the pre-built package:

          http://www.gzip.org/zlib/contrib/zlib113-win32.zip

      The neon build scripts on Windows are set up to use those
      libraries.


II.   INSTALLATION
      ============

  A.  Bootstrapping from a Tarball or RPM
      -----------------------------------

      In order to get the very latest Subversion source code, you need
      to check it out of a Subversion repository, and therefore you
      first need a Subversion client.


      1.  Boostrapping from a Tarball

      Download the most recent distribution tarball from:

          http://subversion.tigris.org/servlets/ProjectDownloadList

      Unpack it, and use the standard GNU procedure to compile:

          $ ./configure --enable-maintainer-mode --disable-shared
          $ make

      (The first switch to ./configure turns on debugging, and the
       second switch builds a statically-linked client binary.)

      After compiling, you will have a large 'svn' binary sitting in
      the tree.  Use it to check out a real Subversion working copy:

          $ subversion-rXXXX/subversion/clients/cmdline/svn checkout \
            http://svn.collab.net/repos/svn/trunk -d svn

          A  svn/dist.sh
          A  svn/buildcheck.sh
          A  svn/HACKING
          ...


      2.  Bootstrapping 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/linux/RPMS/i386 or
      http://summersoft.fay.ar.us/pub/linux/RPMS/ppc directory.

      Currently only Linux on the i386 and ppc platforms are 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.32 or greater)
          db*.i386.rpm     (Version 4.0.14 or greater)
          expat            (Comes with RedHat)
          neon             (Version 0.19.[2-3])

      After downloading, install it (as root user):

          # rpm -ivh subversion*.386.rpm (add other packages as necessary)

      After installing, you can then use the svn command to check out the
      latest source code:

          $ /usr/bin/svn checkout http://svn.collab.net/repos/svn/trunk -d svn
          A  svn/dist.sh
          A  svn/buildcheck.sh
          A  svn/HACKING
          ...

      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 Subversion working copy.  See the section
      "Bootstrapping From A Tarball Or RPM" above for more.)

      You can discard the directory created by the tarball; you're
      about to build the latest, greatest Subversion client.

      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.)

      After all components are in place, follow the usual procedure:

          $ ./configure --enable-maintainer-mode --disable-shared
          $ make
          $ make check    (optional)
          # make install

      The flags to `configure' are highly recommended for developers,
      as they build a statically-linked binary.  If you don't use
      those flags, then you must reverse the order of the "make check"
      and "make install" steps, because the shared libraries must be
      installed before "make check" will work.

      Additionally, with shared library builds, 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:

      svn_error: #21068 : <Bad URL passed to RA layer>
         Unrecognized URL scheme: http://svn.collab.net/repos/svn/trunk

      It probably means that the dynamic loader/linker can't find all
      of the libsvn_* libraries.

      Note that if you commonly build with the -jN option to make, the
      make step above may fail, because we don't ensure that third
      party libraries in our source tree will finish building before
      subversion itself.  If you want to use -jN, use the following
      instead:

          $ ./configure --enable-maintainer-mode --disable-shared
          $ make -jN external-all
          $ make -jN local-all
          $ make check
          # make install


  C.  Building under Unix in Different Directories
      --------------------------------------------

      It is possible to configure and build Subversion on Unix in a
      directory other than the working copy. For example

          $ svn co http://svn.collab.net/repos/svn/trunk -d svn
          $ cd svn
          $ # get neon/db/apr as required
          $ chmod +x autogen.sh
          $ ./autogen.sh
          $ mkdir ../obj
          $ cd ../obj
          $ ../svn/configure [...with options as appropriate...]
          $ make

      puts the Subversion working copy in the directory svn and builds
      it in a separate, parallel directory obj.

      Why would you want to do this? Well there are a number of
      reasons...

          *  You may prefer to avoid "polluting" the working copy with
             files generated during the build.

          *  You may want to put the build directory and the working
             copy on different physical disks to improve performance.

          *  You may want to separate source and object code and only
             backup the source.

          *  You may want to remote mount the working copy on multiple
             machines, and build for different machines from the same
             working copy.

          *  You may want to build multiple configurations from the
             same working copy.

      The last reason above is possibly the most useful.  For instance
      you can have separate debug and optimised builds each using the
      same working copy. Or you may want a client only build and a
      client-server build. Using multiple build directories you can
      rebuild any or all configurations after an edit without the need
      to either clean and reconfigure, or identify and copy changes
      into a another working copy.


  D.  Bootstrapping from a Zip File under Windows
      -------------------------------------------

      Of all the ways of getting a Subversion client, this is the
      easiest. Just download the 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.

      Now open a DOS box (run either "cmd" or "command" from the
      Start menu's "Run..." menu option), change to the directory you
      installed the executables into, and run:

          C:\test>svn co http://svn.collab.net/repos/svn/trunk -d svn

      This will get the latest Subversion sources and put them into the
      "svn" subdirectory.

      If you want to use this client for more than just downloading
      the latest sources, though, you will probably need to make sure
      that Subversion has access to the diff.exe and patch.exe
      programs, as described in section I.10.


  E.  Building the Latest Source under Windows
      ----------------------------------------

      (These instructions assume you have already installed Subversion
      and checked out a Subversion working copy.  See the section
      "Bootstrapping From A Zip File Under Windows" above for more.)

      There is some support for building Subversion on Win32 platforms.
      The project files included in the source tree are from Microsoft
      Visual C++ 6.x; earlier versions of the compiler are not
      supported at this time.

      To build the client components, you'll need a copy of neon
      0.19.[2-3].  See section I.5 for details on where to get one and
      what to do with it when you get it.

      [NOTE: The neon library supports secure connections with OpenSSL
          and on-the-wire compression with zlib. If you want to use
          those features, you should edit the file

              <SVN>\build\win32\build_neon.bat

          to point to the appropriate directories.

          See Section I.11 for more details.

      If you want to build the (local) server components, you'll also
      need a copy of Berkeley DB, version 4.0.14 or newer.  Details are
      in Section I.6. For your convenience, there is also a binary
      distibution on the Subversion downloads page

          http://subversion.tigris.org/ProjectDownloadList

      The file there is named

          db-4.0.14-win32.zip

      Unpack the distribution into the root directory of the Subversion
      source tree as <SVN>\db4-win32. It's a good idea to add
      <SVN>\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 list.]

      If you build Berkeley DB from the source, you will have to copy
      the file ..db-4.0.14\build_win32\db.h to <SVN>\db4-win32\include,
      and all the import libraries to <SVN>\db4-win32\lib. Again, the
      DLLs should be somewhere in your path.

      The workspace `subversion.dsw' at the top of the source tree
      includes all the necessary projects. Right now, only static
      libraries are built. The "__build__" project (active by default)
      builds all the libraries and programs. The "__check__" project
      builds the test drivers.

      You will have to edit the file svn_private_config.hw to set the
      correct paths for diff and patch.

      [NOTE: There have been rumours that Subversion on Win32 can be built
          using the latest cygwin. ymmv.]


III.  BUILDING A SUBVERSION SERVER
      ============================

  A.  Setting Up Apache
      -----------------

      (Following the BOOTSTRAPPING FROM RPM procedures above will install and
      build the latest Subversion server for Linux RedHat 7.1, 7.2, and PPC
      Linux systems *IF* the apache-devel-2.0.31 or greater package is already
      installed when the SUBVERSION RPM is built.)


      1.  Obtaining and Installing Apache 2.0

      Checkout the "httpd-2.0" cvs module from apache.org.  If you have
      questions about the Apache 2.0 build, please consult the HTTPD
      install documentation: http://httpd.apache.org/docs-2.0/install.html
      Place this module wherever you wish; it's an independent project.

          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic login
          (password 'anoncvs')

          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co httpd-2.0

      Checkout the "apr" and "apr-util" modules into the srclib/ directory:

          $ cd httpd-2.0/srclib
          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr
          $ cvs -d :pserver:anoncvs@cvs.apache.org:/home/cvspublic co apr-util

      At the top of the httpd-2.0 tree:

          $ ./buildconf
          $ ./configure --enable-dav --enable-so --prefix=/usr/local/apache2

      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 is where you will ultimately install apache.

      Note: if you build Subversion with --enable-maintainer-mode,
      then do the same for Apache. mod_dav_svn uses Apache's
      maintainer-mode stuff from its headers, so you want to ensure
      that Apache is built with the same assumption. Just add
      --enable-maintainer-mode to the configure line above.

      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.0 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.0.14
      at its default locations.  For more info about the db requirement,
      see section I.6.

      You may also want to include other modules in your build. Add
      --enable-ssl to turn on SSL support, for example.  Consult the
      Apache documentation for more details.

      All instructions below assume you configured Apache to install
      under /usr/local/apache2/; substitute appropriately if you
      chose some other location.

      Compile and install apache:

          $ make depend && make && make install


  B.  Making and Installing the Subversion Server
      -------------------------------------------

      Go back into your subversion working copy and run ./autogen.sh if
      you need to.  Then run:

          $ ./configure --with-apxs=/usr/local/apache2/bin/apxs

      This argument tells subversion to build mod_dav_svn, and where to
      find the required information to do so.

      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.

      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/.  libmod_dav_svn.so should be installed in
      /usr/local/apache2/modules/.


      1.  Building the Server on Windows [EXPERIMENTAL]

      The mod_dav_svn module can now be built on Windows, using the
      mod_dav_svn project in the workspace `subversion.dsw'. You must
      have Apache source tree installed in parallel to the Subversion
      source tree, and will use the apr and apr-util libraries from
      the Apache sources; like this:

          .../
            svn/
              db4-win32/
              subversion/
                mod_dav_svn/
              ...
            httpd-2.0/
              srclib/
                apr/
                apr-util/
              ...

      You must have Berkeley DB available, as described in II.E.
      First, buld (and install) Apache and the Subversion client and
      local server. Then select mod_dav_svn as the active project,
      build it, and copy mod_dav_svn.so to the Apache modules
      directory. Apache configuration is the same as on Unix.


  C.  Configuring Apache for Subversion
      ---------------------------------

      The following assumes you have already created a repository.
      For documentation on how to do that, see README.

      Add this to the *bottom* of /usr/local/apache2/conf/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 seperate 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 contol, please consider taking a look at the
      tutorials found under the "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 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.

      NOTE: If you are unfamiliar with an Apache directive, or not exactly
      sure about what it does, don't hesitate to look it up in the
      documentation: http://httpd.apache.org/docs-2.0/mod/directives.html.

      NOTE: Make sure that the user 'nobody' (or whatever UID the
      httpd process runs as) has permission to read and write the
      Berkeley DB files!  This is a very common problem.


  D.  Running and Testing
      -------------------

      Fire up apache 2.0:

          $ /usr/local/apache2/bin/apachectl stop
          $ /usr/local/apache2/bin/apachectl start

      Check /usr/local/apache2/logs/error_log to make sure it started
      up okay.

      Try doing a network checkout from the repository:

          $ svn co http://localhost/svn/repos -d wc

      The most common reason this might fail is permission problems
      reading the repository db files.  If the checkout fails, chmod
      777 and try again.

      You can see all of mod_dav_svn's complaints in the Apache
      error logfile, /usr/local/apache2/logs/error_log.  For more
      information about tracing problems, see "Debugging the server"
      in the HACKING file.