You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Philip Martin <ph...@wandisco.com> on 2010/04/14 16:43:57 UTC
Re: svn commit: r934008 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
philip@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.
--
Philip
Re: svn commit: r934008 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
Philip Martin wrote:
> philip@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.
The nature of a "hot copy" is generally such that the copied thing isn't
"unavailable" by most definitions thereof. Not sure that write-locking the
repository really counts as "hot". :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r934008 - /subversion/trunk/subversion/libsvn_subr/sqlite.c
Posted by Greg Stein <gs...@gmail.com>.
On Wed, Apr 14, 2010 at 12:43, Philip Martin <ph...@wandisco.com> wrote:
> philip@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