[ On Tuesday, January 7, 2003 at 10:15:51 (+0000), David Laight wrote: ]
> Subject: Re: kernel filesystem code move
>
> Ah - I would bump the major revision of all files in the repository [1] [2]
> and also ensure that any new files added picked up that new revesion.
> ie using the major number as a revision of the repository rather
> that that of a single file.

You mean you would do null commits to every file for no reason at all?
That would be extremely counter-productive with CVS.


> OTOH most of my experience is with scripts front-ending SCCS for
> a small number of users.

Exactly!  :-)  But CVS is not SCCS (and not even "just" RCS)!

SCCS does not have symbolic tags and relies entirely on the SIDs to
identify releases and branches (and thus suffers from the fact that you
need a map to identify the meaning of branches, and even of releases,
especially in projects that use a "lines of development" methodology).

In RCS the numeric delta identifiers ("num" in rcsfile(5)) can be used
exactly as in SCCS by treating the first part as a major release number
and bumping it _AFTER_ a release has been created so as to start a new
release.

CVS however uses a "lazy branching" scheme -- revisions are not created
at the base of a branch when the branch is first committed but rather
only when the first change is made to the file on the branch.  That's
the reason for the "magic" branch numbers in branch tags in CVS.  There
are many implications to this "lazy branching" scheme, but practically
they all boil down to the fact that tags _must_ be used for identifying
branches and releases; and any attempt to subvert CVS by using
SCCS-style management of delta identifiers is going to cause bizzare
problems and will subvert the efficiencies gained by lazy branching.

-- 
								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>