[EMAIL PROTECTED] on 03/08/2000 04:23:10 PM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc: [EMAIL PROTECTED]
Subject: Re: removing the need for "cvs add file" to contact the server....
>[ On Tuesday, March 7, 2000 at 09:47:39 (-0500), Noel L Yap wrote: ]
>> Subject: Re: removing the need for "cvs add file" to contact the server....
>>
>> No, Greg, you're confusing the term "operate on" with "version". Just 'cos
CVS
>> *operates on* directories doesn't mean it *versions* them. The is very true
of
>> "cvs watch". "cvs watch" *operates on* directories though it doesn't
*version*
>> them.
>
>Like I said, no matter how much you might personally desire this to be
>true, it simply isn't. "cvs watch somedir" does not "operate on" a
>directory any more than "cvs commit somedir" does. It does record some
>state in the repository so that future actions will trigger the watch,
>and yes, it does do that "in a directory", but the details are not
>important. Please don't confuse the concepts with the internal details.
>
>> Now that (I hope) we have definitions all straightened out, it should be
clear
>> that "cvs watch" must operate on directories in order for CVS to watch future
>> files. Again, this is very similar to setgid on directories -- new files
don't
>> have setgid set on them, but new subdirectories do.
>
>You're off in your own version of hyperspace again (still?) Noel.....
So, Greg, how do you propose "cvs watch" watch future files if it doesn't
operate on directories? Again, this is pretty much the same question as, "How
do you propose to default future file group ownership without operating on
directories?"
All you've done above is say, "You're wrong." I've given an example backing my
point, but you haven't given any counterexamples or otherwise proven my point
wrong. What don't you understand about, "In order to affect future files, a
tool must operate on the directory of those future files."?
Noel
