Re: CVS diff and unknown files.

[Sergei Organov]

Todd Denniston <address@hidden> writes:
> Sergei Organov wrote:
> > 
> > Paul Sander <address@hidden> writes:
> > > On Jan 27, 2005, at 1:07 AM, address@hidden 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.