Bitten Again
I’m helping to edit a book for O’Reilly, and we’re keeping details on contributors, and the status of their chapters, in a little SQLite database. The database file is kept under version control, since everything should be; unfortunately, Subversion doesn’t know how to diff or merge concurrent changes. I’ve griped about this before: just as languages become more useful when functions and classes are first-class values, so too do data formats become more usable when they are supported by tools that let people create them collaboratively. Moving the data itself onto the web (as I suggested to scientists who are using Excel spreadsheets as structured lab notebooks) is a stopgap measure: the real world will always require people to work offline from time to time, and we damn well ought to support it.
Subversion actually does know how to diff and merge concurrent changes to textual data. It does not know how to do so with binary files, however (since they typically represent a proprietary data format). You might want to use an alternate merging model:
http://svnbook.red-bean.com/nightly/en/svn.basic.vsn-models.html
Yes, I know Subversion can diff/merge textual changes, but SQLite doesn’t store data as ASCII text — its files are in a compact (platform-independent) binary format, and there’s no diff/merge tool for it.
If your requirement is to allow easy collaboration and diffing/merging of changes, perhaps you should stop storing such simple information in a sqlite database? Why not just a text file? Is the data so complex that you really need to ‘mine’ it with SQL queries?