[Top][All Lists]

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

Re: add hook question (was Re: Problem with importing third-party source

From: Derek Robert Price
Subject: Re: add hook question (was Re: Problem with importing third-party sources and adding/committing changes)
Date: Thu, 18 Nov 2004 14:12:26 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Hash: SHA1

Greg A. Woods wrote:

>[ 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.   ;-)

Only if you view the policy enforcement as policing.  If you view it
as a development tool, it makes perfect sense.  I know that if Paul is
correct and his team can really generate days worth of work by adding
a file/directory with the "wrong" name and I were on his team, I would
be grateful for an automated check that I was doing the right thing as
I went along.

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

Maybe, but CVS already has the code to turn the file list, user
information, repository path, etc. into simple, script-digestible
chunks.  A wrapper script might have to duplicate those chunks of code
and possibly stay in sync with CVS as CVS metadata file details
changed.  A hook would be simpler in this regard and I know for a fact
that the current overhead of installing another hook in the feature
version of CVS is actually rather small.  As long as the check could
be avoided when necessary or desirable to allow disconnected operation
of `cvs add', I don't see why a well-written and complete patch for
this should be rejected.

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

This is true.

>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 still back you on this, but also still have absolutely no problem
with an optional check.

>The fact that "cvs add" came to create a directory in the repository was
>a hack that was implemented even before CVS supported the client/server
>mode of operation; and it is a hack that was made simply to avoid having
>to fix other implementation deficiencies in the code at that time.
>Of course we went over all of this in excruciating detail the first time
>this proposal was made and every time it's been seen since and all
>because of one stick in the mud.

Let's see a patch!



- --

Email: address@hidden

Get CVS support at <>!
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


reply via email to

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