[cvsnt] Re: CVSNT 2.6 database engine?

[Bo Berglund]

On Fri, 21 Oct 2005 18:21:25 +0100, Tony Hoyle
<tony.hoyle at march-hare.com> wrote:

>Bo Berglund wrote:
>> Tony,
>> now I must still my curiosity about CVSNT 2.6 (should possibly be
>> promoted to 3.0 instead?).
>> 
>> You mention 'database' when you occationally comment on something and
>> refer to 2.6. So I wonder what engine will be used?
>
>Initially SQLite, since it requires no installation or external 
>maintenence - that will be the normal default.

That is what I use for our Roundup bug trackers...

>At some point during the 2.6 cycle support will also be available for 
>Postgres, MSSQL (via ODBC), Oracle and possibly others... the Postgres 
>and ODBC engines are already there in the audit support.
>
>It's likely MySql support will remain but be slowly depreciated (license 
>issues... we need to link our proprietary stuff to the APIs too and 
>paying £300/client for the commercial version just isn't practical when 
>the entire application ships for £80 a copy...  that pins us to MySql 
>3.23 which won't keep working forever with the newer servers).

I remember voicing my concerns about MySql a year or so back when you
started to talk about a databes backend just because of the styrange
licensing issues...

>> And what exactly will be stored in the database? The admin data or the
>> actual files or both?
>
>Currently it's planned there will be at least 2 databases - a global one 
>(users, groups, repositories, global config), and one per repository*.
>
>> I can see a size problem with storing files because at least MSDE2000
>> is limited to a 2Gb total database size.
>
>At the moment all the data is in the RCS files.. it'll end up in the 
>database in the 3.0 timeframe...  
OK, so the body of the files will be stored as text in the database
then? What about binary files? We have binaries that now have RCS
files in the 150-200 Mb range and it makes operations on these files
real slow. Keeping the admin data in the database would probably get
rid of all that speed problem. Could you not store the binaries in the
file system with pointers in the database?

>SQLite has no filesize limits so that 
>won't be an issue (if you want to stick with MSDE a developer edition of 
>SQLServer will do the same job and ships with MSDN if you have that).

I just wonder how SQLite will perform. For once it is single-threaded
as far as I know, so concurrent usage might be hard to achieve. At
least this is what we see in our Roundup tracker. In that any user
accessing the database will lock it for the others.

We ship MSDE2000 with our applications so we have plenty experience
with using ADO to access it. It really flies. Possibly a bit slower
with ODBC though. But there is te 2 Gb limit on MSDE databases. With a
full version SQL2000 the limit is not there at all of course.

>Tony
>
>* In actual fact these may be the same physical database - especially in 
>oracle where it's a royal pain in the ass to create new ones...

Really simple to do with MSSQL :-)


/Bo
(Bo Berglund, developer in Sweden)