Using ALTER statements would make it tough to get a complete view. I
would stick with your original idea. This would enable diffs to work
nicely, and the latest revision would contain everything you need to
know to create the database.
-Micah
On 04/01/2007 07:11 AM, Miles Thompson wrote:
> Michael,
>
> We're about to head down the same road, using Subversion, and my
> thought was to
> initially capture a series of CREATE TABLE statements and store them
> all in one file.
>
> Then as schema was modified on the development server, update those
> statements using SVN.
>
> Your idea looks a lot better, may I presume to outline how I think you
> use it?
> I'm assuming you capture, for each table, an initial CREATE TABLE,
> and save it in a file. Then as the schema changes you update the file
> with the ALTER TABLE statements, commiting the changes.
>
> If you have to recreate the database, you execute the file up to the
> last change point.
>
> I suppose you could do the same thing to maintain the data stored in
> lookup tables.
>
> We're using Joomla! and have extended it quite a bit, and are now
> running three databases - dev, beta and since last week, live.
>
> Later this week I'll be moving myself and one other developer to an
> SVN environment; we will see how it goes.
>
>
> Cheers - Miles Thompson
>
>
> At 07:04 PM 3/30/2007, Michael Dykman wrote:
>
>> We keep all of the schema (one file per table) in SVN (subversion)
>> with a directory to represent each database. As the schema evolves,
>> we have had no trouble tracking changes through resource history and
>> are able to extract diffs on every commited change. It works like a
>> charm and would proably work equally as well with CVS.
>>
>> - michael
>>
>>
>> On 3/30/07, Tim Gustafson <tim@santacruzcomputers.com> wrote:
>>> Hello!
>>>
>>> I'm just getting in to using CVS to track changes to my source code
>>> for PHP
>>> projects that I'm working on, and it's exactly what my organization
>>> needed.
>>>
>>> However, there does not appear to be a way to track changes to mySQL
>>> databases in the same way. Basically, as the structure of tables are
>>> changed to meet the requirements of new features, I'd like a way to
>>> be able
>>> to record those changes (both structural table changes and also
>>> "default
>>> table data" such as table of states or zip codes or whatever) in a
>>> CVS-type
>>> system (preferably integrated with CVS directly) so that when a
>>> customer
>>> uses CVS to get the newest version of the code for their project,
>>> they can
>>> also get (and automatically apply) all changes to their database for
>>> the new
>>> version.
>>>
>>> Does such a system exist? How do other people cope with these types of
>>> updates?
>>>
>>> Thanks for any guidance!
>>>
>>> Tim Gustafson
>>> (831) 425-4522 x 100
>>> (831) 621-6299 Fax
>>>
>>>
>>> --
>>> MySQL General Mailing List
>>> For list archives: http://lists.mysql.com/mysql
>>> To unsubscribe: http://lists.mysql.com/mysql?unsub=mdykman@gmail.com
>>>
>>
>>
>> --
>> - michael dykman
>> - mdykman@gmail.com
>
>