On 13/07/2011 19:25, Metzler, David wrote:
Um... you do understand that this is data, right? It can't be thought of like source code. You will never get exactly the same data twice, even if you haven't edited a single thing on your site.
Every DB export will be different. There are even session variables in the DB, so it's not like you can use it to track changes. What difference does it make which backup methodology you choose as long as you've tested the restore? I assume that's what you're using it for, since it really doesn't make sense from the version control perspective.
This is very useful, thankyou David - no I hadn't realised this - the point about session variables puts it all in perspective for me.
So if I *did* want to use it from a version control perspective I'd need to be able to extract the content in some non-permeable form (i.e. so the same content had always the same representation - as it does with files in a file system for example) - in fact that gives me an idea - with a bit of nifty footwork (e.g. knocking out mysqld for a short period) it should be possible to do something here directly with the database files in the filesystem. I did do this with a running database once (tarred it up and shifted it across machines) and it worked fine. :-). Never did like sql - its only an API after all, it all ends up on some filesystem or other. Hmmmm - wonder if it uses any of the timestamp info on the files. Hmmm2 - wonder what the variability across the files is. It doesn't make sense to me to put an exported database in a version control system because of this point that no two exports will be the same even without change in the content but it might make sense to put the raw files beneath it in one (with careful control of the processes that use the files).
andy