You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "Hyrum K. Wright" <hy...@mail.utexas.edu> on 2009/02/11 16:42:39 UTC

Re: svn commit: r35810 - trunk/subversion/libsvn_subr

On Feb 11, 2009, at 9:52 AM, Hyrum K. Wright wrote:

> Author: hwright
> Date: Wed Feb 11 07:52:20 2009
> New Revision: 35810
>
> Log:
> More efficiently cleanup existing prepared statements when closing  
> an SQLite
> database.
>
> * subversion/libsvn_subr/sqlite.c
>  (close_apr): Use the sqlite3_next_stmt() API to fetch any outstanding
>    prepared statements, and cleanup error handling.
>
> Modified:
>   trunk/subversion/libsvn_subr/sqlite.c

...

This change added use of sqlite3_next_stmt(), which was introduced in  
SQLite 3.6.0.  We currently state the the minimum required version of  
SQLite is 3.4.0, but that was before we added support for building the  
SQLite amalgamation as part of Subversion.  I currently see two options:
  * Bump the minimum required version
  * Roll back r35810.
  * (Well, a third option is to maintain two separate #ifdef'd  
implementations, but I don't think we want to go down that road.)

Thoughts?

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1139788

Re: svn commit: r35810 - trunk/subversion/libsvn_subr

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Feb 16, 2009, at 8:05 AM, Senthil Kumaran S wrote:

> Hyrum K. Wright wrote:
>>> Though SQLite 3.6.0 was released in 2008 July 16, most of the  
>>> distros
>>> are still
>>> with 3.5.9 or even older versions. So I think bumping the minimum
>>> required
>>> version (which is 3.4.0 right now) will not be the best solution.
>>>
>>>> * Roll back r35810.
>>>
>>> I think we can do this and keep it for future.
>>
>> Rolled back in r35829.
>
> Should we make a note of the above in our issue tracker? so that we  
> ll not miss
> it in future?

We can, if you'd like.  I'm not quite sure what the issue would be,  
though.

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1170911

Re: svn commit: r35810 - trunk/subversion/libsvn_subr

Posted by Senthil Kumaran S <se...@collab.net>.
Hyrum K. Wright wrote:
>> Though SQLite 3.6.0 was released in 2008 July 16, most of the distros
>> are still
>> with 3.5.9 or even older versions. So I think bumping the minimum
>> required
>> version (which is 3.4.0 right now) will not be the best solution.
>>
>>>  * Roll back r35810.
>>
>> I think we can do this and keep it for future.
> 
> Rolled back in r35829.

Should we make a note of the above in our issue tracker? so that we ll not miss
it in future?

-- 
Senthil Kumaran S
http://www.stylesen.org/

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1170880

Re: svn commit: r35810 - trunk/subversion/libsvn_subr

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Feb 12, 2009, at 4:10 AM, Senthil Kumaran S wrote:
>
> Hyrum K. Wright wrote:
>> On Feb 11, 2009, at 9:52 AM, Hyrum K. Wright wrote:
>>
>>> Author: hwright
>>> Date: Wed Feb 11 07:52:20 2009
>>> New Revision: 35810
>>>
>>> Log:
>>> More efficiently cleanup existing prepared statements when closing
>>> an SQLite
>>> database.
>>>
>>> * subversion/libsvn_subr/sqlite.c
>>> (close_apr): Use the sqlite3_next_stmt() API to fetch any  
>>> outstanding
>>>   prepared statements, and cleanup error handling.
>>>
>>> Modified:
>>>  trunk/subversion/libsvn_subr/sqlite.c
>>
>> ...
>>
>> This change added use of sqlite3_next_stmt(), which was introduced in
>> SQLite 3.6.0.  We currently state the the minimum required version of
>> SQLite is 3.4.0, but that was before we added support for building  
>> the
>> SQLite amalgamation as part of Subversion.  I currently see two  
>> options:
>>  * Bump the minimum required version
>
> Though SQLite 3.6.0 was released in 2008 July 16, most of the  
> distros are still
> with 3.5.9 or even older versions. So I think bumping the minimum  
> required
> version (which is 3.4.0 right now) will not be the best solution.
>
>>  * Roll back r35810.
>
> I think we can do this and keep it for future.

Rolled back in r35829.

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1145469

Re: svn commit: r35810 - trunk/subversion/libsvn_subr

Posted by Senthil Kumaran S <se...@collab.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hyrum K. Wright wrote:
> On Feb 11, 2009, at 9:52 AM, Hyrum K. Wright wrote:
> 
>> Author: hwright
>> Date: Wed Feb 11 07:52:20 2009
>> New Revision: 35810
>>
>> Log:
>> More efficiently cleanup existing prepared statements when closing  
>> an SQLite
>> database.
>>
>> * subversion/libsvn_subr/sqlite.c
>>  (close_apr): Use the sqlite3_next_stmt() API to fetch any outstanding
>>    prepared statements, and cleanup error handling.
>>
>> Modified:
>>   trunk/subversion/libsvn_subr/sqlite.c
> 
> ...
> 
> This change added use of sqlite3_next_stmt(), which was introduced in  
> SQLite 3.6.0.  We currently state the the minimum required version of  
> SQLite is 3.4.0, but that was before we added support for building the  
> SQLite amalgamation as part of Subversion.  I currently see two options:
>   * Bump the minimum required version

Though SQLite 3.6.0 was released in 2008 July 16, most of the distros are still
with 3.5.9 or even older versions. So I think bumping the minimum required
version (which is 3.4.0 right now) will not be the best solution.

>   * Roll back r35810.

I think we can do this and keep it for future.

Thank You.
- --
Senthil Kumaran S
http://www.stylesen.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmT9aAACgkQ9o1G+2zNQDiO7wCgxDKYV/zIa76LWlbw73RQnhs+
3yUAoJhsrmquo3auvCj2GmgZHJcvwRst
=ufAd
-----END PGP SIGNATURE-----

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1144200