I tend to agree.  In my recent CVS project, I just went through
an exercise where I created an abstraction layer above all the
triggers currently available in CVS, to create such a consistent
interface.  If the existing interface were more consistent, it
would have saved me some work.

Each of the perl scripts which are called directly by triggers
in commitinfo, verifymsg, taginfo, loginfo, etc., first coalesce
all the available data into a generalized perl hash, then the
hash (reference, actually) is passed to various routines which
live in common perl modules.

The standardization comes in two ways: all calls are hash
references, and the set of keys for the hash have a consistent
naming scheme.

Ultimately, my goals are to (1) mirror meta data (no deltas)
in an MySQL database, and most importantly (2) branch management.

Initially, there are two main entry points which live in the
common module, one to permit or deny an operation, and the
other to log the meta data.  The meta data schema is presently
represented as an XML blob in the database, to be parsed later,
asynchronously from the operation involved, analogous to an
interrupt routine in a device driver.

However, even the abstraction layer I've created isn't nearly
as general as what Noel describes.  But the system he envisions
could easily be incorporated into mine for even greater control,
if that were ever to become necessary.  Right now, I'm mostly
concerned about commit and tag operations, the two biggies in
terms of modifications to the repository (also, restrict who
can perform imports).

wade


Noel L Yap wrote:
> 
> Here we go again.  IMHO, ideally there should be a consistent framework for
> creating CVS command triggers.  This would include:
> 1. consistent inputs to the scripts
> 2. _one_ file that would describe which module(s) the script is for, which
> trigger (pre or post; file, directory, or command; and CVS subcommand) the
> script is for, and the name of the script
> 
> Once such a framework has been created, it should be trivial to create new
> trigger hooks (if so deemed nice) to the other existing CVS commands.
> 
> Noel

Reply via email to