[ On Sunday, January 5, 2003 at 21:05:59 (+0000), David Laight wrote: ]
> Subject: Re: kernel filesystem code move
>
> It is probably also worth making the CVS id of the actual file
> continue to increment monatonically.
> ie make the new file have revision 1.xxx+1 if the old one was 1.xxx
> (rather than starting again at 1.1).

Why?  That just screws things up with CVS.  You can't do it when you
move stuff on branches anyway so why bother even trying?  Besides, see
my next comment:

> FWIW why does no one (except me) ever increment the first number?
> I would have thought it would be worth doing at every major source
> freeze (eg near the point where a release branch occurs).

Because that's a semi-bad, confusing, and very unnecessary thing to do
with CVS.  It is very strongly discouraged.

Do not pay any particular attention to the revision numbers.

In CVS the RCS revision numbers for each revision in each file are for
internal use only and should only be used externally as opaque
identifiers for their corresponding revisions.  No additinoal meaning
should ever be attached to them.  If you want meaningful identifiers for
a particular revision set, branch, whatever, then the only correct way
to create such identifiers, especially in CVS, is to use a symbolic tag.

Remember in CVS operations are normally done on a per-module basis but
that doesn't mean every file is affected with every operation.  The only
way to see a consistent set of revisions across all the files in a
module is to use tags or other virtual identifiers such as branch heads
and/or date&time specifications.

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>