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

RE: Subversion vs multicore processors

From: Edward Ned Harvey <svn_at_nedharvey.com>
Date: Mon, 15 Nov 2010 21:23:12 -0500

> From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> >>>>> On RHEL4 / RHEL5, I find it ridiculously easy to build svn from
> > source.
> >>>>> Here is my build script:
> >>
> >> Has someone had specific problems with the rpmforge rpms? I've been
> >> using them on centos5 without any trouble,
> >
> > Neither rpmforge, nor epel has subversion>= 1.5 for rhel4.
> Umm, OK - we're way off topic now but I'd ask the same question about
> running rhel/centos4.x as I would about running subversion 1.4.x...

This has already been mentioned in this thread. I can't speak for anyone
else, but I personally support engineers and engineering tools. The
engineering tools are only supported on the latest 2 versions of
RHEL/centos. Of which, the latest one is perpetually unstable. So I run
RHEL4 as long as RHEL5 is the current release... But a few days ago RHEL6
was released, so now it's time to upgrade to RHEL5 and ditch RHEL4.

> There's nothing wrong with doing your own compile, but there are good
> reasons to use a distribution's package management tools as much as
> possible.

I fully agree. For the sake of simplicity in upgrades, knowing (or blindly
trusting) it was compiled by an expert, dependency checking, etc. Ability
to remove package if you want to. If there is an rpm out there that suits
your needs (except the collabnet one) I would normally recommend using it.
I fundamentally object to the collabnet one, because it has scripted
"useradd" as part of the rpm post-run scripts. This process is not
consistent or repeatable on different machines, nor is it necessary on my
machines. So after I was bitten by UID conflict, I had to script userdel as
a command to follow the rpm installation.
Received on 2010-11-16 03:24:00 CET

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.