[EMAIL PROTECTED] on 03/06/2000 12:33:39 PM
>On 6 Mar 2000, at 9:37, Noel L Yap wrote:
>> [EMAIL PROTECTED] on 2000.03.03 16:04:27
>> >[ On Friday, March 3, 2000 at 11:18:50 (-0500), Noel L Yap wrote: ]
>> >> Subject: Re: removing the need for "cvs add file" to contact the
server....
>> >>[SNIP]
>
>> >> What do you think it does in order for
>> >> it to work on future files?
>> >
>> >That is irrelevant. We're (or at least I am) talking about a concept
>> >here, not its implementation.
>> >
>> >Conceptually "cvs watch" operates only on files, regardless of how they
>> >are specified, just as "cvs ci" and other similar workspace sub-commands
>> >operate only on files.
>>
>> OK, but regardless of the implementation, "cvs watch" must operate on
>> directories in order to achieve this future inheritence.
>
>Noel, How about trying this concept:
>cvs watch evaluates 'cvs watch dir' whenever it needs to, so that new files
>will
>also be watched.
>If you think of it that way, then you can see that it is no different than
>'cvs commit dir' - which will commit changed/added files now and will also
>commit files added/changed in the future, when it is executed again.
I don't think you understand. "cvs ci dir" does nothing to directories except
traverse them (and possibly create them (with Greg's proposal) when new files
are added). Although "cvs watch dir" won't actually watch "dir", it does do
something with (ie operate on) the directory (namely, keep track of it for
future use). There is absolutely no way "cvs watch dir" can work on future
elements of "dir" if it didn't do this, no matter what the implementation of it
is.
>Now *this* is constructive.
I apologize if "cvs watch dir" is a bit off topic. I brought it up as a
counter-example to Greg's claim that no CVS commands operate on directories.
Noel
