[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: Les Mikesell <lesmikesell_at_gmail.com>
Date: Fri, 12 Nov 2010 20:24:01 -0600

On 11/12/10 8:09 PM, Nico Kadel-Garcia wrote:
> On Fri, Nov 12, 2010 at 8:22 PM, Les Mikesell<lesmikesell_at_gmail.com> wrote:
>> On 11/12/10 6:11 PM, Dominic Lemire wrote:
>>> Hello,
>>> Does anyone know if a Subversion server can make use of multiple CPU cores
>>> to
>>> speed-up long operations? (not just simultaneous requests)
>>> I'm profiling my (dual core) server running subversion 1.4.2 (and trac
>>> wiki),
>>> and I realized the CPU usage often tops at 50% during big checkouts
>>> (probably
>>> using only 1 core).
>>> I would love to find options that would enable multithread in Subversion
>>> (even
>>> if it means I have to recompile apache, subversion and/or the kernel)
>> I'm not sure if it will make a difference in that respect, but if you are
>> looking to improve things why are you using such an old version?
> RHEL 5 still directly only provides Subversion 1.4.2. EPEL will not
> replace it in their "Fedora backported" repositories, and you have to
> reach out to RPMforge to get a reliable update or pull in the
> CollabNet version, which has an entirely different structure, no
> source code, and is frankly bloated for most casual use. (Commercial
> support can be nice, but most of us don't need that for Subversion.)
> RHEL 6, released a few days ago, is up to 1.6.11, but it's awkward to
> backport due to various dependencies.

The rpmforge version works - but because of other incompatibilities I generally
keep the the repo disabled in yum and explicitly:
yum --enablerepo=rpmforge update subversion mod_dav_svn viewvc (etc.)
when I want to use it for specific packages.

    Les Mikesell
Received on 2010-11-13 03:24:49 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.