Yes, he likely really does need to source control the data. A very
common requirement is bootstrap data necessary to get the database up
and running such that an application can use it right out of the box;
lookup values, default users, etc. usually make up that kind of data.
Admittedly an alternative approach is to have the application insert
said data when it starts up. There are pros and cons to both
approaches.
Also, test data is something you need to control very closely. If my
tests suddenly start to fail and I realize it's due to bad data, I want
to know who changed the data and when.
On my current project we absolutely require that the database be
reproducible only from scripts. It can be a little cumbersome to get
your test data back out into this format if you like to insert things
directly, but there are ways around that. If we didn't do this, we
can't take advantage of our source control system's natural ability to
show us what changed in a particular file and who made the change.
Personally, I find it a lot more portable and subversion friendly than
using a binary modeling tool which updates a database directly. With
the scripts, I can easily do the following:
- tear down the existing database
- create a new, clean copy of the database with bootstrap data
- install selected (or all) test data required for unit and integration
tests
My $0.02CDN.
Glenn McAllister
Sapient Canada
-----Original Message-----
From: Martin A. Brooks [mailto:martin@hinterlands.org]
Sent: Sunday, February 06, 2005 3:13 PM
To: 'users@subversion.tigris.org'
Subject: Re: How to version a database
Will Merrell wrote:
>This works, but is clumsy and error prone. How do other people handle
this
>kind of situation? What other options do people use?
>
>
You could store the schema and the data in separate files. The schema
should change less often than the data, of course. Alternatively, use a
database that support PITR (Point In Time Recovery), such as postgres.
Do you really need to version control the _data_ in your database?
Regards
Mart.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Feb 7 02:40:38 2005