Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site varian.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!decwrl!amd!dual!zehntel!varian!david
From: david@varian.UUCP (David Brown)
Newsgroups: net.unix
Subject: RCS + modification time?
Message-ID: <257@varian.UUCP>
Date: Thu, 1-Nov-84 00:18:17 EST
Article-I.D.: varian.257
Posted: Thu Nov  1 00:18:17 1984
Date-Received: Sun, 28-Oct-84 07:41:34 EST
Distribution: net
Organization: Varian, Walnut Creek, CA
Lines: 53

We have recently converted from using SCCS to RCS on a large (6 programmers)
project, and have come across a problem involving RCS and make:

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.  As the cross assembler we are using (Microtec Z80
cross assembler, written in Fortran) is very slow, we would prefer
to avoid unnecessary compilations.

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).

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.
We do use group write permission sometimes, but I think we can avoid that.

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.

-- 
	David Brown	 (415) 945-2199
	Varian Instruments 2700 Mitchell Dr.  Walnut Creek, Ca. 94598
	{zehntel,amd,fortune,resonex}!varian!david