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

[Paul Sander]

>--- Forwarded mail from address@hidden

>Greg A. Woods wrote:

>> There is no trigger for "cvs rm" and there MUST _NOT_ be.
>>
>> There is no trigger for "cvs add" and there MUST _NOT_ be.


>I have to admit, there is a certain logic to drawing the line at
>triggers for repository changes, not workspace changes.  The user
>should have total control over their workspace and the server
>shouldn't be able to veto anything except changes to the repository.

There is a certain logic to having triggers gate changes to the
repository.  There's also a certain logic to having a tool prevent
conditions that will later cause it to fail.  Uncommitable changes
are such a condition, and it simply makes no sense to allow adds
to succeed when we know that committing those adds will fail.

There's another point I'll make but won't argue over:  There's a
limit to the amount of control a user should have, even over his
own workspace.  The user shouldn't be able to corrupt his metadata
to the extent that it causes failures, for example.

>This still requires that `cvs add' of directories not alter the
>repository until commit.  It also reminds me that allowing `cvs add'
>and `cvs rm' in a workspace without even write privs to the server has
>been on my wish list for quite awhile (this enables complete patches
>to be generated from a public repository by anybody).  I'm guessing
>the proposal Greg is advocating would provide for this.

Why is having CVS aware of source files an enabler for producing patches?

>I also still would not object to the a `cvs add -C' "convenience" hook
>which requested that the client contact the server and validate the
>add.  Any team that valued this option significantly should find it
>fairly easy to enforce a policy of placing `add -C' in users' .cvsrc
>files.

I don't consider triggers to be "conveniences."  If they are to enforce
policy then they can't be defeated by the user.  This is why I hate the
-n option of the checkout/commit/tag/update commands and advocate its
removal from CVS.  However, if applied to the add command, it is more
agreeable than the -C option as described above for human engineering
reasons.

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