Re: How do I connect postgres table structures and view structures to an existing svn repository?
От | Scott Marlowe |
---|---|
Тема | Re: How do I connect postgres table structures and view structures to an existing svn repository? |
Дата | |
Msg-id | dcc563d10708010946o4c69542yc876c2bc16768e54@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: How do I connect postgres table structures and view structures to an existing svn repository? ("John Mitchell" <mitchelljj98@gmail.com>) |
Ответы |
Re: How do I connect postgres table structures and view
structures to an existing svn repository?
|
Список | pgsql-sql |
On 8/1/07, John Mitchell <mitchelljj98@gmail.com> wrote: > I am trying to store schema definitions in version-control which I can do by > saving the definition and then importing into svn, but I would like it > to be automatic , so that when an update occurs to a table or view within > postgres then that table or view is flagged within svn. This would be > similar to what I currently do with source code that I have for a web app > within eclipse. OK, the first decision point is whether you want to store whole schemas and blow away the old one each time, or if you want to store incremental changes. I recommend creating an initial schema of version 1.0, and then creating delta files after that as you change your schema. Your first schema can have a table in it called schemaversion(version text primary key, notes text); with an entry there something like '1.0','initial schema'. Each delta .sql file you create would then have an insert into the schemaversion table with the version number it brings the schema up to and a note of possibly the change ticket or bug number or even a brief overview of the changes it implements. That way you can have a production schema at some stable version, say 1.0.8, while your development schema can move ahead to 2.0.4. then you can simply apply the delta files to take you from 1.0.8 to 2.0.4 when you want to upgrade production. Store each of these files in some directory in svn and you're done. My point being that you need to drive the changes from the svn side, not the database side. I've seen no reliable way to do it otherwise, but would love to be pleasantly surprised.
В списке pgsql-sql по дате отправления: