Обсуждение: subversion support?
Are there plans to support a plug-in to a version control system like subversion for DDL? We really need to version our functions we will be writing but currently, we have to go through some hoops to get the function code into subversion.
Jon
Roberts, Jon wrote: > Are there plans to support a plug-in to a version control system like > subversion for DDL? We really need to version our functions we will be > writing but currently, we have to go through some hoops to get the function > code into subversion. This is hoops? svn ci your_functions.sql How do you do things now? b
Yeah. I think having to save the function to disk and then leave pgAdmin to
execute subversion commands is going through hoops.
Also, pgAdmin should be integrated so that you are notified if the function
in the database is different from the last committed version. A visual diff
should be there so you can see what the differences are.
Jon
-----Original Message-----
From: brian [mailto:brian@zijn-digital.com]
Sent: Wednesday, October 24, 2007 1:59 PM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] subversion support?
Roberts, Jon wrote:
> Are there plans to support a plug-in to a version control system like
> subversion for DDL? We really need to version our functions we will be
> writing but currently, we have to go through some hoops to get the
function
> code into subversion.
This is hoops?
svn ci your_functions.sql
How do you do things now?
b
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
On Wed, 24 Oct 2007 14:11:24 -0500
"Roberts, Jon" <Jon.Roberts@asurion.com> wrote:
>
> Yeah. I think having to save the function to disk and then leave
> pgAdmin to execute subversion commands is going through hoops.
>
> Also, pgAdmin should be integrated so that you are notified if the
> function in the database is different from the last committed
> version. A visual diff should be there so you can see what the
> differences are.
Would you be willing to sponsor such development? :)
Joshua D. Drake
>
>
> Jon
> -----Original Message-----
> From: brian [mailto:brian@zijn-digital.com]
> Sent: Wednesday, October 24, 2007 1:59 PM
> To: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] subversion support?
>
> Roberts, Jon wrote:
> > Are there plans to support a plug-in to a version control system
> > like subversion for DDL? We really need to version our functions
> > we will be writing but currently, we have to go through some hoops
> > to get the
> function
> > code into subversion.
>
> This is hoops?
>
> svn ci your_functions.sql
>
> How do you do things now?
>
> b
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 1: if posting/reading
> through Usenet, please send an appropriate subscribe-nomail command
> to majordomo@postgresql.org so that your message can get through to
> the mailing list cleanly
>
> ---------------------------(end of
> broadcast)--------------------------- TIP 2: Don't 'kill -9' the
> postmaster
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997 http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/
Вложения
Robert, that does sound better. It keeps the names of the files in svn consistent with the database object names which is essential. It also makes it automatic. Unfortunately, it doesn't tell you who did the changes. Do you want to share that code? Thanks! Jon -----Original Message----- From: Robert Treat [mailto:robert@omniti.com] Sent: Wednesday, October 24, 2007 10:24 PM To: pgsql-general@postgresql.org Cc: Roberts, Jon Subject: Re: [GENERAL] subversion support? On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: > Yeah. I think having to save the function to disk and then leave pgAdmin > to execute subversion commands is going through hoops. > > Also, pgAdmin should be integrated so that you are notified if the function > in the database is different from the last committed version. A visual > diff should be there so you can see what the differences are. > We have a script that runs nightly that dumps tables / functions to file, and then checks it in automagically to svn, which sends an email of the diffs. Perhaps that would work for you? -- Robert Treat Database Architect http://www.omniti.com
You could setup a subversion commit hook to export the functions to the database. Then you adjust your development mentality to: 1) Edit the files on the disk 2) Commit to Subversion Then the hook takes over and runs the drop/create automatically, you could even have it email the developer if the create failed. Roberts, Jon wrote: > Robert, that does sound better. It keeps the names of the files in svn > consistent with the database object names which is essential. It also makes > it automatic. Unfortunately, it doesn't tell you who did the changes. > > Do you want to share that code? > > > Thanks! > > > Jon > > -----Original Message----- > From: Robert Treat [mailto:robert@omniti.com] > Sent: Wednesday, October 24, 2007 10:24 PM > To: pgsql-general@postgresql.org > Cc: Roberts, Jon > Subject: Re: [GENERAL] subversion support? > > On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: >> Yeah. I think having to save the function to disk and then leave pgAdmin >> to execute subversion commands is going through hoops. >> >> Also, pgAdmin should be integrated so that you are notified if the > function >> in the database is different from the last committed version. A visual >> diff should be there so you can see what the differences are. >> > > We have a script that runs nightly that dumps tables / functions to file, > and > then checks it in automagically to svn, which sends an email of the diffs. > Perhaps that would work for you? > -- Brad Lhotsky <lhotskyb@mail.nih.gov> NCTS Computer Specialist Phone: 410.558.8006 "Darkness is a state of mind, I can go where you would stumble." -Wolfsheim, 'Blind'
I could use psql instead of pgAdmin then which isn't what I want. Having used Quest software SQL Navigator since 97 for Oracle and then migrated to Toad for Oracle which both products have integration to source control, it is hard to revert back to a command line or text file solution. pgAdmin should graphically show differences between the committed version and the database. It should allow me to click a button in the tool and commit it to the repository. It should allow me to revert back to a previous version and the tool take care of restoring the function automatically. It should show history and let me see the differences. In other words, take Tortoise and merge that product into pgAdmin so I have one product instead of two. Jon -----Original Message----- From: Brad Lhotsky [mailto:lhotskyb@mail.nih.gov] Sent: Thursday, October 25, 2007 9:13 AM To: Roberts, Jon Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] subversion support? You could setup a subversion commit hook to export the functions to the database. Then you adjust your development mentality to: 1) Edit the files on the disk 2) Commit to Subversion Then the hook takes over and runs the drop/create automatically, you could even have it email the developer if the create failed. Roberts, Jon wrote: > Robert, that does sound better. It keeps the names of the files in svn > consistent with the database object names which is essential. It also makes > it automatic. Unfortunately, it doesn't tell you who did the changes. > > Do you want to share that code? > > > Thanks! > > > Jon > > -----Original Message----- > From: Robert Treat [mailto:robert@omniti.com] > Sent: Wednesday, October 24, 2007 10:24 PM > To: pgsql-general@postgresql.org > Cc: Roberts, Jon > Subject: Re: [GENERAL] subversion support? > > On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: >> Yeah. I think having to save the function to disk and then leave pgAdmin >> to execute subversion commands is going through hoops. >> >> Also, pgAdmin should be integrated so that you are notified if the > function >> in the database is different from the last committed version. A visual >> diff should be there so you can see what the differences are. >> > > We have a script that runs nightly that dumps tables / functions to file, > and > then checks it in automagically to svn, which sends an email of the diffs. > Perhaps that would work for you? > -- Brad Lhotsky <lhotskyb@mail.nih.gov> NCTS Computer Specialist Phone: 410.558.8006 "Darkness is a state of mind, I can go where you would stumble." -Wolfsheim, 'Blind'
Hi, Roberts, Jon schrieb: > I could use psql instead of pgAdmin then which isn't what I want. > > Having used Quest software SQL Navigator since 97 for Oracle and then > migrated to Toad for Oracle which both products have integration to source > control, it is hard to revert back to a command line or text file solution. Well you can still use gui tools and just let them work against a development database. With little scripting you can just dump the schema of that database periodically and check it in to SVN. Hook scripts can then take over the deployment (ideally based on tag creation) > > pgAdmin should graphically show differences between the committed version > and the database. Does SQL Nav do this? At least the SQL Navigator/Toad support seems to heavily depend on server side code to help. This looks very unclean to the very least. > It should allow me to click a button in the tool and commit it to the > repository. > > It should allow me to revert back to a previous version and the tool take > care of restoring the function automatically. You can test before you commit in the database - unlike Oracle, Postgres supports transactions even for DDL :-) (ok, I've yet find the button in pgadmin to disable auto commit :-) Regards Tino
Roberts, Jon wrote: > I could use psql instead of pgAdmin then which isn't what I want. > > Having used Quest software SQL Navigator since 97 for Oracle and then > migrated to Toad for Oracle which both products have integration to source > control, it is hard to revert back to a command line or text file solution. > > > pgAdmin should graphically show differences between the committed version > and the database. 1. Complaints about pgadmin, should go to the pgadmin this. This is a postgresql list. > > It should allow me to click a button in the tool and commit it to the > repository. > > It should allow me to revert back to a previous version and the tool take > care of restoring the function automatically. > > It should show history and let me see the differences. > > In other words, take Tortoise and merge that product into pgAdmin so I have > one product instead of two. 2. Are you will to sponsor such development? Sincerely, Joshua D. Drake > > > Jon > > -----Original Message----- > From: Brad Lhotsky [mailto:lhotskyb@mail.nih.gov] > Sent: Thursday, October 25, 2007 9:13 AM > To: Roberts, Jon > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] subversion support? > > You could setup a subversion commit hook to export the functions to the > database. > > Then you adjust your development mentality to: > > 1) Edit the files on the disk > 2) Commit to Subversion > > Then the hook takes over and runs the drop/create automatically, you > could even have it email the developer if the create failed. > > > Roberts, Jon wrote: >> Robert, that does sound better. It keeps the names of the files in svn >> consistent with the database object names which is essential. It also > makes >> it automatic. Unfortunately, it doesn't tell you who did the changes. >> >> Do you want to share that code? >> >> >> Thanks! >> >> >> Jon >> >> -----Original Message----- >> From: Robert Treat [mailto:robert@omniti.com] >> Sent: Wednesday, October 24, 2007 10:24 PM >> To: pgsql-general@postgresql.org >> Cc: Roberts, Jon >> Subject: Re: [GENERAL] subversion support? >> >> On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: >>> Yeah. I think having to save the function to disk and then leave pgAdmin >>> to execute subversion commands is going through hoops. >>> >>> Also, pgAdmin should be integrated so that you are notified if the >> function >>> in the database is different from the last committed version. A visual >>> diff should be there so you can see what the differences are. >>> >> We have a script that runs nightly that dumps tables / functions to file, >> and >> then checks it in automagically to svn, which sends an email of the diffs. > >> Perhaps that would work for you? >> >
Ever tried Druid? http://druid.sourceforge.net/ Il Thursday 25 October 2007 18:02:51 Tino Wildenhain ha scritto: > Hi, > > Roberts, Jon schrieb: > > I could use psql instead of pgAdmin then which isn't what I want. > > > > Having used Quest software SQL Navigator since 97 for Oracle and then > > migrated to Toad for Oracle which both products have integration to > > source control, it is hard to revert back to a command line or text file > > solution. > > Well you can still use gui tools and just let them work against a > development database. With little scripting you can just dump > the schema of that database periodically and check it in to SVN. > > Hook scripts can then take over the deployment (ideally based > on tag creation) > > > pgAdmin should graphically show differences between the committed version > > and the database. > > Does SQL Nav do this? At least the SQL Navigator/Toad support seems > to heavily depend on server side code to help. This looks very unclean > to the very least. > > > It should allow me to click a button in the tool and commit it to the > > repository. > > > > It should allow me to revert back to a previous version and the tool take > > care of restoring the function automatically. > > You can test before you commit in the database - unlike Oracle, Postgres > supports transactions even for DDL :-) (ok, I've yet find the button > in pgadmin to disable auto commit :-) > > > Regards > Tino > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
Complaint? Who is complaining? I am simply asking if this feature that is rather common in other database development tools will ever be added to pgAdmin. And no, I will not sponsor such development. Jon -----Original Message----- From: Joshua D. Drake [mailto:jd@commandprompt.com] Sent: Thursday, October 25, 2007 11:16 AM To: Roberts, Jon Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] subversion support? Roberts, Jon wrote: > I could use psql instead of pgAdmin then which isn't what I want. > > Having used Quest software SQL Navigator since 97 for Oracle and then > migrated to Toad for Oracle which both products have integration to source > control, it is hard to revert back to a command line or text file solution. > > > pgAdmin should graphically show differences between the committed version > and the database. 1. Complaints about pgadmin, should go to the pgadmin this. This is a postgresql list. > > It should allow me to click a button in the tool and commit it to the > repository. > > It should allow me to revert back to a previous version and the tool take > care of restoring the function automatically. > > It should show history and let me see the differences. > > In other words, take Tortoise and merge that product into pgAdmin so I have > one product instead of two. 2. Are you will to sponsor such development? Sincerely, Joshua D. Drake > > > Jon > > -----Original Message----- > From: Brad Lhotsky [mailto:lhotskyb@mail.nih.gov] > Sent: Thursday, October 25, 2007 9:13 AM > To: Roberts, Jon > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] subversion support? > > You could setup a subversion commit hook to export the functions to the > database. > > Then you adjust your development mentality to: > > 1) Edit the files on the disk > 2) Commit to Subversion > > Then the hook takes over and runs the drop/create automatically, you > could even have it email the developer if the create failed. > > > Roberts, Jon wrote: >> Robert, that does sound better. It keeps the names of the files in svn >> consistent with the database object names which is essential. It also > makes >> it automatic. Unfortunately, it doesn't tell you who did the changes. >> >> Do you want to share that code? >> >> >> Thanks! >> >> >> Jon >> >> -----Original Message----- >> From: Robert Treat [mailto:robert@omniti.com] >> Sent: Wednesday, October 24, 2007 10:24 PM >> To: pgsql-general@postgresql.org >> Cc: Roberts, Jon >> Subject: Re: [GENERAL] subversion support? >> >> On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: >>> Yeah. I think having to save the function to disk and then leave pgAdmin >>> to execute subversion commands is going through hoops. >>> >>> Also, pgAdmin should be integrated so that you are notified if the >> function >>> in the database is different from the last committed version. A visual >>> diff should be there so you can see what the differences are. >>> >> We have a script that runs nightly that dumps tables / functions to file, >> and >> then checks it in automagically to svn, which sends an email of the diffs. > >> Perhaps that would work for you? >> >
I not sure I follow the question about SQL Navigator and Toad. When you edit a function, package, procedure, trigger, etc, it will notify you via a pop-up window if there is a difference in the committed version and the database version. You can then click "show differences" and then it pops up another window with your typical code differences window. When you are done revising the code, you then commit it to the repository in the tool with a click of a button. So the long story short I'm getting is, "no it is not on the radar". This is terribly ironic given the fact that pgAdmin is developed using source control but the code you write with the tool doesn't have any hooks into source control. Jon -----Original Message----- From: Tino Wildenhain [mailto:tino@wildenhain.de] Sent: Thursday, October 25, 2007 11:03 AM To: Roberts, Jon Cc: pgsql-general@postgresql.org Subject: Re: [GENERAL] subversion support? Hi, Roberts, Jon schrieb: > I could use psql instead of pgAdmin then which isn't what I want. > > Having used Quest software SQL Navigator since 97 for Oracle and then > migrated to Toad for Oracle which both products have integration to source > control, it is hard to revert back to a command line or text file solution. Well you can still use gui tools and just let them work against a development database. With little scripting you can just dump the schema of that database periodically and check it in to SVN. Hook scripts can then take over the deployment (ideally based on tag creation) > > pgAdmin should graphically show differences between the committed version > and the database. Does SQL Nav do this? At least the SQL Navigator/Toad support seems to heavily depend on server side code to help. This looks very unclean to the very least. > It should allow me to click a button in the tool and commit it to the > repository. > > It should allow me to revert back to a previous version and the tool take > care of restoring the function automatically. You can test before you commit in the database - unlike Oracle, Postgres supports transactions even for DDL :-) (ok, I've yet find the button in pgadmin to disable auto commit :-) Regards Tino
No I haven't. Thanks for the tip. Jon -----Original Message----- From: Reg Me Please [mailto:regmeplease@gmail.com] Sent: Thursday, October 25, 2007 11:25 AM To: pgsql-general@postgresql.org Cc: Tino Wildenhain; Roberts, Jon Subject: Re: [GENERAL] subversion support? Ever tried Druid? http://druid.sourceforge.net/ Il Thursday 25 October 2007 18:02:51 Tino Wildenhain ha scritto: > Hi, > > Roberts, Jon schrieb: > > I could use psql instead of pgAdmin then which isn't what I want. > > > > Having used Quest software SQL Navigator since 97 for Oracle and then > > migrated to Toad for Oracle which both products have integration to > > source control, it is hard to revert back to a command line or text file > > solution. > > Well you can still use gui tools and just let them work against a > development database. With little scripting you can just dump > the schema of that database periodically and check it in to SVN. > > Hook scripts can then take over the deployment (ideally based > on tag creation) > > > pgAdmin should graphically show differences between the committed version > > and the database. > > Does SQL Nav do this? At least the SQL Navigator/Toad support seems > to heavily depend on server side code to help. This looks very unclean > to the very least. > > > It should allow me to click a button in the tool and commit it to the > > repository. > > > > It should allow me to revert back to a previous version and the tool take > > care of restoring the function automatically. > > You can test before you commit in the database - unlike Oracle, Postgres > supports transactions even for DDL :-) (ok, I've yet find the button > in pgadmin to disable auto commit :-) > > > Regards > Tino > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster
On Thu, Oct 25, 2007 at 11:35:32AM -0500, Roberts, Jon wrote: > Complaint? Who is complaining? > > I am simply asking if this feature that is rather common in other database > development tools will ever be added to pgAdmin. Why are you then asking on a *PostgreSQL* list ? > And no, I will not sponsor such development. Which means you'll have to be content with a "No, not in the foreseeable future lest unforeseeable things happen." Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Roberts, Jon wrote: > > When you edit a function, package, procedure, trigger, etc, it will notify > you via a pop-up window if there is a difference in the committed version > and the database version. You can then click "show differences" and then it > pops up another window with your typical code differences window. Wouldn't the fact that the thing has been edited suggest that it has, indeed, been changed? Of course, having a diff pop up in your GUI package of choice would be nice if that's your favoured way to work. > When you are done revising the code, you then commit it to the repository in > the tool with a click of a button. > > So the long story short I'm getting is, "no it is not on the radar". This > is terribly ironic given the fact that pgAdmin is developed using source > control but the code you write with the tool doesn't have any hooks into > source control. About as ironic as any other random software package/project that also uses version control in development not having those hooks. brian
> ------- Original Message ------- > From: "Roberts, Jon" <Jon.Roberts@asurion.com> > To: pgsql-general@postgresql.org > Sent: 25/10/07, 17:35:32 > Subject: Re: [GENERAL] subversion support? > > Complaint? Who is complaining? > > I am simply asking if this feature that is rather common in other database > development tools will ever be added to pgAdmin. pgAdmin II had change control. No-one ever really used it though so we never bothered to implement it in pgAdmin III. Regards, Dave
Roberts, Jon wrote: > So the long story short I'm getting is, "no it is not on the radar". This > is terribly ironic given the fact that pgAdmin is developed using source > control but the code you write with the tool doesn't have any hooks into > source control. Actually, it is on my personal radar. But beware that I have a very very longrange radar, and I have a lot of things that sit much higher up on my priority list. //Magnus
"Dave Page" <dpage@postgresql.org> writes: >> Complaint? Who is complaining? >> >> I am simply asking if this feature that is rather common in other database >> development tools will ever be added to pgAdmin. > > pgAdmin II had change control. No-one ever really used it though so we never > bothered to implement it in pgAdmin III. Note that most database admins I've seen use change control by making a series of sql files with all the definitions they need to recreate the tables. They then use those sql files to drive the database, rather than the other way around. So you just need to track those sql files in your revision control system, and they're just plain text. The situation is complicated somewhat by the SQL "ALTER TABLE" and so on commands which you need to use instead of just reissuing the CREATE TABLE command. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On 10/25/07, Gregory Stark <stark@enterprisedb.com> wrote: > "Dave Page" <dpage@postgresql.org> writes: > > >> Complaint? Who is complaining? > >> > >> I am simply asking if this feature that is rather common in other database > >> development tools will ever be added to pgAdmin. > > > > pgAdmin II had change control. No-one ever really used it though so we never > > bothered to implement it in pgAdmin III. > > Note that most database admins I've seen use change control by making a series > of sql files with all the definitions they need to recreate the tables. They > then use those sql files to drive the database, rather than the other way > around. So you just need to track those sql files in your revision control > system, and they're just plain text. > > The situation is complicated somewhat by the SQL "ALTER TABLE" and so on > commands which you need to use instead of just reissuing the CREATE TABLE > command. that's what I do. The fact that I can wrap my entire change control script in begin / commit pairs means I don't have to worry about ruining production if one step goes wrong. Unlike some other large, expensive, commercial databases. I like the idea of easy, SVN controlled DDL. I'm just not sure it's likely to be as easy as we wish when moving from dev to test to production.
> ------- Original Message ------- > From: Gregory Stark <stark@enterprisedb.com> > To: "Dave Page" <dpage@postgresql.org> > Sent: 25/10/07, 19:06:12 > Subject: Re: subversion support? > > The situation is complicated somewhat by the SQL "ALTER TABLE" and so on > commands which you need to use instead of just reissuing the CREATE TABLE > command. From memory, pga2 used to log the reverse engineered DDL after a change, as well as the SQL used to make that change. Itthen allowed you to generate scripts to update your production schemas from one version to another. It also allowed youto view the history for an object, and rollback to a previous version. Dropped objects were logged in the 'graveyard'from where they could be resurrected. /D
That is awesome. Can it be added to pga3? Jon -----Original Message----- From: Dave Page [mailto:dpage@postgresql.org] Sent: Thursday, October 25, 2007 2:11 PM To: Gregory Stark Cc: Roberts, Jon; pgsql-general@postgresql.org Subject: Re: subversion support? > ------- Original Message ------- > From: Gregory Stark <stark@enterprisedb.com> > To: "Dave Page" <dpage@postgresql.org> > Sent: 25/10/07, 19:06:12 > Subject: Re: subversion support? > > The situation is complicated somewhat by the SQL "ALTER TABLE" and so on > commands which you need to use instead of just reissuing the CREATE TABLE > command. From memory, pga2 used to log the reverse engineered DDL after a change, as well as the SQL used to make that change. It then allowed you to generate scripts to update your production schemas from one version to another. It also allowed you to view the history for an object, and rollback to a previous version. Dropped objects were logged in the 'graveyard' from where they could be resurrected. /D
Roberts, Jon wrote: > That is awesome. Can it be added to pga3? Like I said - it wasn't implemented in pga3 because noone used it in pga2 except for (as far as I know), the team I was working with at the time. As I recall we polled the mailing lists before dropping it and noone said they wanted to keep it, nor did anyone complain about it being missing in pga3. Unless there are a decent number of people that would actually use it now, I'm reluctant to spend the time on a feature that would simply add to the maintenance burden. Regards, Dave
Hi Dave, Dave Page schrieb: > >> ------- Original Message ------- >> From: "Roberts, Jon" <Jon.Roberts@asurion.com> >> To: pgsql-general@postgresql.org >> Sent: 25/10/07, 17:35:32 >> Subject: Re: [GENERAL] subversion support? >> >> Complaint? Who is complaining? >> >> I am simply asking if this feature that is rather common in other database >> development tools will ever be added to pgAdmin. > > pgAdmin II had change control. No-one ever really used it though so we never bothered to implement it in pgAdmin III. But it was implemented differently then the proposal above. One way to implement it as easily as possible would be the ability to link editor windows to file on disk, where you could have the file version controled and changes to the file would show up immediately in the edit window where edits in the window could (with small delay) auto saved to the file. This way you need not change pgadmin much while you can use cvs/svn on your file system to do the VC stuff. "only" a clever way for mapping (maybe based on object type) configuration and the change detection (file notify, FAM, ...) (the latter depending on the OS unfortunately) Regards Tino
Hi Tino Tino Wildenhain wrote: > Hi Dave, >> pgAdmin II had change control. No-one ever really used it though so we >> never bothered to implement it in pgAdmin III. > > But it was implemented differently then the proposal above. I'm not sure the detail of how it was implemented was a huge factor in the fact that few people used it. People tend to complain if a feature is there but they don't like the way it is designed - they didn't in this instance. > One way to implement it as easily as possible would be the ability > to link editor windows to file on disk, where you could have > the file version controled and changes to the file would show > up immediately in the edit window where edits in the window > could (with small delay) auto saved to the file. > > This way you need not change pgadmin much while you can use cvs/svn > on your file system to do the VC stuff. Yeah, but the most useful feature of such a system is to provide a 'diff' to allow a schema to be patched to a new version. To do that, you need to store not only the object definition, but the changes made to get to that state - ie. a bunch of ALTER statements instead of a traditional diff. Unless you're going to provide that sort of functionality (which I believe would be difficult with a traditional SCMS), you might as well just script a regular 'pg_dump --schema-only && svn commit' Regards, Dave.
On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: > Yeah. I think having to save the function to disk and then leave pgAdmin > to execute subversion commands is going through hoops. > > Also, pgAdmin should be integrated so that you are notified if the function > in the database is different from the last committed version. A visual > diff should be there so you can see what the differences are. > We have a script that runs nightly that dumps tables / functions to file, and then checks it in automagically to svn, which sends an email of the diffs. Perhaps that would work for you? -- Robert Treat Database Architect http://www.omniti.com
Robert, I'd like to have a copy of your script if you're willing to share. We're currently working on schema control stuff, and your script may be useful. On Wed, Oct 24, 2007 at 11:23:39PM -0400, Robert Treat wrote: > On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: > > Yeah. I think having to save the function to disk and then leave pgAdmin > > to execute subversion commands is going through hoops. > > > > Also, pgAdmin should be integrated so that you are notified if the function > > in the database is different from the last committed version. A visual > > diff should be there so you can see what the differences are. > > > > We have a script that runs nightly that dumps tables / functions to file, and > then checks it in automagically to svn, which sends an email of the diffs. > Perhaps that would work for you? > > -- > Robert Treat > Database Architect > http://www.omniti.com > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- Tim Goodaire 416-673-4126 tgoodair@ca.afilias.info Database Team Lead, Afilias Canada Corp.
On Nov 6, 2007, at 3:43 PM, Tim Goodaire wrote: > Robert, > > I'd like to have a copy of your script if you're willing to share. > We're > currently working on schema control stuff, and your script may be > useful. > > On Wed, Oct 24, 2007 at 11:23:39PM -0400, Robert Treat wrote: >> On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: >>> Yeah. I think having to save the function to disk and then leave >>> pgAdmin >>> to execute subversion commands is going through hoops. >>> >>> Also, pgAdmin should be integrated so that you are notified if >>> the function >>> in the database is different from the last committed version. A >>> visual >>> diff should be there so you can see what the differences are. >>> >> >> We have a script that runs nightly that dumps tables / functions >> to file, and >> then checks it in automagically to svn, which sends an email of >> the diffs. >> Perhaps that would work for you? Btw, the latest version of AquaData has built in Subversion and CVS clients. Erik Jones Software Developer | Emma® erik@myemma.com 800.595.4401 or 615.292.5888 615.292.0777 (fax) Emma helps organizations everywhere communicate & market in style. Visit us online at http://www.myemma.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would be interested as well. Our changes are perhaps once or twice a week in development but its nice to make sure that its being tracked. Mario Tim Goodaire wrote: > Robert, > > I'd like to have a copy of your script if you're willing to share. We're > currently working on schema control stuff, and your script may be useful. > > On Wed, Oct 24, 2007 at 11:23:39PM -0400, Robert Treat wrote: >> On Wednesday 24 October 2007 15:11, Roberts, Jon wrote: >>> Yeah. I think having to save the function to disk and then leave pgAdmin >>> to execute subversion commands is going through hoops. >>> >>> Also, pgAdmin should be integrated so that you are notified if the function >>> in the database is different from the last committed version. A visual >>> diff should be there so you can see what the differences are. >>> >> We have a script that runs nightly that dumps tables / functions to file, and >> then checks it in automagically to svn, which sends an email of the diffs. >> Perhaps that would work for you? >> >> -- >> Robert Treat >> Database Architect >> http://www.omniti.com >> >> ---------------------------(end of broadcast)--------------------------- >> TIP 5: don't forget to increase your free space map settings > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMcK2Wo7/TvkZs+IRAh3OAJ99c7oYoRjo4N3PpgcCBs2R5xX0CwCfQ+5b yhL6Eldt6tug6qnYmCAHRDs= =dkj2 -----END PGP SIGNATURE-----