"Hyrum K. Wright" <hyrum_wri...@mail.utexas.edu> writes: > On Tue, Apr 13, 2010 at 7:08 AM, Philip Martin > <phi...@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
