[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: Sat, 29 Jan 2005 15:22:34 -0800

On Jan 28, 2005, at 3:55 PM, address@hidden wrote:

[ On Friday, January 28, 2005 at 03:26:05 (-0800), Paul Sander wrote: ]
Subject: Triggers (was Re: CVS diff and unknown files.)

Sigh.  Just because you haven't found a use for add-time triggers
within the scope of your blinders, doesn't mean that no one has.

You don't seem to understand.

A new file, from the repository's point of view, thus from any
repository policy point of view, does not exist until commit time.

The existing commitinfo hooks are more than adequate enough to enforce
any repository policy on the new file, be it by name, or by content.

(my own commitinfo scripts check that the new file has a proper RCS Id,
for example)

I understand perfectly what you're saying and why. But you fail to understand the problem. I'm not talking about anything from the repository point of view; my arguments are from the user's and project manager's point of view. Using naming conventions as an example, it's true that at the point the project ships, it doesn't matter from a quality for feature perspective when a defect was found and fixed, as long as the policy is checked sometime before the release.

What I'm talking about is something else: The cost to fix defects. Once again, history has shown that defects found early are easier, faster, and cheaper to fix than defects that are found late. If someone creates a new file and spends a day integrating it into the project only to have it rejected by a commit due to a naming policy violation, then he gets to spend another day fixing the mistake. This is an unnecessary effort if only the developer had found out in the morning that the name of his file was bad rather than in the evening.

Also, wrappers are not always the answer.

Wrappers are always the answer when you want to do something policy
related in the working directory.  THEY MUST BE.  The core CVS program,
by design, does not involve itself in policy matters affecting the
working directories.  The core CVS program is not a complete SCM

Wrappers are enablers, not enforcers. By their nature, they cannot be enforcers. You can automate some process using some script, and you can even mandate its use. But you can't enforce its use because as long as there's something more primitive available the user can drop down and use that instead.

Triggers, on the other hand, are enforcers. They block higher-level functions when their programmed preconditions aren't met, and they force actions when their programmed preconditions are met. Wrappers are simply incapable of this.

- Wrappers can be subverted by the users, sometimes accidentally,
sometimes deliberately.

If your users are so lazy, ill informed, or antagonistic of their fellow
workers, that your shop worries about users subverting "wrapper"
programs, even accidentally, then CVS is _NOT_ the right tool for your

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?

- Some users must be kept away from certain features.

If your users are so lazy, ill informed, or antagonistic of their fellow
workers, that your shop worries about users accessing certain features,
even accidentally, then CVS is _NOT_ the right tool for your shop.

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. (Those who believe that remove/add of entire directory structures is a reasonable implementation of the ability to rename a directory can understand the need for this.) 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.

Every end user of that tool undergoes 2-3 hours of training and is given documentation. They also undergo another 1-2 hours to learn how the tool is tightly integrated with one of our mission critical tools. There are also on-site mentors and online support for the tool. It was on this basis that senior team leads and management crushed the CM guy mercilessly, claiming that no one would possibly be so irresponsible as to use that command in a damaging way.

Within two weeks of that argument, someone used that command at the very top of their source tree. (This person reported directly to the guy who made the responsibility argument.) It took them a day to restore visibility of all of the files, and a week to redo the legitimate deletions that had accumulated. Within a week after completing the recovery, someone else used that command again, at the very top of their source tree.

CVS suffers the same vulnerability. Forgive me for thinking your argument is bogus, because experience proves otherwise.

- Access to certain features must be restricted conditionally upon the
user's specific task.

If your users are so lazy, ill informed, or antagonistic of their fellow
workers, that your shop worries about users accessing certain features,
even accidentally, then CVS is _NOT_ the right tool for your shop.

In our shop, we have visitors to each project who are well-versed in the underlying tools, but not in the higher level ones or the policies that keep the project going. Sometimes they appear silently, and although they're not permitted to save changes, they find that simply populating their workspaces with the latest checked-in versions is incorrect for their purposes. This may be because they're unfamiliar with our branch management or change control policies that define working configurations. Had you read the story that followed my list, you'd understand where this comes from.

- In client/server environments, certain actions must be performed in
the context of the server, not in the context of the user.

Any wrapper script can also contact the server.  Write a client/server
wrapper scripting environment -- it's trivial to do.

Client/server protocols can be easy to build demonstrations for, but they're rarely easy to build for production. If you have such an environment, I'd like to see it because I'm also looking into it. Implementations based on rsh and ssh are not sufficient, particularly if actions taken on the server run with administrator permissions on behalf of the end user.

security model is such that access to the server is given only to
certain trusted applications.

Either make the wrapper a trusted application, or brainwipe your
security officer and go find one who actually knows a thing or two about
computer security, instead of one who simply reads the "Idiots" books.

Our system and network administrators are pretty well versed in the issues. That's why they're paranoid. It's what makes them good at what they do.

- Wrappers can only add functionality.  They cannot remove or limit
existing functionality.

WRONG.  Wrapper programs can trivially prevent or mediate all

Your claim is not true as long as the programs that the wrappers call are available to the end user. Whether mandated or not, users have the option to skip using the tools provided.

- Wrappers cannot utilize or control primitive operations at a lower
level than the command line.

Not my problem!  ;-)

Therein lies the basis of our disagreement.  It IS my problem.

But, yes, they can -- you have the source.

Your "wrapper" could very easily be any new client front-end that talks
to the server, perhaps over multiple channels even.

So, what you're recommending is that I rewrite the CVS server to fix my problem. And I have to write a new client to match. Okay, but what about all those other people who need the same capability? Especially those who need it but don't realize it yet? It's much easier, faster, and cheaper to add it to the existing software and make using it an option.
Paul Sander       | "To do two things at once is to do neither"
address@hidden | Publilius Syrus, Roman philosopher, 100 B.C.

reply via email to

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