peg: review tool review request

I've been working for years now on various scripts to automate setting 
up test installs of PostgreSQL for everything from patch to performance 
testing.  This month I pulled them all together into one unified 
framework I've named "peg", and it's now available on github:  
http://github.com/gregs1104/peg/  I thought this list was a good subset 
of people to announce it to initially, as I think it's ideal for 
reviewing one or more patches efficiently.

Basically, you create a single directory to put all your PostgreSQL work 
into (if you name it "pgwork" it will automatically find it even), and 
the script can do everything else needed to grab a repo, build a 
cluster, and start the database.  You get a subdirectory for each of the 
main components in a PostgreSQL install (source code, binaries, data) 
and another underneath those for each project .  Here's how simple you 
can get going with CVS:

cd
mkdir -p pgwork
peg init test
. peg build
psql

That's it; you'll get a standard debug/assert enabled source build from 
the master PostgreSQL repo, with a checked out copy you can apply 
patches to and tinker with, and you'll have the usual PGDATA/PGLOG 
environment variables exported to your shell along with a PATH having 
the new binaries in front.

Once you've got the environment setup, it's this easy to get back into 
it again after something like a reboot:

. peg switch

It will remember what project name you told it to use last, start the 
server, and off you go again.  It tries very hard to guess what you want 
it to do and just take care of it, while still allowing that behavior to 
be overridden.  I also provide simple aliases like "start" and "stop" to 
do routine server cycling, without even running the big script.  At this 
point you might be thinking this is only a hundred or two lines of 
code.  Not even close; it's filled with every little workflow 
optimization, good default, and detection method I know in this area.  
There's 64 distinct if statements alone, each of which tries to detect 
and guess some behavior.

I also support git and a simple tarball file as repo sources.  Amusing 
for a project hosted at github, the git support is probably the weakest 
of the three right now.  I'm not 100% happy with how I handle that just 
yet, I've been offline and working mainly with the alpha2 .tgz for much 
of the recent development.  The documentation is pretty comprehensive 
already, and I do note which of the examples provided I've tested or 
re-tested recently and which haven't been (and therefore might have 
problems).

The code is a little raw still, is probably filled with bash and Linux 
isms, and it might take you a minute to see how it all fits together.  
But I think you'll find a time savings very soon if you try it out.  And 
since I'll be living inside the environments it generates for the near 
future, you can be sure I'll eventually get all the bugs out of there.

-- 
Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com  www.2ndQuadrant.com