> hi, > I was wondering how u people are working with SQL-shema changes... say I > have it under CVS control... > How u automate adding/removing tables and fields, and as special case > populating some of the tables...!!
CVS is not a build tool. To make sure that all the schemata and the application code (all of it) is consistent, you really have to have regression tests that exercise all of the table definitions. Only when all regression tests pass would you commit *.sql and application code to CVS (or rather, it would be commited earlier, but given it some significant tag or branch when everything flies again). This is not trivial, especially if people have to hand tweak the schema's inside the databases (which is not uncommon). If they do so, dump the schema from the database, can commit it. I would suggest using a layer of view definitions (to be used by the application code) can help insulate you from schema churn. A final scenario is that the tables definitions are embedded in the applications (e.g. if you have some object layer). In this case, *.sql is a derivation, hence should not be stored under CVS. -- The mail transport agent is not liable for any coffee stains in this message ----------------------------------------------------------------------------- Philip Lijnzaad, [EMAIL PROTECTED] European Bioinformatics Institute,rm A2-08 +44 (0)1223 49 4639 Wellcome Trust Genome Campus, Hinxton +44 (0)1223 49 4468 (fax) Cambridgeshire CB10 1SD, GREAT BRITAIN _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs