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.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
