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

Re: [PATCH] Make SQLite compatibility check less picky

From: Jonathan Nieder <jrnieder_at_gmail.com>
Date: Sat, 29 Oct 2011 07:18:54 -0500

Stefan Sperling wrote:
> On Sat, Oct 29, 2011 at 06:45:50AM -0500, Jonathan Nieder wrote:

>> [[[
>> The actual ABI compatibility of sqlite3 doesn't depend on the patchlevel
>> (the x in 3.7.x), so stop being picky about the patchlevel when checking
>> the version number at runtime. This avoids spurious errors of the form
>> "svn: Couldn't perform atomic initialization" / "svn: SQLite compiled
>> for 3.7.4, but running with 3.7.3" when sqlite gets a minor update
>> without Subversion being rebuilt to match.
> Shouldn't the version numbers in your example be the other way around?

No, my description was just bogus. This is not about when sqlite gets
a minor update, but rather when either

 A. sqlite gets downgraded in a minor way, or, more likely,
 B. subversion is installed using pre-built binaries that were built
    against a slightly newer version of sqlite.

>> --- subversion/libsvn_subr/sqlite.c (revision 1194866)
>> +++ subversion/libsvn_subr/sqlite.c (working copy)
>> @@ -606,7 +606,7 @@ static volatile svn_atomic_t sqlite_init_state = 0
>> static svn_error_t *
>> init_sqlite(void *baton, apr_pool_t *pool)
>> {
>> - if (sqlite3_libversion_number() < SQLITE_VERSION_NUMBER)
>> + if (sqlite3_libversion_number()/1000 < SQLITE_VERSION_NUMBER/1000)

This test was already a '<' rather than '!=' so minor sqlite updates
were already handled fine.

Thanks for the sanity check. I'll sleep on this for now, planning to
resend with a new log message and some other tweaks tomorrow.
Received on 2011-10-29 14:19:38 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.