On Sun, May 04, 2008 at 10:36:47PM +0200, M. Emal Alekozai scratched on the wall: > Hi, > > In the BIG db I have worked on there is a table that log every insert/update > > on specific and important tables and a log of every sql statement execute > > but I haven't ever see a db under version control with svn (or csv or git or > > any other). > > I'm (mis)using subversion more as a synchronization tool than as a > version control system.
You can mark the database files as binary, assuming you're only editing them in one location at a time. Chances are Subversion will mark the database file as "binary" automatically, but you can also force Subversion to consider it binary by setting a non-text MIME type (such as "application/x-sqlite3"). See this FAQ question for more info: http://subversion.tigris.org/faq.html#binary-files Binary files are treated the same as any other file, except they cannot be merged. This is only an issue if the file is edited in more than one source tree at the same time. In this case, when the second source tree tries to do a commit, it will always return as a failed merge. You can also configure Subversion to require a lock on the file in order to edit it. This makes editing even more restrictive, but also means you'll never have to deal with the merge issue. Don't be concerned about putting binary files into revision control systems. Subversion handles this without problems, as do most other revision systems. At my day job well over half the files in our project trees are marked as binary data (we have a lot of image assets). > A possible solution would be to export the sqlite database as a list of > sql commands. This sql commands could be stored in a text file and be > put under version control. Before starting to work on the project I > could build from the text file the sqlite database. This approach means > some extra work but in principle it should work. That is the other common approach. On the plus side, if the SQL is simple enough it will merge just like any other text file. On the minus side, you have to deal with building and dumping the database files. For the "consumer" side of things, you can just treat the SQL dump as a "source file" and add a build rule to whatever environment you're in that re-creates the binary database file from the SQL source. This, of course, assumes you have a "build environment" and not just a collection of documents. Things are a bit more complex for the "producer" side. The most straight forward solution is to edit the SQL dump files and re-build the databases as part of the normal build process. The dump files will then be handled by the revision system just like any other "source" file. Sometimes that's too complex, however. If you need to edit the database file directly (or use a GUI or other tool to manage the database files) then you need a way to dump them back out. Ideally this would be integrated into the editing tools, but that might not be a choice if you're using a third party tool. Chances are good that if your schema is this complex the SQL dump isn't going to merge cleanly anyways-- you might as well just check the database file in directly. Which method is best depends a lot on how complex your data is, and how many people are likely to edit it at the same time. In your specific situation, it sounds like multiple edits are unlikely. In that case, I'd just add the database files to repository directly and be done with it. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "'People who live in bamboo houses should not throw pandas.' Jesus said that." - "The Ninja", www.AskANinja.com, "Special Delivery 10: Pop!Tech 2006" _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
