Re: Triggers (was Re: CVS diff and unknown files.)

[Greg A. Woods]

[ On Friday, January 28, 2005 at 03:26:05 (-0800), Paul Sander wrote: ]
> Subject: Triggers (was Re: CVS diff and unknown files.)
>
> Sigh.  Just because you haven't found a use for add-time triggers 
> within the scope of your blinders, doesn't mean that no one has.

You don't seem to understand.

A new file, from the repository's point of view, thus from any
repository policy point of view, does not exist until commit time.

The existing commitinfo hooks are more than adequate enough to enforce
any repository policy on the new file, be it by name, or by content.

(my own commitinfo scripts check that the new file has a proper RCS Id,
for example)


> Also, wrappers are not always the answer.

Wrappers are always the answer when you want to do something policy
related in the working directory.  THEY MUST BE.  The core CVS program,
by design, does not involve itself in policy matters affecting the
working directories.  The core CVS program is not a complete SCM
platform.


> Are you arguing here that I should not be using triggers, or that I 
> should not be using CVS?

If your developers are so lazy, ill informed, or antagonistic of their
fellow workers, that your shop needs every little move they make, even
in their working directories, mediated by some policy-enforcing
big-brother overseerer, then CVS is _NOT_ the right tool for your shop.


> - Wrappers can be subverted by the users, sometimes accidentally, 
> sometimes deliberately.

If your users are so lazy, ill informed, or antagonistic of their fellow
workers, that your shop worries about users subverting "wrapper"
programs, even accidentally, then CVS is _NOT_ the right tool for your
shop.

> - Some users must be kept away from certain features.

If your users are so lazy, ill informed, or antagonistic of their fellow
workers, that your shop worries about users accessing certain features,
even accidentally, then CVS is _NOT_ the right tool for your shop.

> - Access to certain features must be restricted conditionally upon the 
> user's specific task.

If your users are so lazy, ill informed, or antagonistic of their fellow
workers, that your shop worries about users accessing certain features,
even accidentally, then CVS is _NOT_ the right tool for your shop.

> - In client/server environments, certain actions must be performed in 
> the context of the server, not in the context of the user.

Any wrapper script can also contact the server.  Write a client/server
wrapper scripting environment -- it's trivial to do.

>  The 
> security model is such that access to the server is given only to 
> certain trusted applications.

Either make the wrapper a trusted application, or brainwipe your
security officer and go find one who actually knows a thing or two about
computer security, instead of one who simply reads the "Idiots" books.


> - Wrappers can only add functionality.  They cannot remove or limit 
> existing functionality.

WRONG.  Wrapper programs can trivially prevent or mediate all
functionality.

> - Wrappers cannot utilize or control primitive operations at a lower 
> level than the command line.

Not my problem!  ;-)

But, yes, they can -- you have the source.

Your "wrapper" could very easily be any new client front-end that talks
to the server, perhaps over multiple channels even.

-- 
                                                Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>