RCS + modification time?

[Steve Glaser]

Summary:
Expires:
References: <varian.257>
Sender:
Reply-To: steveg at hammer.UUCP (Steve Glaser)
Followup-To:
Distribution: net
Organization: Tektronix, Inc., Wilsonville, OR
Keywords:

In article <varian.257> david at varian.UUCP (David Brown) writes:

> When a user checks out a file for edit, the lock information is placed
> in the ,v file itself (as opposed to SCCS, which created a separate
> lock file with a p. prefix).  This changes the modification time of the
> ,v file, and if someone else does a make on the system before the
> editing user does a check-in (ci) , that file will be recompiled
> unnecessarily.
>
> I have thought of a modification to co that would avoid unnecessary
> recompilations, but I want to get opinions from the net in case there
> are holes, security problems, etc.. I would also be interested in
> hearing from anyone who has made a similar change or found a better
> way around this problem. It seems to me that someone else should have
> run into this by now.
>
> Proposal:
> There is a system call (utime(2)) that allows you to set the times
> on a file to whatever you want, rather than the actual time. A quick
> grep through /usr/src/cmd/*.c found this call used only by the mv(1)
> command.
>
> Modify co to:
>	call stat(2) to find out original modification time of the ,v file
>	do normal processing (write lock info into file & close)
>	call utime(2) to set the modification time of the ,v file
>	back to the original time
>
> There will be a short window after the file is closed but before the
> modification time is set back, but it shouldn't be large enough to
> worry about a make coming through.
>
> Possible problems:
> 1) How does this affect dumps (my guess is that an incremental dump will not
> pick up the ,v file, so if we had to do a total restor, the ,v file will
> no longer be locked. I think I could live with that).

No problem.  There is another time (not settable bu utime(2)) that
records the modification time of the inode.  Incremental dumps use the
later of inode mod time or the normal mod time to decide what to dump.

> 2) utime must be called by superuser or by the owner of the file
> (at least according to the manual); this implies to me that utime can't
> be called by someone who only has group write permission on the ,v file.

No problem.  All RCS files get copied when you play with them.  The
last setp of the operation is to do a quick rename of the ,RCSxxxx temp
file to the real ,v file.  If you do the utime(2) against the ,RCSxxxx
file before the rename, there's not even a timing window where it's
wrong (rename does not change file mod time except that of the parent
directory).

> 3) You will not be able to find out the latest files that have been checked
> out by doing ls -lt in the RCS directory; you will need to use rlog.
> We could live with this too.

Right.

We made this change to our version of RCS (but under the control of the
new -P option).  It's useful on more than just co.  Supposed you check
out something with a lock and later decide you didn't need it after
all, a quick "rcs -P -u file" undoes the damage and doesn't change the
,v file time.

One further major gotcha with RCS.  The number of revisions is strictly
limited and the standard number is about 239 revisions.  We made it 719
and added a warning if you're within 20 of that.  If you overflow the
table, the ,v file becomes useless to RCS.

	Steve Glaser
	tektronix!steveg