-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Paul Sander wrote:
>>--- Forwarded mail from [EMAIL PROTECTED] > > >>Derek Robert Price <[EMAIL PROTECTED]> writes: > > >>>Mark D. Baushke wrote: >>> >>>>Hi Greg, >>>> >>>>Is it reasonable to suggest that a addinfo trigger could be run as a >>>>part of the 'cvs commit' command should the client not happen to connect >>>>to the server for a 'cvs add' operation? >>> >>> >>>It should probably run regardless since it would be much simpler than >>>securely tracking whether the add on the client side had contacted the >>>server. > > >>Good point. > > >Yes! > >>>>The idea would be that having simpler triggers for various kinds of >>>>policy makes the administration of a repository easier. >>>> >>>>In a similar manner a trigger for 'cvs rm' could be implemented to >>>>impose policy. >>> >>> >>>Sure, but again, not by default. > > >>Sure. > > >I think that it should be enabled by default, and the user can put the >-n option in his .cvsrc file for the affected commands, both for add >and remove. No! -n means "don't change the disk!" In other words, nothing is changed anywhere and the file would not be added locally. >The reasons for this: >- It maintains compatibility with existing commands. No, but to continue your logic, -C to request the validation would be consistent with the current behavior of `cvs commit' and `cvs edit' on feature. >- The user is caught just once when the trigger fires. Recovery is to > interrupt the client, edit .cvsrc, and re-run. In the converse, the > user must ask for policy enforcement, and may never get around to it > in violation of the project's policy. Policies should not be enforced until the change is to the repository where everyone else can see it. If your team really wants this behavior, you could always hack their clients, though, as I mentioned before, they can still get around any such "enforcement" using only a text editor. If it is really a lot of work to clean up after one of these mistakes, I expect most users won't forget to run add -C more than once or twice. If it is really, really, a lot of work, then you should be training them before hand to avoid the issue and probably installing a default .cvsrc for them which contains the `add -C' and `rm -C' options or providing them with hacked clients. >Unfortunately, there appears to be no way to countermand a -n option, >so the only way to turn it off is to edit the .cvsrc file. The -f option tells CVS to ignore the .cvsrc file for the duration of a command, but I have often thought it would be useful if every option had an "opposite" so that they could be countermanded individually on the command line. Of course, I haven't thought it would be so useful to actually be tempted to write the patch yet, as an easy solution, such as lower case being on and upper case being off would already break backwards API compatibility (for instance -r and -R already have very different meanings to CVS). Cheers, Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at <http://ximbiot.com>! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBngoZLD1OTBfyMaQRAg2iAKDVf9KeXeESxMEDIioZoA4k6bgltwCgjk03 OGOdGv6eKFA/DzyZGVhu/QU= =UNGJ -----END PGP SIGNATURE----- _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs