Todd Denniston <[EMAIL PROTECTED]> writes: > Sergei Organov wrote: > > > > Paul Sander <[EMAIL PROTECTED]> writes: > > > On Jan 27, 2005, at 1:07 AM, [EMAIL PROTECTED] wrote: > > [...] > > > > Just to understand your point better, do you propose 'cvs add -c > > > > new_file' and 'cvs ci new_file' run exactly the same set of triggers? > > > > Different sets? > > > > > > I think the consensus in the last iteration of the topic was that, if > > > add-time triggers were implemented, they would run as a client-side > > > option at add-time and and be obligatory at commit time, preceding > > > commit-time triggers. Doubling the overhead was the only way we came > > > up with at the time that guaranteed that the add-time triggers fired > > > at least once prior to the first commit of a new file. > > > > Well, so the answer to my question is "the two trigger sets are > > different". But it in turn means that it could be the case that I won't > > be able to 'cvs ci new_file' even though 'cvs add -c new_file' just said > > the file is OK to be added. IMHO that's a mess. And I believe this mess > > is direct consequence of poor design choices you are advocating, sorry. > > > > Careful, Last discussion time it was indicated that if add triggers were to > be added, then for them to be useful they would have to run at add time > (when the flag requesting them was passed) AND more importantly at commit > time, so commit on the server would if it had never seen the file before run > the add trigger and then the normal commit trigger. > So as long as the add trigger (script) had not changed between 'cvs add -c' > (IIRC that was the flag) and commit time and the trigger allowed the add, > then the server would at commit time > run the add trigger, get a pass > run any commit triggers, get a pass if appropriate. > > So in adding the add trigger functionality, the person patching CVS would > have to recognize the signals in the code indicating new file/directory at > commit, and connect the hook there too.
If you consider my suggestion, there will be no such a beast as add-to-working-copy-time trigger. The commit trigger will notice the file is new and invoke appropriate additional actions (if any). That's all. There is absolutely no need for separate "add-to-working-copy-time" triggers. Clients still have ability to check if their new files will be accepted by the repository using "cvs -n commit". [...] > As has been mentioned, the contact to the server for add should > require a flag being set (for Paul's group they would put the flag in > each of their .cvsrc files). So it does require a working connection, > but only if you, like Paul, require add time trigger checking. With my design you don't have ugly add-to-working-copy-time triggers and still have the functionality of checking if new files are OK from the point of view of repository policies. Usual commit time trigger can do the job. [...] > If "cvs -n commit" runs the triggers to do your check(see my question > above), I have another question: in a remote server setup (i.e., :pserver:, > :ext:) which test was failed, the add or the normal commit? With my approach there is no add-to-working-copy-time triggers, adding of a new file is normal commit (the commit time trigger should have a way to check if the file is already in the repository or not). So your question reduces to the following: "how client knows what exactly failed?" and the answer is "through appropriate error message, as usual". Please notice that with separate add-to-working-copy-time triggers the situation at commit time is exactly the same as those triggers must be run at commit time anyway. What's an answer to your question in this case? -- Sergei. _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs