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

[Paul Sander]

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

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

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.

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

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.