On Thu, Dec 15, 2011 at 4:18 PM, David Vaillancourt
<david_v@sympatico.ca> wrote:
> The changes to the plugin framework I intend to implement would keep the
> existing functionality, but add to it also.
> Please let me know if this is an avenue I should drop, as I will find an
> alternative ... It do not want to work against the PGadmin team.
That's fine with me, assuming the changes you wish to make will fit
into that model cleanly.
> As for the workflow you describe to track Schema versions, this is the way
> we do things right now.
> So here are my questions:
>
> * How do you manage incremental scripts numbering for multiple developers
> working on the same DB Schema?
The same way as any of the other code in the repo. When a developers
work is finished, reviewed and then committed, the guys working in
parallel will just do a pull and rebase their work over the latest
changes. That may not be practical with hundreds of developers, but
there typically aren't more than 7 or 8 developers at most working on
this project, so there's little coordination required beyond git
push/pull/rebase.
> * Once a developer creates an incremental script, who/how do you modify the
> original creating script to reflect these new changes (ex: pemserver.sql)?
Manually. If they've added some new columns to a table the upgrade
script will contain ALTER TABLE statements, whilst the CREATE TABLE
statements in pemserver.sql will get the additional columns added. On
a couple of occasions (for example, when updating 237 SQL objects we
call probes) that gets a touch tedious, but the vast majority of the
time it's a non-issue.
> * If developer A has pending modifications but another developer B has
> commited changes to the schema since, how does developer A make sure he is
> not going to overwrite changes made by A? This especially problematic for
> stored procedures code that is modified by developers (for us anyways)
Typically developer A will just do a "git pull". If there are merge
conflicts then he may need to do a "git stash" first, and then "git
stash apply" to re-apply his changes, fixing any conflicts manually.
If he's already committed to his local repo, git detects the conflicts
and A can manually fixup them up and commit the result, then push it
back to the central repo when he's done.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company