[ 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 <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]> Secrets of the Weird <[EMAIL PROTECTED]> _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs