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

Re: [Issue 3596] 'hotcopy' of packed fsfs repos may corrupt target revprops.db

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 13 Apr 2010 16:31:28 +0100

"Hyrum K. Wright" <hyrum_wright_at_mail.utexas.edu> writes:

> On Tue, Apr 13, 2010 at 7:08 AM, Philip Martin <philip_at_codematters.co.uk>wrote:
>
>> > [We should normally be pretty liberal with not using too-new
>> > dependency versions, but since we've made it possible for users to
>> > compile SQLite directly into Subversion, I think we can reasonably
>> > make an exception in its case.]
>>
>> Can we do that for 1.6? Most distributions probably use the system
>> SQLite and it won't be new enough.
>
> I'd have to check, but I believe the "compile as part of Subversion"
> capability is present in 1.6.x.

I meant that distributions will be unhappy with a "fix" that requires
them to use an embedded sqlite. They will also be unhappy if we force
them to upgrade to a newer version of sqlite.

>> > The rep sharing cache is just a cache, and can be truncated or
>> > deleted without impact on the correctness of the system.
>>
>> That's a way to fix a corrupt hotcopy but I don't think it prevents
>> the corruption.
>
> What kind of corruption are we talking about? The file gets corrupted and
> isn't recognized by SQLite as a valid database? It sees the file is a valid
> database, but doesn't contain some rows? The data contained in the SQLite
> data is wrong?

One SQLite recommendation is a lock that excludes writers during the
copy (http://www.sqlite.org/backup.html). I think that means that
copies made while a write is in progress are undefined. The result
probably depends on the platform, the size of the database, the type
of disk caching and the phase of the moon.

-- 
Philip
Received on 2010-04-13 17:31:59 CEST

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