Question about RCS check-in

[Gary Bridgewater]

In article <1990Jun17.050747.27703 at cs.umn.edu> slevy at klein.geom.umn.edu (Stuart Levy) writes:
>Yes.  The effect on 'make' of checking RCS'd files in/out really annoyed me.
>I modified ci & co to optionally preserve the mod date: on checkin, to
>(a) keep the source file modification date unchanged and (b) set the
>RCS revision date = source file's mod date; on checkout, to set
>checked-out file's mod date = RCS revision date.  Works great.
>
>Walter Tichy argued this shouldn't be the default behavior, though;
>if you have a source file on hand, then check out an older revision,
>you'd *want* make to remake anything depending on that file.

I would argue against it on the grounds that your ident string will
will be inconsistent between the source and the executable.  That final,
"unnecessary" compile is what puts all of them in synch so you can
determine what is installed versus what is current.  If you don't care
about such things that is your perogative - although I would wonder why
you would want to disregard such a handy piece of information to save
a few minutes of time at the end of a project.
In a multi-team effort such niceties can save many hours of hassle - team
A produces library A, team B produces library B, team 1 produces product
1 using library A and library B.  Knowing what of which was used when
is very useful.  In a c++ environment it can be critical - right down to
the header files.
Given that - if you do keep headers in sync you should be able to wrap
co with a script that compares the headers between the checked out source
and the .o file and, if they are the same, touch's the .o (or the .c) to
synch the dates.  For header files, this is impractical.
A more exotic kludge would be to wrap ci with a script that grabs the
date of the source file at the beginning and then touches the .o
up to sync. It should also sed the new ident string into the .o while
it was at it.
-- 
Gary Bridgewater, Data General Corporation, Sunnyvale California
gary at sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary
C++ - it's the right thing to do.