Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Thursday, November 18, 2004 at 10:38:44 (-0500), Derek Robert Price 
>wrote: ]
>> Subject: Re: add hook question (was Re: Problem with importing third-party 
>> sources and adding/committing changes)
>>
>> Perhaps a -C option to `cvs add' similar to `cvs edit', where -C can
>> be placed in the user's .cvsrc for the add command and the add will
>> not be allowed unless the server contact and verification is successful.

>Which of course is an extremely stupid way to implement something that
>is done for the sole and lone reason of policy enfocement.   ;-)

>It would be saner and safer and much Much MUCH simpler to just write a
>wrapper script for the CVS client and require (through external security
>measures, such as peer pressure and/or threat of dismisal) that everyone
>always use the wrapper script.

It's simpler, but neither safer nor saner to wrapper script around the
client.  The reason is this:  If you enforce policy but give the user
an avenue to circumvent it, the user will do so.  If you're serious about
enforcing policy, then you must have a way to build it into your tools
in a way that user cannot defeat.  In CVS (and indeed most if not all
existing version control systems), that means spawning trigger scripts
from within the tool, because wrapper scripts are trivial to defeat.

>Remember the very strongest bit of advice for using CVS is to "update"
>and to "commit" early and often

This is true, but it remains a common belief that nothing should be
committed until it's ready for unlimited use by the rest of the project.
As long as that paradigm holds, work will continue to be done for long
periods of time between commits.

Note that this is not what I teach, it's what I see.  I would never, ever
discourage someone from checking in their work, working or not (though I
may recommend doing so on a private branch).  But despite my teachings to
the user community of the folly of their ways, this "we will commit no
line until its time" mindset persists.

>(but of course only commit after compiling _everything_ one last time
>and doing at least a few tests! :-)

>(which of course implies that day-to-day work using CVS should never be
>done directly on a baseline branch either, assuming the project needs a
>working baseline at all times.... :-)

>Any fears about early policy enforcement not being possible at "cvs add"
>time are ungrounded and illogical in the context of how CVS is used in
>general.  Also the fear about lack of a "cvs add" hook is pure
>F.U.D. given that "cvs rm" also lacks a similar hook (and it lacks it
>for the same reaons).

Claiming that the hooks are not needed in the context of current use is
meaningless because the hooks do not currently exist.  Such arguments can
only be made if one can demonstrate that existing hooks are not used in a
meaningful way.

On the other hand, we have stated requirements where existing users find
existing capability to be inadequate.  This is compelling reason to add
the requested feature.

>CVS "add" and "rm" commands are intended solely to change the state of
>the working directory.  They MUST NOT require access to the repo or the
>repo server.  They are no different than "vi" except that they change
>metadata describing the state of the working directory instead of
>changing the content of a file.

I define the "add" and "rm" commands as the actions required to make
CVS aware of new artifacts or to remove them from existing configurations.
How it does that is to me an implementation detail, and I don't care
whether or not the tool considers it necessary to contact the server.

However, in the event that triggers are added to track these events,
they must be added in such a way that user's can't defeat them by applying
more primitive operators or munging their environment.  To me, that means
building triggers into the server and making the client contact the server
at appropriate times to fire the triggers.  If there's a better way to
do it, I'm open to hearing it.

>--- End of forwarded message from address@hidden