[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Version control of Databases

From: Mark Parker <mark_at_msdhub.com>
Date: 2005-06-13 16:50:18 CEST

Ryan Schmidt wrote:
> Another solution I've thought of is this: SQL statements that belong
> with a commit should be added as a revprop (say "foo:sql") to that
> revision. When you want to deploy a new release of the system, you
> gather, in order, all the foo:sql properties from all those revisions
> and execute the SQL. Ideally you would also store a second property
> (like "foo:sql-undo") which could undo whatever it was that the SQL
> did. This way, if you need to downgrade to an older release, you can
> pull all the foo:sql-undo properties, in reverse order, and get back to
> more or less the state you were in before. Depending on your confidence
> in these SQL statements this could even be automated to a greater or
> lesser degree in your deployment process.
> I'm not sure how best to handle SQL statements that do not relate to a
> commit.

We tried something like that. We discovered that mere mortal humans
don't have the discipline to ensure that what the create-from-scratch
script makes and what the upgrade-from-previous script mades aren't
always the same. We ended up with a
create-from-scratch-and-use-a-sync-tool approach that we're quite happy


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Jun 13 16:54:47 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.