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

Re: eliminating sequential bottlenecks for huge commit and merge ops

From: Joe Schaefer <joe_schaefer_at_yahoo.com>
Date: Wed, 4 Jan 2012 16:56:49 -0800 (PST)

> From: Greg Stein <gstein_at_gmail.com>
>To: Joe Schaefer <joe_schaefer_at_yahoo.com>
>Cc: "dev_at_subversion.apache.org" <dev_at_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_at_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.
>> 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).


>> 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.
Received on 2012-01-05 01:57:26 CET

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