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

[Paul Sander]

On Feb 1, 2005, at 12:03 PM, address@hidden wrote:

> [ On Saturday, January 29, 2005 at 15:22:34 (-0800), Paul Sander 
> wrote: ]
> > Subject: Re: Triggers (was Re: CVS diff and unknown files.)

> 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).

What I understand is that they are that way, and that they have always 
been that way.  I might even accept the argument that they're "supposed 
to" be that way.  What I will not accept is that they *must* be that 
way, and I argue that there is value if they are changed.

> 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.

I do not have an insanely powerful drive to have policy controls over 
everything.  I have strong desire to have some control over things that 
meet one of these two criteria:
- By consensus, they offer significant advantage in time and expense.
- They are demonstrably harmful, i.e. have been used to cause 
significant harm in the past.

> CVS is _NOT_ a complete SCM solution and it's not supposed to try to be
> one either.

Adding triggers won't make it a complete SCM solution.  But they would 
make it easier to integrate it with other tools to create one.  That is 
what I'm after.

> > 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.

Okay suggest a way to do it that's easier than adding a trigger to CVS.

> > 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.

I'm not asking CVS to be a security tool.  I'm asking for more places 
for it to say "no" when users attempt things that are not permitted by 
the project.

> CVS is not about enforcing policy.  CVS is not a complete SCM solution.

Obviously not, that's why we're having this argument.

> 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.

Fine.  Give me the hooks I need and I'll make it into what I need it to 
be.

> > 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.

Yep, that's what I want, too.  I just have different actions that I 
want to perform.

> > 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.

True, but it did make a temporary, reversible change that affected 
everyone.  And it took hundreds of man-hours to recover.  TWICE!!!  
This is not acceptable.

> >  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.

Really?  In CVS, the corresponding actions are to run "cvs add" on 
every file found in the attic, review the tree, and run "cvs rm" for 
the files that had been legitimately removed prior to the hiccup.  Had 
we used CVS, we would have been in exactly the same boat.  If we'd had 
the ability to limit the effect of the removal command, we could have 
either forced the user to rethink what they were doing or at least 
reduce the amount of work required for recovery.  That would have been 
good.

There are many ways we could have limited the effects of the removal 
that would have not gotten in the user's way, at least to a lesser 
degree than the amount of work required to recover.  We could have:
- Disabled the recursive descent option for end users (i.e. have an 
admin do it).
- Limited the depth of the removal.
- Limited the height (from the leaf nodes) of the directory that the 
user could remove.
- Limited the set of removable directories to those owned by the user.
- Limited the set of removable directories to those meeting certain 
criteria in the design.

Most of these would have allowed the user to accomplish what they 
really wanted without supervision, had they been in the right place to 
start with.  All of them would have given the user enough pause to 
realize that something bad was about to happen.

> > 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.

There's a difference between hiding 10000 files in the attic and 
deleting 10000 lines in an editor.  In the latter case, recovery is 
quick and cheap, and you only have to worry about recovering your own 
work.  In the former case, the recovery is slow and expensive, and the 
whole project stops while you do it.

So, no, I would not make that specific complaint about vi.  The scope 
of such a mistake, while unpleasant for someone, isn't worth my 
attention.

> 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!

Actually, I don't even have to worry about that.  All I have to do is 
wait for the warranty on the disks to run out.

--
Paul Sander       | "Lets stick to the new mistakes and get rid of the 
old
address@hidden | ones" -- William Brown