谁能帮忙翻译一下有关svn安装方面的文章.(4)

szhu

11. serf

      serf is a library for HTTP and WebDAV which is an alternative to
      Neon for accessing Subversion repositories over http:// and
      https:// URLs.  serf is designed as an asynchronous library
      which can take advantage of HTTP pipelining, so ra_serf may be
      more efficient than the Neon-based ra_dav.  The serf library can
      be found at:

          http://code.google.com/p/serf/

      In order to use ra_serf instead of ra_dav, you must install
      ra_serf, and run Subversion's ./configure with the arguments
      --with-serf and --without-neon. (The latter isn't required if
      you don't actually have Neon.)  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.


      12. Libraries for our libraries

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

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

      On Unix systems, if you are building neon as part of the Subversion
      build process (as described in section I.4 above), you can pass flags
      to Subversion's "./configure", and they will be passed on to neon's
      "./configure".  You need OpenSSL installed on your system, and you
      must add "--with-ssl" as a "./configure" parameter.  If your OpenSSL
      installation is hard for Neon to find, you may need to use
      "--with-libs=/path/to/lib" in addition.  In particular, on Red Hat
      (but not Fedora Core) it is necessary to specify
      "--with-libs=/usr/kerberos" for OpenSSL to be found.  The zlib library
      is included in the Subversion dependencies package, but if you are compiling
      Neon from a different source you can also specify a path to the
      library using "--with-libs".  Consult the Neon documentation for more
      information on how to use these parameters and versions of libraries
      you need.

      Under Windows, you can specify the paths to these libraries by
      passing the options --with-zlib and --with-openssl to gen-make.py.

      You can also add support for these features to an Apache httpd server
      to be used for Subversion using the same support libraries.  The
      Subversion build system will not provide them, however.  You add them
      by specifying parameters to the "./configure" script of the Apache
      Server instead.

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

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

          http://www.openssl.org/

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

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

      Windows users should get the source for ZLib version 1.2 or later:

          http://www.zlib.net/zlib123.zip

      The Windows build scripts will compile the ZLib sources.


      13. 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.tigris.org/servlets/ProjectDocumentList

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

          $ ./configure
          $ make
          # make install

      You can also run the full test suite by running 'make check'.


      2.  Building from an RPM

      If you are using Linux (or any OS that can use RPM) then another
      possibility is to download the binary RPM from the
      http://summersoft.fay.ar.us/pub/subversion directory.

      Currently only Linux on the i386 platform is supported
      using this method.  You might also require additional RPMS
      (which can be found in the above mentioned directory) to use the
      subversion RPM depending on what packages you already have installed:

          subversion*.i386.rpm
          apache*.i386.rpm (Version 2.0.49 or greater)
          db*.i386.rpm     (Version 4.0.14 or greater; version 4.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.50 or later, but you do have a new enough autoconf
      available, then you can specify the correct one with the
      AUTOCONF variable.  (The AUTOHEADER variable is similar.)  This
      may be required on Debian GNU/Linux, where "autoconf" is
      actually a Perl script that attempts to guess which version is
      required -- because of the interaction between Subversion's and
      APR's configuration systems, the Perl script may get it wrong.
      So for example, you might need to do:

          $ AUTOCONF=autoconf2.50 sh ./autogen.sh

      Once you've prepared the working copy by running autogen.sh,
      just follow the usual configuration and build procedure:

          $ ./configure
          $ make
          # make install

      (Optionally, you might want to pass --enable-maintainer-mode to
      the ./configure script.  This enables debugging symbols in your
      binaries (among other things) and most Subversion developers use it.)

      Since the resulting binary depends on shared libraries, the
      destination library directory must be identified in your
      operating system's library search path. That is in either
      /etc/ld.so.conf or $LD_LIBRARY_PATH for Linux systems and in
      /etc/rc.conf for FreeBSD, followed by a run of the 'ldconfig'
      program. Check your system documentation for details. By
      identifying the destination directory, Subversion will be able
      to dynamically load repository access plugins.  If you try to do
      a checkout and see an error like:

      subversion/libsvn_ra/ra_loader.c:209: (apr_err=170000)
      svn: Unrecognized URL scheme 'http://svn.collab.net/repos/svn/trunk'

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

      Note that if you commonly build with the -jN option to make and
      have unpacked a dependency tarball into your checkout, 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