Re: cvs add <directory>

[Max Bowsher]

Greg A. Woods wrote:
> [ On Friday, May 23, 2003 at 23:34:16 (+0100), Max Bowsher wrote: ]
>> 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*?
>
> Check them all out.  None of them are optional from a source code
> version control point of view.
>
>> 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.
>
> In my mind '-d' always only means "get new directories".  It (along with
> 'update -P') should have been the default (with '-l' being the only
> option), but that didn't occur to the author of CVS-II until he thought
> it was too late to change, though he did agree it would have been the
> right way to do things.  Ultimately many of us believe he was mistaken
> about it being too late to change, and at least some of us believe it
> should still be changed any old day now anyway.
>
> (I'm not sure what you mean by the "clear static flag" -- unless you're
> confusing it with '-A')

I mean, delete CVS/Entries.Static - i.e. permit new files to be fetched from
repository into the working copy.

>> So, you are saying I should check out vast quantities of source I don't
>> want, and then choose not to build it?
>
> No, that's not at all what I said.  Maybe your source should be
> re-organized into appropriate groups, each in its own sub-directory so
> that each may be checked out and worked on individually, perhaps all
> within some enclosing directory so that the whole can also be checked
> out and worked on too.

Well, you kind of did say that above: "Check them all out...". But I see now
that you think that the organization of the source is at fault. The
repository I'm talking about is:
http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/?cvsroot=src#dirlist
containing binutils, newlib and cygwin, amongst other things. The point is
that it has a layout which works quite well, even if unconventional. I'm
just suggesting how a tweak to CVS's behaviour might make it work even
better, without any inconvenience to others, that I can see.

>> 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.
>
> In CVS a "module" is best thought of as a pointer to a directory, and
> only a pointer to a directory (though it may also define a collection of
> afew selected file or files from a directory, and it may be an alias for
> another module).

Why is this better?

> That directory may be a part of some larger hierarchy which is pointed
> to by yet another module name.  I.e. one module may be made up of
> several other modules, as well as other files and sub-directories that
> are not included in any other module
>
> If you read the documentation and examples very carefully you'll see
> that there are only three valid definitions of a module name:
>
> # Three different line formats are valid:
> #       key     -a    aliases...
> #       key [options] directory
> #       key [options] directory files...
>
> Note that "key [options] directory directory ..." is not valid.  Perhaps
> this restriction should be enforced more strictly by the code, but never
> the less you've wandered off into using undefined features and you
> should expect the resulting behaviour to be undefined as well.

No, not using that.

> The problem comes with the first one, the '-a' option.  This feature has
> never been fully or correctly implemented, and I believe still results
> in different behaviour depending on whether you're using client-server
> mode, or direct access.  It probably should be eliminated, or at least
> restricted to one and only one parameter (i.e. be left solely as the way
> of migrating modules to new names).  It should definitely be avoided.

Extensive use of -a, though. And it certainly seems to work well enough.
I don't think a buggy corner case is justification for ripping out a
mostly-working feature.

>> 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.
>
> CVS gives you a lot of unnecessary rope that you can easily hang
> yourself with, just as many powerful tools do.

But rope has beneficial uses too.


Max.