monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Linking monotone with Debian's official sqlite shar


From: Matthew Gregan
Subject: Re: [Monotone-devel] Linking monotone with Debian's official sqlite shared library
Date: Mon, 25 Jul 2005 17:25:00 +1200
User-agent: Mutt/1.5.9i

At 2005-07-25T02:35:04+0200, Tomas Fasth wrote:
> My question to Andreas Rottmann is; Since sqlite version 3.2.2 is
> not yet uploaded to the Debian unstable archive, is it possible to
> incorporate the changes already made to the monotone version of the
> sqlite source files?

I don't think it makes a lot of sense to integrate these changes into
the Debian version of SQLite as well; it would create additional, less
localised divergence.

> My question to the monotone developers is; Can you please provide
> convincing arguments for each and every change made to the sqlite
> source files as presented in the attached diff?

See below.

> A followup question is; Do you intend to communicate your changes
> upstream to the authors of sqlite so it will show up in a future
> source release of sqlite?

Yes, it's just a matter of finding the time to do so.

> I would very much like to resolve this issue in such a way that I
> can begin to link monotone with the sqlite library as provided in
> Debian.

Please refer to Graydon's earlier email about Lua; similar arguments can
be made regarding QA, etc. for the rest of our bundled software.

It's also worth noting that the monotone developers do keep an eye on
the upstream sources of the bundled software, and integrate fixes and
new releases as is appropriate--it's not as if we are insisting on using
old, buggy, or known insecure versions of upstream projects.

> diff -u sqlite-3.2.2/src/main.c monotone/monotone-0.21/sqlite/main.c
> --- sqlite-3.2.2/src/main.c     2005-06-06 14:44:41.000000000 +0000
> +++ monotone/monotone-0.21/sqlite/main.c        2005-07-17 23:02:14.000000000 
> +0000
> @@ -298,7 +298,7 @@
>    sqlite3OsSleep(delay);
>    return 1;
>  #else
> -  int timeout = (int)Timeout;
> +  int timeout = ((sqlite3 *)ptr)->busyTimeout;
>    if( (count+1)*1000 > timeout ){
>      return 0;
>    }

This is a simple compile fix to the upstream source--it looks like
someone forgot to change the code inside one of the conditionals.  There
should be no problem integrating this upstream.

> diff -u sqlite-3.2.2/src/sqliteInt.h monotone/monotone-0.21/sqlite/sqliteInt.h
> --- sqlite-3.2.2/src/sqliteInt.h        2005-06-12 21:35:52.000000000 +0000
> +++ monotone/monotone-0.21/sqlite/sqliteInt.h   2005-07-17 23:02:14.000000000 
> +0000
> @@ -39,6 +39,7 @@
>  # define _LARGEFILE_SOURCE 1
>  #endif

> +#include "config.h"
>  #include "sqlite3.h"
>  #include "hash.h"
>  #include "parse.h"

This is to integrate the bundled SQLite into our build/configure system.

> diff -u sqlite-3.2.2/src/tokenize.c monotone/monotone-0.21/sqlite/tokenize.c
> --- sqlite-3.2.2/src/tokenize.c 2005-06-06 14:45:43.000000000 +0000
> +++ monotone/monotone-0.21/sqlite/tokenize.c    2005-07-17 23:02:14.000000000 
> +0000
> @@ -500,8 +500,14 @@
>  ** is look for a semicolon that is not part of an string or comment.
>  */
>  int sqlite3_complete(const char *zSql){
> +  const char *tmp;
> +  return sqlite3_complete_last(zSql, &tmp);
> +}
> +
> +int sqlite3_complete_last(const char *zSql, const char **last){
>    u8 state = 0;   /* Current state, using numbers defined in header comment 
> */
>    u8 token;       /* Value of the next token */
> +  const char* lastseen = 0;

>  #ifndef SQLITE_OMIT_TRIGGER
>    /* A complex statement machine used to detect the end of a CREATE TRIGGER
> @@ -551,7 +557,7 @@
>          }
>          zSql += 2;
>          while( zSql[0] && (zSql[0]!='*' || zSql[1]!='/') ){ zSql++; }
> -        if( zSql[0]==0 ) return 0;
> +        if( zSql[0]==0 ) { *last = lastseen; return 0; }
>          zSql++;
>          token = tkWS;
>          break;
> @@ -562,14 +568,14 @@
[...snip...]

This is to allow us to efficiently load large database dumps.  It needs
to be proposed upstream in the near future.  It would probably be polite
to the upstream developers to implement the equivalent changes for the
UTF-16 version, but only after confirming that this sort of change would
be accepted upstream.

Cheers,
-mjg
-- 
Matthew Gregan                     |/
                                  /|                address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]