I have used a variety of version control methods and products over the years. In the beginning, I (infrequently) added a digit or date to the end of the file name, an effort that was largely ineffective and highly subject to user error. :-) Then, corresponding with a job change, I was introduced to version control software in the shape of CS-RCS from ComponentSoftware, based on GNU RCS. After a couple of years, the development team made the shift to Subversion, my personal favorite. To be complete, I will throw in a year of pain using Visual SourceSafe.

Despite the differing products, or methods, the common thread was I only put my CF code into version control. But wait. I write web applications, and web applications consist for more than just the UI and business object layers. What about the database?

My current development methodology for maintaining the application data model - the tables, views, stored procedures, functions, etc. for the application - lags far behind that for maintaining the CF code. If I need to modify a table or view, I script the change and execute it against the development database. The script usually then disappears into the ether. When it comes time to move changes into a higher environment, everything has to be recreated, often from memory if it is a solo effort. Talk about cowboy coding.

The first step I can take in providing discipline to data model changes is to script the data model and add them into version control. Each object will need a separate script file. As I make changes to an object, I will then have to regenerate the script and commit the new script.

This seems a little tedious, but it is a step in the right direction to providing the same change control discipline I use for my CF code to the data model behind the application.