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] -----------------------------------------------------------------------------
