"Greg A. Woods" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]... > [ 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? _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
