Re: Question about version numbers.

[Peter Kroon]

"Greg A. Woods" <address@hidden> wrote in message news:address@hidden
> [ On Thursday, November 1, 2001 at 14:21:01 (+0100), Peter Kroon wrote: ]
> > Subject: Re: Question about version numbers.
> >
> > Larry, is this why you advise against it? And if I really want to do
> > this, is there a way around this?
>
> If I may:  Just ignore the revision numbers of files behind the (cvs)
> curtain.  They do not exist (for your use).  Use tags and forget about
> them.  They are only meaningful in specific instances where you need to
> look at individual deltas (or their comments) on individual files, and
> in that scenario they are only an index reference, not anything
> meaningful in any larger context.

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.
These files exist since many years and have been modified many times. So they 
have a pre-CVS history and version numbers. Older
versions were usually not preserved, but the changelog is still present in 
comments in the header of the file. Now say a file has
(pre_CVS) revisions 1.0 - 1.25. When I import it into a cvs repository it gets 
revision 1.1, and subsequent updates produce 1.2 -
1.13. Doesn't this become confusing? I now have to distinquish between e.g. the 
pre-CVS 1.3 and the CVS version 1.3. This is why I
want to do the initial import or add with revision 1.25 (or maybe 1.26). From 
then on I am gladly willing to let CVS do the
administration and consider revision as internal indexes as you suggest.

Does this make sense or do I overlook other good arguments not to do this?

To workaround my initial problem with stickyness Mark suggested the following, 
which worked fine:

   cvs add gamma.c
   cvs ci -r 6.27 gamma.c
   cvs up -A gamma.c
   <edit gamma.c>
   cvs ci gamma.c

This raises another question, the difference between 'add' and 'import'.
It seems to me that I can achieve the same result with add & commit as with 
import.
The difference is that import does the trick with vendor and release tags and 
creates branch 1.1.1 and revision 1.1.1.1.
Now http://www.cvshome.org/docs/manual/cvs_13.html#SEC105 says:
"When you use the import command to track third-party sources, the vendor tag 
and release tags are useful".
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?