[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Sander
Subject: Re: Triggers (was Re: CVS diff and unknown files.)
Date: Wed, 2 Feb 2005 02:43:43 -0800

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

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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]