Re: Question about version numbers.

[Greg A. Woods]

[[ you should teach your mail client to wrap lines at ~72 chars!!! ]]

[ On Friday, November 2, 2001 at 18:21:06 (+0100), Peter Kroon wrote: ]
> Subject: Re: Question about version numbers.
>
> Greg, I agree if a new project is concerned.  But in this specific
> case I have a single directory with *.h files where each file contains
> descriptions of a specific piece of hardware, like register addresses
> and register layout.  The only relation between the files is their
> nature: hardware description files.  There is nothing else that binds
> them together in a project.  It is just convenient to have them in the
> same directory.

That's really irrelevant.  CVS uses RCS revision numbers internally and
they're not really for "human consumption".  In CVS release "ID"s take
the form of tags, not revision numbers.  Just because CVS is somewhat
RCS-compatible doesn't mean you can continue to use it as you would
plain RCS.  Use of CVS to manage a collection of files implies at least
some conformance to a certain software development process model, and in
how you define the relationships between your collections of files.

It might be convenient to have them all in one directory, but if you
want to separately release manage each one of them then you really
should put them in separate CVS modules.  You can no doubt invent other
tools and means to mask the inconvenience of having one module per file.

If the convenience of having them all together comes primarily in how
they're used in some other project then you can install the released
versions of each in one common target directory on your build machines.

>  These files exist since many years and have been
> modified many times.  So they have a pre-CVS history and version
> numbers.

That's really not relevant -- if you've moved them into CVS then you
should probably try considering using CVS' preferred release management
techniques to control them, otherwise you'd be better off just leaving
CVS out of the picture (eg. go back to just plain RCS for these files).

Use the right tool for the job -- if use of CVS doesn't give you any
significant added value in your task of managing some set of files then
do not use it to manage that set of files.  If all the secondary
features of CVS add up to a significant benefit, but the implied process
model doesn't fit, then you still should not use CVS as its overall cost
of use will not be positive.

> If I do not intend to use this feature, does it mean that vendor and
> release tags are irrelevant for me, and import and add are equivalent?

I would say "No".  Don't use "cvs import" if you're not managing a
vendor (3rd party) collection of source files.  Vendor branched modules
have certain other limitations that will get in the way of normal use.

(though you can use "cvs import" as a cheap hack to quickly add a whole
bunch of files in a deep directory hierarchy, and then you can quite
easily clean out the extra branch and revision it adds)

-- 
                                                        Greg A. Woods

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