Re: CVS_USER

[Laird Nelson]

"Derek R. Price" wrote:
> Also, it sounds like with this method large lists would be processed and
> placed in the environment regardless of whether the child was going ot
> use them or not.  i.e. CVS could go through and place a 1000 item list of
> filenames in the environment for a script called from taginfo even though
> the script was only going to check whether the user was on a list of
> admin users.

Each script fired by a commit support file is fired once per directory. 
So in the usual case, where people don't store 1000 files in a single
directory, this would be a non-issue.

Put me down for +1 in favor of either (a) putting this information in
the environment so I don't have to remember what arguments go where or
(b) loading my commitinfo scripts via dlopen() or some other dynamic
in-core solution.  Given the current architecture I'm more in favor of
(a).

Actually I'd be most in favor of writing a pserver implementation in
perl and dynamically including perl modules, but that's a whole
different story :-) :-) :-)

The project I'm working on at
http://sourceforge.net/projects/cvssupport/ lets you write perl modules
that override methods to handle parts of the commit process.  If you
need some piece of information, like a filename or an old revision, or
what the best guess is as to what the new revision number will be, and
so on, you call the appropriate method, which defers looking that
information up as late as possible.  The nice thing about this approach
is that regardless of what the scripting interface turns out to be
(environment vs. DerekPatch (tm)), I can still keep a simple interface
into something most sysadmins are used to, viz. perl modules.

So you do this:

  sub commit() {
    my $self = shift;
    if ($self->get_filename() ne 'foobar.txt' &&
        $self->get_old_revision() ne '2.4') {
      # vote for rejection of the commit based on this
      # silly conditional
      return 0;
    }
  }

...instead of writing a shell script or something else that parses
through argument lists.

Speed, incidentally, is less important to me, FWIW, on tools like this;
by the time I commit or tag something I'm psychologically resigned to
its taking a long time anyway (I'm done doing whatever I was doing,
after all), and as far as space and memory go, the cvs repository binary
is usually running on a big fat server anyway.  I'd be much more in
favor of loading the environment (or whatever) up with a lot of info,
rather than putting it on demand in odd places.

Cheers,
Laird