[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CVS diff and unknown files.

From: Sergei Organov
Subject: Re: CVS diff and unknown files.
Date: 28 Jan 2005 22:36:22 +0300
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]