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

[Greg A. Woods]

[ 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 <address@hidden>
Planix, Inc. <address@hidden>          Secrets of the Weird <address@hidden>