Re: problem with git-cvsserver

[Marco Roeland <marco.roeland@xs4all.nl>]

On Friday September 1st 2006 at 12:07 Martin Langhoff wrote:

[warning: discussion about sqlite; no direct git serviceable parts inside!]

> >I have to say though: Ouch. Do you know if there's an upgrade path for
> >apps? Does v3 detect you've got a v2 file and do something smart
> >(upgrade in place / spit out a readable error)?

Applications for both v2 and v3 can work on the same machine at the same
time. Both versions will not corrupt a database of the other version
and will immediately stop with an error, although the error isn't very
readable (doesn't mention _which_ version it saw or needed).

They do not perform an upgrade in place.

But as sqlite or sqlite3 databases are standalone files, most of the
time just use the sqlite version that is standard for your platform
and/or version. For new development v3 is the way to go, as v2 is in
deep sleep maintenance now.

Not just the database format changed in v3, the whole API changed
incompatibly.

> Oh, grumble. See the comment at the bottom of
> http://www.sqlite.org/formatchng.html
> 
> We may need to add something in the doco pointing to this "technique",
> and perhaps the URL as later versions may do something different.
> 
> I do wonder what the debian packaging does, perhaps the v3 package
> forces an upgrade to the v2 package that renames the cli binary? I
> guess the drawback of having the DBs anywhere in the FS is that the
> packaging can't upgrade them for you as it does with Pg for instance
> :(

The commandline programs are called 'sqlite' and 'sqlite3' so there is
no "upgrade", you can have the two different versions simultaneously
installed and working on the same machine.

Unfortunately the 'sqlite3' doesn't directly read the 'sqlite' format
and neither the other way round. You can convert a database easily from
the one format to the other:

$ echo .dump | sqlite database.v2.dat > dump.v2.dat
$ sqlite3 < dump.v2.dat database.v3.dat

If you don't use the new features in sqlite3 you can even convert back
in the same way:

$ echo .dump | sqlite3 database.v3.dat > dump.v3.dat
$ sqlite < dump.v3.dat database.v2.dat

Use a non-existent file for the target database, and sqlite(3) will
create the database for you. Do check the conversion as error reporting
in the commandline tools in this "batch" mode is sometimes rather sparse
or non-existent!

Once you got it finally going I find that sqlite(3) is a fast, reliable
and quite handy database. Especially, as Johannes said, its standalone
nature makes developing and deploying very easy.
-- 
Marco Roeland