[ On Monday, February 14, 2000 at 12:23:12 (-0500), John Macdonald wrote: ]
> Subject: Re: removing the need for "cvs add file" to contact the server....
>
> When a user creates a new file on the file system he first does a
> mkdir and then edits the file. How does it *hurt* CVS if the user
> first does a "cvs add" of the directory and later does a "cvs add" of
> the file?
Because that's not the way *all* of the other sub-commands that operate
in a working directory hirarchy work.
The *standard* meaning of "cvs SOMECOMMAND dir" is to operate on the
files within "dir" (including recursing into any sub-directories and
operating on the files within them too unless you use '-l', sans the
optimisation I discuss in the final paragraph below).
My "cvs add" will be compatible to all those other similar sub-commands
and thus "cvs add dir" will obviously ``work'', but it won't do what you
want it to do (which is effectively the broken hack it does today).
> Why is it important that when the user is making changes
> in directory structure, he must be forced to communicate those
> changes in a different way to CVS compared to how he communicates
> them to the file system?
What the heck kind of nonsense are you talking about? Haven't you used
SCCS for decades? Have you ever done 'delta dir'? Yet don't you use
'mkdir' quite often? CVS versions files, not directories. I.e. CVS
does not *operate* directories. It operates only on the files within
directories (usually in a "recursive" manner). Assuming you use it in
the documented recommended way CVS magically does "The Right Thing(tm)"
with directories, meaning that you don't have to tell it anything about
them, just as you don't tell RCS or SCCS anything about directories
either. This is one of the reasons people flock to CVS despite their
often mentioned misgivings about it forcing them to use the
copy-edit-merge paradigm, and before there was a client/server
implementation this was almost the only reason why users were attracted
to CVS.
> While creating a directory in the repository was one step taken by
> the command, it also added the work area directory to the locally
> managed working set of the work area, extending the depth of the
> cvs-managed work area.
You're in the working directory when you're anywhere within it,
regardless of whether or not there are CVS administrative files
immediately and currently available in the current directory. You
obviously cannot be within it and outside of it at the same time. This
is pure common sense and is the way Unix (and Multics) directory
hierarchies have worked for decades. Trying to claim otherwise is
either arguing that black is white or makes use of tricks that CVS
explicitly does not respect (i.e. the previously discussed symlinks,
loop-back mounts, and so on).
> (You have noted one exception. The "cvs release" command combines a
Two ``exceptions'' actually. "cvs rm" is the other. They aren't really
``exceptions'' though -- they are just examples to counter a silly
nonsensical argument.
> ... and they all ignore all of the files and sub-directories of any
> directory that doesn't contain a CVS sub-dir (i.e. any directory that
> is not part of the cvs-managed work area is totally ignored). They
> quietly return from such a directory without doing any other portion
> of the cvs operation as soon as it has been determined that the
> directory is not part of the cvs-managed work area.
That's only an artifact, or rather an optimisation, of the current
implementation. It would make equal sense to note every un-ignored file
as unknown in every sub-directory. This would be a bit noisy and
unnecessary though -- it's plainly obvious that all of the files within
an as-yet uknown directory must also be unknown themselves. I guess
this optimisation should be turned off too so as to avoid confusing
naive users and implying that CVS has features that it in fact does not
have.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
