[ 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).
> 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.
> 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....
> 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.
You'll obviously still be able to use the current workaround of manually
creating the empty top-level directory for the module directly in the
repository too, though hopefully this new ability will eventually
supplant the use of the workaround.
> I'm not sure how I feel about this yet, but it should
> definitely be discussed further.
As with the rest of the proposal you're free to take it or leave it.
You're also welcome to discuss it too -- this is one of the "finer"
points of the proposal and indeed I posted it in order to solicit
comments on the finer points.
> 2. CVSROOT/modules will have a more important role. I like this idea but I'm
> not sure if your proposal is the way to go about doing it.
No, it won't really -- there's always more than one way to skin a
<critter-of-your-choice>.
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.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
