info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs add <directory>


From: Greg A. Woods
Subject: Re: cvs add <directory>
Date: Fri, 23 May 2003 20:34:05 -0400 (EDT)

[ On Friday, May 23, 2003 at 23:34:16 (+0100), Max Bowsher wrote: ]
> Subject: Re: cvs add <directory>
>
> That said, CVS, being the most standard open source version control system,
> is probably the correct tool for the job.

Hammers are very commonly used, but they absolutely suck at driving in
screws.  They might do the job, but it will only be very poorly done.

> 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')

> 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.

> 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).

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.

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.

Even the latter option of "key directory files..." is of very
questionable value.  It had some benefit on old, slow, limited systems,
and for one particular historical source tree.

> 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.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]