Re: A couple of features in RCS that CVS lacks... why?

[Greg A. Woods]

[ On Friday, July 27, 2001 at 13:48:25 (-0700), Josh Baudhuin wrote: ]
> Subject: A couple of features in RCS that CVS lacks... why?
>
> First off, I'd expect that the update and commit command would have
> co(1)/ci(1)'s -s<state> option to allow you to pull the latest rev of
> a certain state. In fact, the documentation for the admin command,
> which allows you to _set_ the state of a revision after the fact,
> reads:

RCS "states" are far far less useful in CVS than they can be in RCS.

That's because CVS already uses the RCS state for "magic" internal-only
uses.  You have to be very careful not to collide with the "dead" state,
or remove the "dead" state from any file.  This has much deeper
implications than you might expect if you don't have a very deep
understanding of the internal operation of CVS.

It's entirely likely that future versions of CVS might choose to use RCS
state values for other internal purposes too.

For example if "cvs update" and/or "cvs checkout" had a "-sSTATE" option
like the RCS "co" command does then it would have to be made smart
enough not to look back past any revision with a "dead" state lest it
resurrect an invalid variant of the file!  Also any '-s' option for "cvs
update" or "cvs checkout" it would have to be a sticky option and you'd
have to block commits on files stuck at a given state (just as '-r' is
sticky and will prevent you from doing a commit unless the stuck
revision happens to be a branch revision).

In CVS it also really doesn't make as much sense to change the state on
commit either.  CVS manages groups of files at once, but since you only
usually commit to one or two files out of the group it's best to
delegate any assignment of states to the "cvs admin" command (if you're
going to mess with RCS "states" at all).

In CVS the (much) better way to mark files as being in a particular
state w.r.t. your development process is to use tags.  With careful
construction of a naming scheme for tags it's possible to describe the
status of files as they evolve through the development and release
process.  Tags work just as well, if not better, with branches as
"states" do.

It's best to forget about the underlying features of RCS when you're
using CVS and instead focus just on what CVS is capable of and how best
to use CVS.  Having one feature that works really well is better than
having two somewhat similar but half-baked features at the same time.
CVS does need something like the RCS state information internally and so
in CVS states are always going to be less useful and trickier to use
than tags, i.e. be second class to tags....

All of this is very much along the lines of why you should basically
ignore revision numbers when using CVS -- they're also just internal-
only information that CVS needs to keep track of the things it does and
not something that's directly relevant or useful, and certainly not to
be changed unexpected, by the user.

> `-sSTATE[:REV]'
>      Useful with CVS.  Set the state attribute of the revision REV to
>      STATE.  If REV is a branch number, assume the latest revision on
>      that branch.  If REV is omitted, assume the latest revision on the
>      default branch.  Any identifier is acceptable for STATE.  A useful
>      set of states is `Exp' (for experimental), `Stab' (for stable),
>      and `Rel' (for released).  By default, the state of a new revision
>      is set to `Exp' when it is created.  The state is visible in the
>      output from CVS LOG (*note log::), and in the `$Log$' and
>      `$State$' keywords (*note Keyword substitution::).  Note that CVS
>      uses the `dead' state for its own purposes; to take a file to or
>      from the `dead' state use commands like `cvs remove' and `cvs
>      add', not `cvs admin -s'.

In other words I disagree with much of the advice given in that paragraph!  ;-)

(worst of all it suggests using silly abbreviations for proper words,
though in its defense it's just copied from the rcs(1) manual!)

> I would say that it's NOT really "useful with CVS" unless commit and
> update allow you to specify state.

Well, you can still use states to mark revisions with particular
information that's somewhat more static and more closely assosciated
with a given revision, but indeed RCS "states" are hardly useful with
CVS at all in any manner.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>