[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....
>>
>> Please help me out here. I'm trying to figure out where our disconnect is.
>>
>> I'm saying that "cvs watch" does indeed work on directories in order to work
on
>> future files/sub-directories. The way it does this is by storing some
>> information within CVS/fileattr. This mechanism is similar to how group
>> ownerships are controlled by setgid on directories.
>>
>> Now, you're saying that "cvs watch" does not work on directories and that it
>> only works on current and future files.
>
>I have *always* said that (and if I said anything else in the past that
>conflicted with this then it was a mistake).
Please learn to read English; the comma after "Now" means a lot.
>> 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.
>> The major difference between "cvs add" and "cvs import" is that "cvs add"
should
>> not affect the repo directly while "cvs import" does (in fact, it is possible
to
>> create empty modules (and therefore empty directories) with "cvs import").
>
>That's not really important -- it's only an optimisation that "cvs
>import" does everything in one step....
The ability for "cvs import" to create empty directories is important.
>> Upon reading your proposal again, I caught that you intend "cvs co
>> non-existent-module" to create an empty working directory iff
>> non-existent-module is described within CVSROOT/modules. This sounds like:
>> 1. You're trying to replace "cvs import" with "cvs co CVSROOT; add new-module
to
>> CVSROOT/modules; cvs ci CVSROOT; cvs co new-module; create stuff in
new-module;
>> cvs ci new-module".
>
>Not "replace". "cvs co new-module" will be an optional way of starting
>a new module, not a necessary or only way.
Then this is bloat.
>I did consider the possibility of allowing "cvs co new-dir" to just
>create a new directory regardless of whether there's a modules entry
>with the name "new-dir" yet or not. However I do feel rather strongly
>that the use of the modules feature should be encouraged as much as
>possible.
I think either CVS should require CVSROOT/modules or it shouldn't. Your
proposal is an "in between" decision that could confuse people. The way I would
go about it would be to have "cvs co module" require that module exist in
CVSROOT/modules. I know this would probably break many people's use of "cvs
co", but I don't think it's too difficult to add appropriate lines in
CVSROOT/modules.
Also, I just thought of a couple of cases that might need discussion:
echo "dir" >.cvsignore
mkdir dir
cd dir
touch file
cvs add file
and, a little different:
echo "dir0" >.cvsignore
mkdir -p dir0/dir1
cd dir0/dir1
touch file
cvs add file
Where, if anyplace, will CVS admin subdirectories get created?
Noel
