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(at)2ndQuadrant(dot)com www.2ndQuadrant.com