At the moment we only have our stored procs in CVS but it works really
well. Each stored proc is in it's own file with a drop proc ... create
proc ... grant permissions ... type of sequence. When installing a new
"release" of the procedures we simply run through all of them. This is
somewhat overkill (dropping and createing 1000 procs) but it doesn't
take very long (~5 minutes) and your assured that every proc in the
database is up to date.
Views also work pretty well organized the same way but things start to
get more tricky when you want to put your table definitions into CVS.
Once tables are populated (and large) it's tough to drop and re-create
them! So far we have our heads in the sand on this one and simply leave
it up to the DBA's to keep the tables straight. We'd never be able to
revert to an old release of our database however.
Phil Shrimpton wrote:
>
> > From: [EMAIL PROTECTED]
>
> Hi,
>
> > As far as I know, people don't use CVS for databases.
> >
> > A simple 300MB database might take up many gigs after
> > just a few revisions. You're better off using the programs
> > the database comes with for version control and backup
>
> I was not thinking about a populated database, but if you are using lots of
> stored procedures and embedded code, you really need to keep the Metadata
> under version control with your applications code. The 'easiest' way is to
> store the database binary, but it looks like extracting the DDL and
> recreating each time is probably the best option.
>
> Cheers
>
> Phil
--
Cheers,
Derek
_____________________________________________________________________
Derek Scherger Echologic Software Corporation
mailto:[EMAIL PROTECTED] http://www.echologic.com
