Numbering
Kay Schulz
Can I change the numbering to numbers like 2.1.1.1.1
I only get 1. something, but it nevers goes to two
I know it's just the internal numbering but it would be nice to
have this, too
Thanks
--
Kay
Rodney Holm
You are correct, the "numbering" is for internal cvs usage. If you would
like to use different "numbers" then you should be using tags. Tags are a
much easier and more human understandable way to keep track of changes than
is trying to follow the cvs revision numbers.
--
-------------------------------------------------------------------------------
Rodney D. Holm rod...@apexxtech.com
Apexx Technology, Inc. http://www.apexxtech.com
-------------------------------------------------------------------------------
Russ Allbery
> Kay Schulz <k...@ciemed.nus.edu.sg> writes:
>> Can I change the numbering to numbers like 2.1.1.1.1 I only get
>> 1. something, but it nevers goes to two
> Alternatively, I'd be perfectly happy if the leading "1." was simply
> removed (since it's always "1." it's redundant).
===================================================================
File: bundle Status: Up-to-date
Working revision: 2.14 Thu Aug 27 10:15:48 1998
Repository revision: 2.14 /afs/ir/dev/cvs/leland/bundle/bundle,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
===================================================================
File: wrap Status: Up-to-date
Working revision: 0.3 Mon Aug 31 15:20:18 1998
Repository revision: 0.3 /afs/ir/dev/cvs/leland/bundle/wrap,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
Some of us are vain about revision numbers, even though it's not
recommended that you even worry about them. :) They're just RCS revision
numbers. If all else fails and you're careful (do this *before* tagging),
you can fix them by editing the RCS files directly. You can also under
some circumstances update them with the -r flag on commit, but that has
the potential of doing odd things as well (at least according to the FAQ).
I actually use the following patch to 1.10, which is probably not a little
evil, but I like it for my personal version.
--
Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Russ Allbery
> I actually use the following patch to 1.10, which is probably not a
> little evil, but I like it for my personal version.
Er, there was supposed to be a patch there. Sorry. But it turns out that
it doesn't matter, since the patch that was supposed to go here to fiddle
with version numbers doesn't work.
Hmm.
The CVS RCS code really isn't that easy to read.
Jim Kingdon
That is a bit of an understatement :-(. Some of it has been hacked
for speed, some of it is needlessly complex (for historical reasons or
whatever), and some of it really needs to be (somewhat) hairy.
If it makes you feel any better, the RCS 5.7 code is considerably worse
(IMHO).
Meta E. Sienkiewicz
>
> Hi
> Can I change the numbering to numbers like 2.1.1.1.1
> I only get 1. something, but it nevers goes to two
> have this, too
> Thanks
>
> --
> Kay
If you really want to change your version numbers to start with '2'
you are certainly allowed to do it.
from the Cederqvist manual (info doc):
Normally there is no reason to care about the revision numbers--it
is easier to treat them as internal numbers that CVS maintains, and tags
provide a better way to distinguish between things like release 1
versus release 2 of your product (*note Tags::.). However, if you want
to set the numeric revisions, the `-r' option to `cvs commit' can do
that. The `-r' option implies the `-f' option, in the sense that it
causes the files to be committed even if they are not modified.
For example, to bring all your files up to revision 3.0 (including
those that haven't changed), you might invoke:
$ cvs commit -r 3.0
Note that the number you specify with `-r' must be larger than any
existing revision number. That is, if revision 3.0 exists, you cannot
`cvs commit -r 1.3'. If you want to maintain several releases in
parallel, you need to use a branch.
--
Meta Sienkiewicz msienk...@dao.gsfc.nasa.gov http://dao.gsfc.nasa.gov/
Data Assimilation Office, Code 910.3 ph: (301)805-7956 fax: (301)805-7960
NASA Goddard Space Flight Center, Greenbelt, MD 20771
One says a lot in vain, refusing;
The other mainly hears the "No."
-- Goethe