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
with.
Mark
---------------------------------------------------------------------
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