Re: problem with git-cvsserver

From: Marco Roeland <marco.roeland@xs4all.nl>
Date: Sep 1, 2006, 07:05 UTC
Message-ID: <20060901070559.GA22015@fiberbit.xs4all.nl>
In-Reply-To: <46a038f90608311707t4ab5fc2fj45e852df4b91870f@mail.gmail.com>

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.

Show 11 quoted lines

> 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