[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Triggers (was Re: CVS diff and unknown files.)
Re: Triggers (was Re: CVS diff and unknown files.)
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
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
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
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
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
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
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
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
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
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
address@hidden | ones" -- William Brown