You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@davidglasser.net> on 2007/11/19 21:33:47 UTC
Re: svn commit: r27922 - in trunk: . subversion/include subversion/libsvn_fs_util
On Nov 19, 2007 2:30 PM, <gl...@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.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r27922 - in trunk: . subversion/include subversion/libsvn_fs_util
Posted by Blair Zajac <bl...@orcaware.com>.
David Glasser wrote:
> On Nov 19, 2007 2:30 PM, <gl...@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
Re: svn commit: r27922 - in trunk: . subversion/include subversion/libsvn_fs_util
Posted by Philip Martin <ph...@codematters.co.uk>.
"David Glasser" <gl...@davidglasser.net> writes:
> On Nov 20, 2007 9:46 AM, Philip Martin <ph...@codematters.co.uk> wrote:
>>
>> Debian Etch (the stable distribution) comes with 3.3.8, so Subversion
>> no longer builds on my machine :(
>
> Out of curiosity, is the Etch sqlite threadsafe? ie
>
> #include <sqlite3.h>
>
> int main(int argc,char** argv) { printf("%d\n", sqlite3_threadsafe()); }
$ gcc z.c -lsqlite3
z.c: In function ‘main’:
z.c:3: warning: incompatible implicit declaration of built-in function ‘printf’
/tmp/cccyNuPh.o: In function `main':
z.c:(.text+0x15): undefined reference to `sqlite3_threadsafe'
collect2: ld returned 1 exit status
According to the build log
http://buildd.debian.org/fetch.cgi?&pkg=sqlite3&ver=3.3.8-1.1&arch=amd64&stamp=1173183620&file=log
it is configured using --enable-threadsafe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r27922 - in trunk: . subversion/include subversion/libsvn_fs_util
Posted by David Glasser <gl...@davidglasser.net>.
On Nov 20, 2007 9:46 AM, Philip Martin <ph...@codematters.co.uk> wrote:
> "David Glasser" <gl...@davidglasser.net> writes:
>
> > On Nov 19, 2007 2:30 PM, <gl...@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.
>
> > 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?
>
> Debian Etch (the stable distribution) comes with 3.3.8, so Subversion
> no longer builds on my machine :(
Out of curiosity, is the Etch sqlite threadsafe? ie
#include <sqlite3.h>
int main(int argc,char** argv) { printf("%d\n", sqlite3_threadsafe()); }
> > ... 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.
>
> Distributions will probably want to build against a system sqlite as
> an embedded version makes security support harder.
Yeah, that is probably true.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r27922 - in trunk: . subversion/include subversion/libsvn_fs_util
Posted by Philip Martin <ph...@codematters.co.uk>.
"David Glasser" <gl...@davidglasser.net> writes:
> On Nov 19, 2007 2:30 PM, <gl...@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.
> 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?
Debian Etch (the stable distribution) comes with 3.3.8, so Subversion
no longer builds on my machine :(
> ... 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.
Distributions will probably want to build against a system sqlite as
an embedded version makes security support harder.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r27922 - in trunk: . subversion/include subversion/libsvn_fs_util
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
David Glasser wrote:
> On Nov 19, 2007 2:30 PM, <gl...@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?
My Ubuntu Gutsy install is running 3.4.2. 3.3.9 was released on Jan 4,
2007. My feeling is that most distributions will be shipping at least
3.3.9 (and probably some variant of 3.4 or 3.5) by the time they are
also including Subversion 1.5.
> ... 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.
>
> --dave
>