David Glasser wrote:
> On Nov 19, 2007 2:30 PM, <glasser@tigris.org> wrote:
>
>> In order to do this, we add a few new helper macros, and make sure to
>> always use sqlite3_prepare_v2 instead of sqlite3_prepare; the "v2"
>> version returns the precise error code from sqlite3_step instead of
>> just returning SQLITE3_ERROR.
>
> This seems to require SQLite 3.3.9.
>
> This is our current INSTALL section:
>
>
> 3. SQLite 3.x or newer (REQUIRED for client and server)
>
> SQLite is a lightweight, embeddable SQL library necessary to
> build any repository-related code.
>
> You can get sqlite 3.5.2 from:
>
> http://www.sqlite.org/sqlite-3.5.2.tar.gz
>
> You can build and install sqlite however you wish. However,
> you also have the option of unpacking the archive into the
> top of the Subversion source tree and renaming the resulting
> directory within the Subversion source code) from
> ./sqlite-3.5.2/ to ./sqlite/. Subversion will then build
> and install it for you.
>
> We are already using an AUTOVACUUM feature that requires 3.1.
>
> Do we know what the status of sqlite3 versions on various popular
> Linux packagers is?
>
> ... alternatively, we *could* just ship svn with the single-file
> (sqlite3.c/sqlite3.h) copy of the latest version of sqlite, and avoid
> making anybody ever have to deal with installing it. Given how much
> of a dependency-hog we already are, I'd kind of like this route.
It does seem that there are many versions of sqlite available and some have had
problems. Even 3.5.2 seems pretty fresh to me to base svn on.
But having a single file sqlite3 in svn would be nice. We would be certain of
the version that everybody is using and could use the latest features. If we do
run into problems with sqlite3, then we know everybody is using the same
version, which makes debugging easier.
However, with apr having sqlite3 support, how would this work if apr and svn
both link with sqlite3 with different versions? Maybe we should preprocess the
sqlite3 names we use with svn_.
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 19 22:46:20 2007