Alien-SVN
view release on metacpan or search on metacpan
src/subversion/INSTALL view on Meta::CPAN
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)
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/libserf*
Start the process by running "autogen.sh":
$ sh ./autogen.sh
This script will make sure you have all the necessary components
available to build Subversion. If any are missing, you will be
told where to get them from. (See the '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.
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 SQLite amalgamation if required
$ chmod +x autogen.sh
$ ./autogen.sh
$ mkdir ../obj
$ cd ../obj
$ ../svn/configure [...with options as appropriate...]
$ make
puts the Subversion working copy in the directory svn and builds
it in a separate, parallel directory obj.
Why would you want to do this? Well there are a number of
reasons...
* You may prefer to avoid "polluting" the working copy with
files generated during the build.
* You may want to put the build directory and the working
( run in 0.612 second using v1.01-cache-2.11-cpan-63c85eba8c4 )