>--- Forwarded mail from [EMAIL PROTECTED] >Paul Sander wrote:
>>It's true that add and commit hooks can enforce the same kinds of policies >>as post-conditions of the commit. However, add hooks can enforce things >>like naming conventions. I'm working in a shop right now that prefers to >>have additions to the source tree (particularly new directories) be made >>by the architects of the project rather than the rank and file, and >such a >>policy is best enforced at add time. >> >>The reason why I say these are best done at add time is because if the >>add succeeds then the user is likely to do a lot more work under the >>assumption that the subsequent commit will succeed (or at least not fail >>due to conditions created by the add). If the commit fails due to an >>improper add, then the user must re-do (or un-do) a bunch of work. All >>those hours of lost productivity could have been avoided by an add-time >>hook. >This might be true, but it seems to me that most damage due to your >"lost productivity" could be fixed with a rename or two and maybe a >few `sed' runs, in a few minutes. At least in an environment where >most of the files concerned were text files, as will usually be the >case using CVS. It depends on the nature and extent of the changes. I can easily imagine scenarios in which lost productivity would be measured in days, even assuming that all files are ASCII. >It might be interesting to see Greg's patch, but yours wouldn't be a >big deal either, I think, as long as the add went forward without the >hook execution when the server could not be contacted. The thing is, if there's a triggerable event, the trigger must be able to halt the event. Unplugging the network interface to enable adding a directory is simply not acceptable. On the other hand, requiring all add hooks to be replicated at commit time would eventually catch the error, and it could be argued that someone who attempts such tricks gets what they deserve, but it's just easier and better all around to just make the trigger act like a trigger. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
