Re: CVS diff and unknown files.

[Todd Denniston]

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.

<SNIP>
> > When "cvs add" runs, I don't care whether or not the CVS server
> > modifies the repository. Some people seem to think that running "cvs
> > add" while disconnected is a useful thing to do. (I take the attitude
> > that client/server applications shouldn't be expected to run without a
> > working network, so I'd never run any CVS command when I was unable to
> > connect to the server.)
> 
> Very strange attitude. And a very unusual definition of expectations
> associated with client/server applications. Having this definition, mail
> client isn't supposed to let you do anything with the mail on your
> computer without a working network?!

If you are using IMAP, that is a true statement, for all mail boxes ON the
server. If you have downloaded the mail to your local disks you can work
with it there off-line (I have this kind of setup).  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.


<SNIP>
> > For example, suppose a mixed Windows/Unix shop requires all files to
> > have upper-case 8.3 file names. A new programmer splits a header file
> > and creates a new foo.h. He adds the file, then proceeds to modify all
> > of the source files to include the new foo.h. Then he updates all of
> > the dependencies in his makefiles. He builds and tests on Unix. He
> > types "cvs commit", types a very detailed log of his actions, and
> > finally punches the screen. This person might have saved a day's work,
> > his equipment, and his knuckles if only "cvs add" had said "Sorry,
> > this new file violates our naming policy, try renaming it to FOO.H
> > instead."
> 
> ... and what? Is the file added to the working copy or not? If not, then
> if I've specified a few files, are they all not added, or only those
> that didn't pass the test? Still I'm opposed to the idea that "cvs add"
> would refrain from adding files to the working copy. It's not repository
> administrator business to decide what I can and what I can't do to my
> working copy. 

It could be if it is company policy. Remember those silly things many of us
just sign to get hired? (yes bad practice I know)

> If "cvs add" will only warn about the problems, -- that's
> OK with me as a user.

Actually, the way I see the situation is it only prevents the add if you
have requested the check with -c, if you have not used -c there is no
connection to the server and therefor can be no warning or prevention.

<SNIP>
> > It would run the add-time triggers (for the first commit) and then the
> > commit-time triggers.
> 
> Will "cvs -n ci new_file" run the triggers in the design you have in
> mind?
> 

Does "cvs -n ci file" run the commit trigger now (cvs-1.11/1.12)? if yes
then the modified version should run the add, if no, then no.

<SNIP>
> Whatever the reasons for duplication are, the fact is that the server
> must run add-time triggers when new file is being added to the
> repository. Adding files to repository is what "cvs commit" does. Then
> it's logical for "cvs -n commit" to run the triggers as well. Then,
> provided you already have a way to run these add-time triggers through
> "cvs -n commit", why do you need yet another way to perform the same
> operation (through "cvs add")? Thus, the duplication is not in fact
> required, -- it's the wrong design choice you are advocating that leads
> to the duplication.
> 

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?

<SNIP>

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter