>--- Forwarded mail from [EMAIL PROTECTED] >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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs