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

[Josh Baudhuin]

D'uh woops. It occurs to me that the  -T  was not what was keeping us from 
having to recompile--it was because our wrapper script reset the committed 
(ci'd) file to the timestamp it had before the ci occurred.

First issue remains. Any comments? workarounds? 

> -----Original Message-----
> From: Josh Baudhuin [mailto:address@hidden
> Sent: Friday, July 27, 2001 1:48 PM
> To: address@hidden
> Subject: A couple of features in RCS that CVS lacks... why?
> 
> 
> 
> There are a couple of things in RCS that CVS doesn't have any 
> longer (i.e., since cvs-1.10) that I find a little odd and vexing.
> 
> 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:
> 
> `-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'.
> 
> I would say that it's NOT really "useful with CVS" unless commit 
> and update allow you to specify state.
> 
> The second thing is that  commit  loses ci(1)'s  -T  option, 
> which makes sure the archive file has the same timestamp as the 
> working copy being commited. As the ci(1) documentation states:
> 
>                 . . . [Not having -T] can cause excessive  recom-
>           pilation  caused by a make(1) dependency of the working
>           file on the RCS file. . . .
> 
> Yes indeed. Our previous VCS scripts wrapped around RCS and used 
> -T as a matter of course. Now that it's no longer available, we 
> have to put up with the agony of unnecessary rebuilding after 
> commit--this can be particularly onerous if you're checking in a 
> key .h file, since you've already done a heinous rebuild and now 
> you have to go and do it again.
> 
> Any comments? Known workarounds?
> 
> ____________________________
> Josh Baudhuin
> Cadence Design Systems, Inc.
> <insert standard disclaimer here>