On Tuesday, February 15, Greg A. Woods wrote:
>
> My 'cvs add' will not do anything beyond adding CVS administrative files
> to any of the intervening parent directories between the current
> directory and the first valid CVS working directory. It will not
> "recurse" within them. It will still only do its actual operations
> based solely on the command-line arguments it is given and do so
> relative to exactly where you start it from.
Greg, I'm going to disagree with this proposal. In some sense, and correct
me if I'm wrong here, it looks like you wish to remove 'cvs add' for all the
directory cases. IE: since directories are not versioned, you wish to have
'cvs add/rm' work only with files, dealing with directories as an artifact.
While that may be a good goal to work towards, I personally was hoping it would
go towards a slightly different track. I envision you needing to use 'cvs add/rm'
on directories, but that action would only add the admin files in the dir
you just added/rmmed. Feel free to make that recursive down the tree, if a
directory is specified. However, for 'cvs add/rm' to work, I believe you
should have admin files in the current directory, and not search for them
up the tree. I will give 2 reasons, again all IMHO, why you should not do
the upward searching.
1) I'm hoping to see directories versioned to some degree in the future.
Treating them, however wrong currently, as a pseudo object at the user level
will be easier to integrate into the UI in the future.
2) Searching up the tree is not always possible. There are filesystems out
there in use, where searching up the tree is a very expensive, and sometimes
impossible, operation. Certain "instances" of AFS come to mind, and other
such filesystems.
> The details of the proposal should make this abundantly clear but
> perhaps a more visual example will help. Say you're a couple of levels
> within the top of the working directory and you have created a nice
> little hierarchy of stuff you want to add, but at each level out there
> are a bunch of similar directories that you don't yet want to touch, you
> don't have to worry. They won't be touched, even if you do "cvs add"
> with no explicit arguments:
>
> module-top ---+--- CVS --------- {admin files}
> |
> +--- leavealone -- {more stuff}
> |
> +--- donttouch --- {more stuff}
> |
> +--- subdir1 ----+--- keepout ----- {more stuff}
> | |
> +--- subdir2 ----+--- youarehere --
> | |
>
> PWD = .../module-top/subdir1/subdir2/youarehere
>
> Only module-top/subdir1/CVS and module-top/subdir1/subdir2/CVS (and
> their respecitve contents) will be created outside of "youarehere".
> Inside "youarehere" a CVS directory would be created and all files
> within which are candidates to be added would be added. That's all. No
> danger. Nothing irreversible. Extremely simple and easy to figure out.
> Entirely predictable. The only CVS-style recursion that will happen
> will be restricted to within "youarehere".
I would rather see the semantics that the above would return an error from
CVS, saying something about admin files not found. Then if you were in dir
module-top, and said 'cvs add subdir1', admin files would be created in
subdir1. If things are to be recursive, then also in all subdirs below
subdir1, such as keepout, subdir2, youarehere, etc...
While not 100% pure (in the sense you still 'cvs add' directories), I believe
this model offers the least confusion for current users of CVS. And judging
by the list traffic, the less confusion about these sort of things, the better
in the long run.
--Toby.
