[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Installing Subversion on Red Hat 9

From: S I <xiamak_at_hotmail.com>
Date: 2005-09-22 03:35:25 CEST

Subversion SUCKS! The 'Sub' in Subversion stands for below par, as in BAD

Run away now, while you can, don't install it. It's very hard to maintain,
buggy, crappy, bad design with impatient maintainers and bad writers who
can't write diddly. Some LOSER fell sleep after chapter 3. It's too late
for us, run and save yourself! Get Clearcase, Perforce, PVCS, VSS, or CVS
anything but subversion. The high volume of traffic on this newsgroup
should be a LOUD clue to anyone that so many people have unanswered
questions or problems. If the manuals were written eqlouently, most of us
would not have the need to be on here to ask questions and get snubbed.

Some folks just suck at reinventing the wheel. CVS is fine and does the job
but through word of mouth, Subversion has become another fad with fools
rushing in... God help us all!!

----Original Message Follows----
From: Kevin Slater <kevin.slater@gmail.com>
Reply-To: Kevin Slater <kevin.slater@gmail.com>
To: users@subversion.tigris.org
Subject: Re: Installing Subversion on Red Hat 9
Date: Wed, 21 Sep 2005 21:11:38 -0400
MIME-Version: 1.0
Received: from tigris.org ([]) by mc9-f31.hotmail.com with
Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Sep 2005 18:13:02 -0700
Received: (qmail 25960 invoked by uid 5000); 22 Sep 2005 01:11:39 -0000
Received: (qmail 25936 invoked from network); 22 Sep 2005 01:11:38 -0000
X-Message-Info: JGTYoYF78jFtPXsrlTc4rHU0wPyI3/BasBmqk6n7T3g=
Mailing-List: contact users-help@subversion.tigris.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
list-help: <mailto:users-help@subversion.tigris.org>
list-unsubscribe: <mailto:users-unsubscribe@subversion.tigris.org>
list-post: <mailto:users@subversion.tigris.org>
Delivered-To: mailing list users@subversion.tigris.org
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
References: <5E47282BEBB9CE4D9D2FF205A1E0BB88012F7FCB@bleriot.easa.local>
Return-Path: users-return-38845-xiamak=hotmail.com@subversion.tigris.org
X-OriginalArrivalTime: 22 Sep 2005 01:13:02.0145 (UTC)

Ok, from the download link on the Subversion website you can find packages
that will install just fine on Redhat 9. (At least they did for me.)

However, what's this about FSFS being preferred over BDB? Seems like the
reverse was true not long ago. Is there a compelling reason why FSFS is
better than BDB?


On 9/21/05, Goddard Lee <lee.goddard@easa.eu.int> wrote:
> I have subversion on a recentish RedHat, and had the same problems as you
> did.
> Do not use the latest SWIG - the docs lie, they do not support 1.3.24
> up, but do support 1.3.24. That'll solve your SWIG problem.
> BDB is a simillar story -- you probably have BDB 1 on RH, and the very
> latest DBD doesn't work with RH, so my advice is either ask me offlist to
> find the BDB version that works, or better still, use the FSFS, which is
> much nicer, everyone will agree.
> Good luck, get in touch if I can help.
> lee
> Lee Goddard
> Internet Application Development, European Aviation Safety Agency
> T: +49 221 89990 3221
> E: Lee.Goddard@EASA.EU.int
> -----Original Message-----
> *From:* Philip Radford [mailto:phil@chycor.com]
> *Sent:* Tuesday, September 20, 2005 5:28 PM
> *To:* users@subversion.tigris.org
> *Subject:* Installing Subversion on Red Hat 9
> Hi all,
> I have recently come across subversion for the use of controlling our
> development projects.
> I am attempting to install verson 1.2.3 on Red Hat 9 (Shrike) with
> limited success.
> I have untarred the source distribution, obtained berkeley db 4.3.28 and
> needed to locate swig 1.3.25 as it could not find that on the system.
> After the first configure, make and make install any utility that was run
> such as svn and svnadmin resulted in a 'segmentation fault' message being
> displayed.
> I then repeated the process making sure to note any errors. The
> following is an extract from the make install section.
> ------------------------------------
> Libraries have been installed in:
> /usr/local/lib
> If you ever happen to want to link against installed libraries
> in a given directory, LIBDIR, you must either use libtool, and
> specify the full pathname of the library, or use the `-LLIBDIR'
> flag during linking and do at least one of the following:
> - add LIBDIR to the `LD_LIBRARY_PATH' environment variable
> during execution
> - add LIBDIR to the `LD_RUN_PATH' environment variable
> during linking
> - use the `-Wl,--rpath -Wl,LIBDIR' linker flag
> - have your system administrator add LIBDIR to `/etc/ld.so.conf'
> See any operating system documentation about shared libraries for
> more information, such as the ld(1) and ld.so(8) manual pages.
> ----------------------------------------------------------------------
> cd subversion/libsvn_wc ; /bin/sh /usr/local/src/subversion-1.2.3/libtool
> --mode=install /usr/local/src/subversion-1.2.3/ac-helpers/install-sh -c
> libsvn_wc-1.la <http://1.la> /usr/local/lib/libsvn_wc-1.la <http://1.la>
> libtool: install: warning: relinking `libsvn_wc-1.la <http://1.la>'
> (cd /usr/local/src/subversion-1.2.3/subversion/libsvn_wc; /bin/sh
> /usr/local/src/subversion-1.2.3/libtool --tag=CC --silent --mode=relink
> gcc -g -O2 -g -O2 -pthread -DNEON_ZLIB -rpath /usr/local/lib -o
> 1.la <http://1.la> adm_crawler.lo adm_files.lo adm_ops.lo copy.lo diff.lo
> entries.lo lock.lo log.lo merge.lo props.lo questions.lo relocate.lo
> status.lo translate.lo update_editor.lo
> 1.la <http://1.la>
> 1.la <http://1.la> /usr/local/src/subversion-1.2.3/apr-util/libaprutil-
> 0.la <http://0.la> -lgdbm -ldb-4.0 -lexpat
> /apr/libapr-0.la <http://0.la> -lrt -lm -lcrypt -lnsl -lpthread -ldl )
> libtool: link: warning:
> `/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..//libgdbm.la' seems to
> moved
> libtool: link: warning:
> seems to be moved
> libtool: link: warning:
> `/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..//libexpat.la' seems to
> moved
> libtool: link: warning:
> `/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..//libgdbm.la' seems to
> moved
> libtool: link: warning:
> seems to be moved
> libtool: link: warning:
> `/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..//libexpat.la' seems to
> moved
> libtool: link: warning:
> `/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..//libgdbm.la' seems to
> moved
> libtool: link: warning:
> seems to be moved
> libtool: link: warning:
> `/usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../..//libexpat.la' seems to
> moved
> /usr/local/src/subversion-1.2.3/ac-helpers/install-sh -c .libs/libsvn_wc-
> 1.so.0.0.0T /usr/local/lib/libsvn_wc-1.so.0.0.0
> (cd /usr/local/lib && rm -f libsvn_wc-1.so.0 && ln -s
> 1.so.0)
> (cd /usr/local/lib && rm -f libsvn_wc-1.so && ln -s
> 1.so)
> /usr/local/src/subversion-1.2.3/ac-helpers/install-sh -c .libs/libsvn_wc-
> 1.lai /usr/local/lib/libsvn_wc-1.la <http://1.la>
> /usr/local/src/subversion-1.2.3/ac-helpers/install-sh -c .libs/libsvn_wc-
> 1.a /usr/local/lib/libsvn_wc-1.a
> ranlib /usr/local/lib/libsvn_wc-1.a
> chmod 644 /usr/local/lib/libsvn_wc-1.a
> PATH="$PATH:/sbin" ldconfig -n /usr/local/lib
> ------------------------------------
> I can only assume that this linking warning is the cause of subversion
> not compiling correctly and therefore not running.
> It seems to be that it is looking for libdb-4.0.la
<http://libdb-4.0.la>which is not on the system but I have supplied the path
to the latest
> berkeley db using the configure command :-
> ./configure --with-apr=/usr/local/apache
> --with-apr-util=/usr/local/apache -with-berkeley-db=/usr/local/src/db-
> 4.3.28 --with-swig=/usr/local
> I would be grateful for any advice or guidance in this matter.
> Regards
> Philip Radford.

-- "Thank God for Microsoft" - Linus Torvalds
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 22 03:37:13 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.