Velocity Reviews - Any interest in source code repository module/drivers modeled afterDBI?

At a job site a long time ago in a galaxy far, far away, a team labored
and toiled to use Perl as a build/deploy management framework to build
and deploy large J2EE apps calling external tools such as Ant to do the
dirty work. Perl was the framework driver and all the little tools were
the robot wenches...

Turns out, the company requiring work on the DeathStar project mandated
we use their source code repository, but couldn't decide at the time
what source code repository it was going to stay with and during the
first part of the project we changed SCR's 3 times! So when we went to
version 2 of the project, I decided to use a little Jedi/Perl magic and
wrote the pieces in the overall build/deploy framework to get, put,
checkin, checkout, label, etc. code from SCR in a generic way, modeled
after DBI. I was determined that one should never have to know the
underlying SCR tool for basic SCR functions just like for DBI (add,
update, delete records, etc). If Darthy baby asked us to change the SCR
again, we would just write the driver for the new SCR and the code above
would never have to change.

I've been sitting on this code for a while now. I have the SCR
framework, which I called simply "SCR" (like "DBI") that loads an
appropriate underlying SCR "driver" for VSS, CVS, Subversion, MKS, PVCS,
etc. and, as I said, abstracts a consistent call interface to Perl for
scripts to use. Before I do the work to release it into open source, I
just wonder if there is any interest in something like this? Since I
modeled it after DBI, I think it would be the approiate thing to
publicly release this code as well, but if no one cares, then I don't
want to take the time and effort to do it.

Additionally, I only have a VSS driver written and some CVS driver code
written. I have no driver code written for anything else (PVCS,
Subversion, MKS, etc.), but that's the beauty of the design and open
source. Someone can come along and write the appropriate driver for
other third party SCR engines.

Scant examples:

## Connect format is basically:
## SCR->connect( driver-sig, username, password, [specific options] );

my $scr = SCR->connect( 'scr:vss', 'chris', 'perlr0cks', SSDIR =>
"blah", REPOSITORY => "c:\\My\\Repository" );

## or

my $scr = SCR->connect( 'scr:cvs', 'chris', 'perlr0cks', PSERVER =>
"blah" ); # Or something like this; I have to check my CVS implem.
my $scr = SCR->connect( 'scr:cvs', 'chris', 'perlr0cks', CVSROOT =>
"blah" ); # Or something like this; I have to check my CVS implem.

## Then, methods are basically:
## $scr->method( general options first, any SCR specific opts last );
## (And overall, I've been quite able to avoid the later).

$scr->add( blah options );
$scr->get( blah options );
$scr->put( blah options );
$scr->checkin( blah options );
$scr->ci( blah options ); # Synonym for checkin()
$scr->checkout( blah options );
$scr->co( blah options ); # Synonym for checkout()
$scr->label( blah options );
$scr->remove( blah options );
....etc...

(Okay, I have to admit, I modeled a lot of the method names after CVS
command names...!)

Speak up here if anyone wants me to go ahead with this or you can
contact me at "PerlJunkie" on GMail. It's been great using SCR, and I
thought maybe others would like this?

(One can even, using this module, build a project over multiple
repository types, say CVS and PVCS, and never even know the difference.
It also helps make absolutely horrible software like VSS "appear" to
behave halfway decently since Perl can abstract things like recursive
labeling -- native VSS has horrible labeling options among other things!
-- when the underlying SCR doesn't really support it.)

-ceo