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

[Josh Baudhuin]

Tags can be used as a STATE substitute, however the nice thing about STATEs is 
that it's much easier to revert to a last known good state, for example. With 
tags, however, once you've moved your tag, the last rev to which you associated 
the tag no longer has the association. You can workaround this w/ judicious and 
tedious use of graded tags (good better best, red yellow green, builds links 
runs, ...), but, oy.


> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of
> Greg A. Woods
> Sent: Friday, July 27, 2001 4:57 PM
> To: Josh Baudhuin
> Cc: CVS-II Discussion Mailing List
> Subject: Re: A couple of features in RCS that CVS lacks... why?
> 
> 
> [ 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>