I would tend to lean towards cvs storage as a flat file .dump format of the
database rather than the binary database.
1. Its more portable. What happens if sqlite is no longer maintained or
actively developed?
2. Create the db is simple. Allowing you easy migration from one version of
sqlite to the next. Although backwards compatiblity is generally maintained,
there have been instances when this is broken.
I would also maintain in cvs the create sql commands (.schema) seperate from
the data.
Just my opinion, I'm sure others here will differ.
Regards,
Ken
Rich Rattanni <[EMAIL PROTECTED]> wrote: All:
I have several sqlite databases that I want to store in my version
control system. I was wondering if instead of storing them as binary
files, would make sense to store a SQL dump in version control. When
I create a root file system for my development board I will create the
databases from the SQL dump.
I had two reasons for thinking this was a good idea
1) If I upgrade sqlite and build a new root file system, then my
databases will be created with the same version of sqlite.
2) This is essentially the same (or better?) as a vacuum, since the
database should be completely free of any wasted space.
2) They may be a slight possibility of using version control faculties
(diff, blame, etc) while I am developing.
However I thought of one con for doing this
1) It may be stupid to do this.
I guess I am more concerned with wether or not I can guarantee that
the sqlite engine is deterministic such that for a given sequence of
SQL input each time I wind up with the same database (of course, using
sqlite3 to dump the sql may not guarantee me the same sequence of SQL
as was used to create the database, huh?).
Feedback? (please be nice)
--
Rich Rattanni
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
