Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!adam.pika.mit.edu!scs
From: scs@adam.pika.mit.edu (Steve Summit)
Newsgroups: comp.unix.wizards
Subject: Re: RCS
Message-ID: <10243@bloom-beacon.MIT.EDU>
Date: 1 Apr 89 07:38:15 GMT
References: <5372@lynx.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Distribution: na
Lines: 68

In article <5372@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes:
>When a file is checked out (with co) of an RCS directory, it seems to me
>that it would be nice if the modification date were set to the date of
>the revision.

That's exactly what I thought.  I'm a stickler for modification
time preservation, so this was a requirement of mine for any
revision control system I might use.  RCS seemed quite powerful
otherwise, so I went in and modified it, with the following
results:

     1.	The time associated with a revision is its original
	modification time, not the time of checkin.

     2.	When a new revision is checked in on the main branch, the
	RCS (,v) file inherits the time of the revision being
	checked in.  If ci -u or -l is used, the working copy's
	modification time is preserved, notwithstanding any
	keywords which may have been expanded.

     3.	When any revision is checked out, its original
	modification time is resurrected.

     4.	The rcs command preserves the modification time of the
	RCS (,v) file.

I want the modification time of a source file to reflect the last
time I did something to it, not the last time it was copied (I
use the equivalent of cp -p) checked in or out of RCS, or
otherwise manipulated by system utilities.

I arranged for the time of the RCS (,v) file to reflect the time
of the head revision on the main branch so that ls -lt on the RCS
directory gives sensible results, again based on the last time I
edited a file.  Among other things, this makes it easy to see
what needs checking in, by comparing ls -lt of the RCS directory
with the working directory.

Playing with modification times under RCS in this way has two
disadvantages:

     1.	The timestamps in the RCS file no longer record checkin
	time; this information is lost.  I have never really
	missed having this information.

     2.	As has been adequately discussed, there can be problems
	with make when old versions are checked out, or when
	keywords are expanded.  I simply remember to delete the
	.o file when I check out an old revision, and I don't use
	keywords any more, because for me they're more trouble
	than they're worth.  (You can never compare .o files that
	ought to be identical, because they might contain
	different RCSid's.)

I grant that there's a lot of personal preference involved here,
and that having to remember to manually delete .o files can be
problematical.  For me, having modification times changing every
time RCS blinked would be unthinkable; I've been very pleased,
and have had no problems, using this modified version of RCS.

I could probably be persuaded to make context diffs available, if
anyone else is interested in these modifications.  If you're not
interested, or if you think I'm crazy for having RCS behave this
way, all you have to do is not ask me for them.  (I bet somebody
posts a followup telling me that I'm wrong, anyway.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu