[ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander wrote: ] > Subject: Re: Triggers (was Re: CVS diff and unknown files.) > > But you fail to > understand the problem.
I understand the problem perfectly. You don't seem to understand the fact that "cvs add" and "cvs rm" are supposed to be exactly the same as "vi" or any other file modification tool (except they operate on the whole file and all its content at once). You don't seem to understand that your insanely powerful drive to have policy controls over everything is quite contrary to the very design goals of CVS overall. CVS is _NOT_ a complete SCM solution and it's not supposed to try to be one either. If you think "cvs add" (or "cvs rm") should invoke "addinfo" and "rminfo" scripts on the server then you are using the wrong tool. > Wrappers are enablers, not enforcers. By their nature, they cannot be > enforcers. Yes, they can be. You need to think a little more outside the box you've built around your ideas. > Triggers, on the other hand, are enforcers. Actually that's one thing they cannot be -- at least not at any hard technical controls level. CVS is not a security tool. CVS is not about enforcing policy. CVS is not a complete SCM solution. CVS is a very simple file versioning tool that is designed to keep as much out of the way of the user as is possible and only do exactly what the user wants, and to do it only when the user wants it done, and to only try to do a very select set of operations on a very select set of object types. NOTHING more. If you want more and you think CVS should give you more then you're trying to use the wrong tool for the job. > Tell me something. If this were true, why does your commitinfo check > for valid RCS ID's? Why don't you periodically run a script to check > your sources for them? Because it's easier and infinitely more efficient to have CVS run that script exactly once when it's needed on exactly the files it needs to run it on and never any other time and never on any other files. It's just a reminder though -- it can be foiled, or disabled on purpose for certain files if necessary. > Here's another horror story. On another project, we're using a version > control system that has a command that does what "cvs rm" does, but > with an instant commit. It also has an option to perform a recursive > descent. Why is that a "horror story"? The whole point of versioning systems is that you can undo your changes. After all you didn't say that the command did what "rm -rf /*" does when root runs it -- i.e. it didn't make a permanent, irreversible, change that affected everyone. > The CM guy for that > project was concerned about such capability in the hands of the end > users, and raised the issue with management about whether or not to > make it an admin function. Than he is, or was at that time, a paranoid idiot who doesn't, or didn't, understand the tools and their utility. > It took them a day to > restore visibility of all of the files, and a week to redo the > legitimate deletions that had accumulated. Clearly that tool wasn't very well designed and implemented to do even the very most basic job of change management. > CVS suffers the same vulnerability. Forgive me for thinking your > argument is bogus, because experience proves otherwise. "vulnerability"? Next you'll say that "vi" suffers the same vulnerabilty too because it's just too easy to delete all the lines in a file with one tiny command. B.S. Many commonly used filesystems suffer the same vulnerabiltiy too -- and quite often CVS repositories live on such filesystems. OOH! The world is such a dangerous and scary place -- we'd better just hide and do nothing! > So, what you're recommending is that I rewrite the CVS server to fix my > problem. No, just the client. You might want to add other supplementary server-like programs that run on the server to go along with CVS, and they might be invoke by your new client. -- 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