On Tue, Apr 13, 2010 at 7:08 AM, Philip Martin <philip_at_codematters.co.uk>wrote:
> [Lets move discussion to dev]
>
Heh. Good idea. :)
hwright_at_tigris.org writes:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3596
Summary: FSFS hotcopy doesn't handle SQLite databases properly, this
> affects the new revprop packing db and the 1.6 rep sharing db.
>
> > We can set the minimum required SQLite version such that the backup
> > API is available. Is it still experimental in more recent versions
> > of SQLite?
>
> Yes.
>
> > [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.
>
> > 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?
Answering these questions will help us know what we should do to recover
from this type of corruption (if it exists). Since 1.6.x does include the
rep sharing cache as part of hotcopy, one would think we would have heard
about this type of corruption, if it is actually a practical concern, rather
than a theoretical one.
-Hyrum
Received on 2010-04-13 16:40:08 CEST