This allows the developers to have their own copies of the db on their workstations and try out new things without messing up the shared dev db. So in the morning when a developer starts working, he can do an update and pull down any DTS scripts that need to be run against his local db from the latest build.
I will be making the cf code for this app with its ant scripts available very shortly.
Russ
On 9/9/06, Dave Merrill <
[EMAIL PROTECTED]> wrote:
Another perspective...If you're building commercial software, various customers are using various versions of your stuff, and may upgrade to any other version at any time. You need a way to automatically upgrade them from any schema version to any later one.Typically that's done with a table that stores the current schema version *of the db*, and a series of code steps that know how to upgrade it from each step to the next. When a site installs new code, the appropriate code steps run to get them from wherever they were to the state the new code expects. That might mean adding tables or columns, inserting or modifying data, anything needed. Rails has built-in hookups for this, called migrations, and some other frameworks in other languages that I've used did too; most cf products roll their own AFAIK.The developer-process upshot is that everyone can use their own local dbs, and whenever they check out new code that requires a schema update, it happens for them automatically, just like it does for customers.This seems to me to be very much the best way. A shared db won't be stable if people are evolving their ideas while others who don't have the relevant code yet are trying to use it. Better to get things fleshed out "in private", then promote the schema update code that makes it so. Other developers will get those db updates at the same time they get the code that requires them.Dave Merrill-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Vega
Sent: Wednesday, August 30, 2006 4:42 PM
To: CFCDev@cfczone.org
Subject: [CFCDEV] subversionI have a quick question for anyone using subversion. I am trying to get our developers to move towards subversion and we have come across one problem. If everyone develops on a local machine, updates at the begining of the day and commits at the end of the day. At the end of the day I have a script that runs and moves a build to our staging server. One question though, how do you deal with a MSSQL 2000 database. We all have local copies of the database but make changes to the design and add data. What is the best solution to our problem, any help would be greatly appreciated.
--
Dan Vega
[EMAIL PROTECTED]
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm
CFCDev is supported by:
Katapult Media, Inc.
We are cool code geeks looking for fun projects to rock!
www.katapultmedia.com
An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
