Martin Neitzel wrote:
> FYI, this escaped me in the Cederqvist because this special variable
> substitution appeared to me as a regular environment variable with
> its regular $SYNTAX and all the other shell piping / redirecting,
> and quoting being used in the examples.
Yes; IMHO the Cederqvist needs to be updated. I had to be set straight
myself by Larry Jones earlier. :-)
And now, a related tangent (can there be such a thing? :-)):
For anyone (particularly perl folks) who has tried to write backend
scripts that do complicated things (as opposed to simply mailing
something somewhere), I think you'll find my upcoming cvssupport package
useful (http://sourceforge.net/projects/cvssupport/). There will be,
among other things, a program called something like cvs_harness (a perl
program) that you "install" into each of your *info and verifymsg files
like this:
DEFAULT /path/to/cvs_harness --script=commitinfo
--plugin-registry=/some/file ${=PID} $USER
...(that's a commitinfo example). Then you write perl plugins that all
have the same interface. The harness normalizes all of the bizarre
arguments, variable expansions, etc. that go on among the various *info
files.
So remembering, e.g. that taginfo takes five arguments and gets called
once per file but commitinfo gets called with batches of files in the
same relative directory and loginfo gets its log message on STDIN but
verifymsg gets ITS log message in a file in the temp directory are all
things of the past. Instead you write perl like this:
# ... somewhere in your plugin
sub commit() {
my $self = shift;
my $status = 1;
# oo, acl stuff. Read on in the message.
my $acl = new CVSSupport::ACL("some/file.acl");
for ($self->get_file_entries()) {
unless ($acl->check_permission(user => $self->get_user(),
action => $self->get_action(),
file => $_)) {
return 0;
}
}
return $status;
}
...that works on an acl file something like this:
<?xml version="1.0"?>
<cvsacl>
<security-constraint>
<fileset>
<!-- Note the perl 5 regex below -->
<file-pattern>^whackme.txt$</file-pattern>
<revision-pattern>^2\.\d+$</revision-pattern>
</fileset>
<role-name>normal-users</role-name>
<!-- Basically says that normal-users can add, modify and remove
a file named whackme.txt only if the revision
being committed is 2.x (bizarre) -->
<file-action>
<action-name>add</action-name>
<action-name>modify</action-name>
<action-name>remove</action-name>
</file-action>
</security-constraint>
</cvsacl>
The package will have a CVS::ACL plugin which will allow you to
selectively prohibit commits based on pretty much any combination of
(using full perl 5 regular expressions):
* filename
* file's old revision
* file's new revision (where possible)
* file's tag
* tag pattern
* branch names
...as the simple example above indicates. The acl is role-based and
looks surprisingly like the deployment descriptors of Java's J2EE
standard.
I say this is all future because of course I'm working on it in my spare
time at home. :-) I'm about 85% of the way towards a first cut
release; the ACL stuff is working as is the plugin machinery, but there
are various bits that need to be polished up a bit. The whole thing
SHOULD work on rsh/ssh, local and pserver deployments; I haven't tested
using gserver or any of the kerberos-type deployments. It's probably
best used with pserver, as that's what I'm mainly writing it for.
Cheers,
Laird
