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

Re: svn commit: r934008 - /subversion/trunk/subversion/libsvn_subr/sqlite.c

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 14 Apr 2010 12:45:46 -0400

On Wed, Apr 14, 2010 at 12:43, Philip Martin <philip.martin_at_wandisco.com> wrote:
> philip_at_apache.org writes:
>
>> Author: philip
>> Date: Wed Apr 14 16:35:11 2010
>> New Revision: 934008
>>
>> URL: http://svn.apache.org/viewvc?rev=934008&view=rev
>> Log:
>> * subversion/libsvn_subr/sqlite.c
>>   (svn_sqlite__hotcopy): Use the SQLite backup interface if available.
>>
>> Modified:
>>     subversion/trunk/subversion/libsvn_subr/sqlite.c
>
> The backup method works but is measurably slower in my tests than than
> the plain copy under a lock; the benefit should be better concurrency.
>
> I don't know which is better: the faster hotcopy that blocks writers
> or the slower hotcopy that allows writers to progress?  At the moment
> it's a compile time decision based on the version of SQLite but that's
> not a good way to decide whether we should be using this feature.  I
> think it's too obscure to make it configurable on a per-repository
> basis so I don't really know what we should do.

To me, "hot copy" means that you are trying to continue operation.
Thus, the concurrency is needed.

I don't see that a hot copy needs to be blazing fast. Just concurrent.

Cheers,
-g
Received on 2010-04-14 18:46:17 CEST

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

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