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

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Sander wrote:

>>--- Forwarded mail from address@hidden
>
>
>>Derek Robert Price <address@hidden> 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: address@hidden

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