[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.

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

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