subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Schaefer <joe_schae...@yahoo.com>
Subject Re: eliminating sequential bottlenecks for huge commit and merge ops
Date Thu, 05 Jan 2012 00:56:49 GMT

>________________________________
> From: Greg Stein <gstein@gmail.com>
>To: Joe Schaefer <joe_schaefer@yahoo.com> 
>Cc: "dev@subversion.apache.org" <dev@subversion.apache.org> 
>Sent: Wednesday, January 4, 2012 7:54 PM
>Subject: Re: eliminating sequential bottlenecks for huge commit and merge ops
> 
>
>
>On Jan 4, 2012 7:20 PM, "Joe Schaefer" <joe_schaefer@yahoo.com> wrote:
>>...
>> They're using the ASF CMS to manage the www.openoffice.org website, which is full
>> of 10 years worth of accumulated legacy spanning 50 or so different natural languages.
>> The CMS is "too slow" during commits to template files or such which change
>> the generated html content of virtually every file on the site.
>Gotcha.
>>
>> There are 2 ways I could mitigate this issue with them if subversion isn't interested
>> in working on this use case:
>Not sure I'd quite characterize it that way, but more that it is kind of expected and
we'd have a hard time using threads to fix it. It is entirely possible that there are *other*
solutions besides threads to help with this problem.
>>
>> 1) convert the templating system to use SSI, which would eliminate most of the
>> sledgehammer type commits.
>>
>>
>> 2) deploy the CMS on an SSD backed system.
>>
>>
>> FWIW (2) is scheduled to happen in the not too distant future anyway,
>I'm gonna guess you'll have this done faster than our 1.8 release (some time H1 this year).


Yes.

>> and I personally
>> don't want to encourage the use of SSI with the CMS even for oddball situations
>> like this one.
>I think you really should switch to SSI. For a site this size, it is murder on *any* version
control system.


I've raised the suggestion with them.  We'll see where it leads.

Mime
View raw message