That sounds like it would be a great solution if the need to go back to different points in the database were needed.
Our needs have always been just to go back to one certain point and really it has always been to go to that point with the data intact to then diagnose the problem. Typically the users never provide enough details to easily recreate the problem via creation of all new test data. To revert back to different versions of the database we could always just export that versions via the modeling tools we design the databases within since they have versioning in them but honestly never tried it since not had the need. On 10/7/07, Zaphod Beeblebrox <[EMAIL PROTECTED]> wrote: > > This is where something like Rails migrations would be a great thing > for a CF framework to copy. All of your database changes are kept in > ruby files that describe table creation, column additions, table > deletions, and if so needed, raw sql statements to create functions or > stored procs. Every ruby migration file is a migration point and has > two methods 'up' and 'down', anything you do in the up method must be > reflected as an opposite action in the down method. So if you're at > migration 18 and you want to go back to version 16, "rake db:migrate > VERSION=16" will do all the necessary changes for you. > > > > On 10/7/07, Aaron Rouse <[EMAIL PROTECTED]> wrote: > > Could you explain that with a little more detail. What code(language) > is > > going to track all of the table/column changes and track any data > > manipulation that is needed between versions of the database structure? > > Also if you are creating a database of that era, say version 1.5, does > this > > mean it is going to drop the database of the version 2.0 era in order to > > have a place to put the 1.5 era? > > > > On 10/7/07, Dale Fraser <[EMAIL PROTECTED]> wrote: > > > > > > Control the databases through code. > > > > > > Then if you check out your code at 1.3.2 > > > > > > It should be able to create databases of that era. > > > > > > Regards > > > Dale Fraser > > > > > > http://learncf.com > > > > > > -----Original Message----- > > > From: Aaron Rouse [mailto:[EMAIL PROTECTED] > > > Sent: Monday, 8 October 2007 11:23 AM > > > To: CF-Talk > > > Subject: Re: SOT: How do you version control with your CF code? > > > > > > What do you do when client needs a fix on version 1.5 which has > > > significant > > > database differences when compared to version 2.0 that you are > currently > > > working on? We just maintain a separate copy of the DB for the > versions > > > for > > > cases like that but just curious on how others do it. > > > > > > On 10/7/07, J.J. Merrick <[EMAIL PROTECTED]> wrote: > > > > > > > > Rick, > > > > > > > > > > > > > > > > 3. Branch and tagging. "me: ::working on version 2.0:: client: I > need > > > > to you fix something that is broken on the live server! me: ok:: > > > > switch to the trunk which is version 1.5, fix, deploy, switch back > to > > > > v2.0 branch" no mess and no thought > > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Download the latest ColdFusion 8 utilities including Report Builder, plug-ins for Eclipse and Dreamweaver updates. http;//www.adobe.com/cfusion/entitlement/index.cfm?e=labs%5adobecf8%5Fbeta Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:290504 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
