Re: cvs add <directory>

[Max Bowsher]

Greg A. Woods wrote:
> [ On Thursday, May 22, 2003 at 16:42:47 (-0700), Kaz Kylheku wrote: ]
>> Subject: Re: cvs add <directory>
>>
>> In Meta-CVS, I took the approach that directories are simply just an
>> implementation choice in a filesystem to support hierarchically
>> organized path names.
>
> Why bother?  What a total waste of time and energy, and complete
> perversion of one of the primary design goals of CVS.
>
> CVS already ensures that a directory will exist in the workspace
> whenever it needs to (provided of course that your users are smart
> enough to always use the right options in their ~/.cvsrc -- i.e. the
> options that should have been the defaults in CVS, or at least CVS-II,
> from day one).
...
> CVS keeps things simple by automatically managing directories, and even
> files to some extent, allowing the user to focus on their content.  This
> fulfils a primary design goal of CVS:  to keep out of the way as much as
> possible.

CVS's handling of directories would be elegant *if* we could use "co -P" and
"update -dP" *all the time*.

Unfortunately, trying to do so prevents the use of certain complex modules
arrangements: specifically when a module name expands to some files in a
toplevel directory, and certain subdirectories within that toplevel.
With -d, the intent of the module is destroyed - *every* subdirectory within
the toplevel is fetched on update. (Example: the src repository at
sources.redhat.com)

This problem could probably be mostly solved by making CVS fetch new
directories by default (even without -d) *unless* CVS/Entries.Static
exists - i.e., make the "should I create new objects" criteria identical for
files and directories. I can't imagine this being a problem for anyone -
unless there is a valid reason for *not* wanting directories added to the
repository to be created on the client? Can anyone think of one?



Max.