Re: cvs add <directory>

[Max Bowsher]

Greg A. Woods wrote:
> [ On Friday, May 23, 2003 at 22:19:48 (+0100), Max Bowsher wrote: ]
>> Subject: Re: cvs add <directory>
>>
>> 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)
>
> I would suggest to you that you're using the wrong tool(s), or using
> them in the wrong way, if you've created this problem for yourself.  :-)

Well, I didn't design the repository, I just get stuff from it.

That said, CVS, being the most standard open source version control system,
is probably the correct tool for the job.

Can you think of an alternate way to handle a group of top-level files,
which drive the build in various subdirectories, *each of which is
optional*?

>> 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?
>
> That's an interesting idea, though I'm not certain it's the right
> approach.

Can you think of any drawbacks to it? In my mind, the -d switch is
overloaded with too much functionality - "get new directories" and "clear
static flag". Sometimes you only want one.

> You should try to use your build system to select and combine modules
> instead of trying to do too many fancy things with the various modules
> options which were never really very well thought out or implemented.

So, you are saying I should check out vast quantities of source I don't
want, and then choose not to build it?

I'd rather have a discussion which might lead to improving the
implementation of CVS.

> You should never have the option of ignoring certain sub-directories in
> a given module's top-level directory.  Top level module directories
> should be "atomic" and should contain a single cohesive collection of
> source files.  It should not be possible to, by default, extract only a
> portion of the files in a module's top-level directory.

In the scenario I present, "module" != "directory". Rather, "module" = "a
defined subset of subdirectories to check out", and all modules include
certain core build support files, which live alongside the subdirectories.
This leads to a structure like this:

src/
    build-support-file1
    build-support-file2
    build-support-file3
    module-directory1/
    module-directory2/
    module-directory3/

Where src/ actually contains more module-directorys, which are not checked
out.

Granted, slightly unconventional, but it works.

I'm not sure why you say "you should never have the option...". You should
have the option to lay the repository out however makes most sense for the
situation.


Max.