jennyk@dartvax.UUCP (Jennifer Kortfelt) (10/18/84)
We're maintaining a large group of programs and would like to use
either sccs or rcs, but they don't seem to be compatible with make.
Has anyone had any experience with using these together?
According to current practice.......advTHANKSance
Jennifer Kortfelt
USNET: {linus|decvax|cornell|astrovax}!dartvax!jennyk
ARPA: jennyk%dartmouth@csnet-relay
CSNET: jennyk@dartmouthjlw@ariel.UUCP (10/20/84)
AT&T UNIX make is pretty incompatible with SCCS.
There are two main reasons:
1. SCCS uses a dating structure internal to the text of the
file, stored in the delta records of the header.
Make, on the other hand, uses only UNIX's idea of when
the file was changed. This can actually be dangerous
when combined with the absolutely brain-damaged rule
supplied with make for dealing with SCCSfiles. To wit:
get -p SCCSfile > object
This is diametrically opposed to SCCS's idea of what type
of file permissions warrant protection. In SCCS a file
out for editing, `get -e', and therefore writable is precious
and not to be overwritten, whereas a file obtained with plain
`get' is recreatable and does not need to be preserved.
I think that the rule should be something like:
if [ ! -w object ] then get SCCSfile
Think about what happens in the following scenario:
Monday: Programmer `get -e SCCSfile.c'
ed file.c; etc.
Tuesday: Programmer more ed file.c; etc
Wednesday: Source Administrator makes global
change to headers of all project source
files.
Thursday: Programmer `make's a new version
and wipes out two day's work.
Friday: Programmer realizes what went wrong and
goes on binge.
Saturday: Programmer meets Source Administrator
in bar and wastes him in cold blood and
we have another tragedy for our criminal court
system.
2. SCCS today uses leading context and make uses trailing context.
For example in SCCS
get s.file.c -> file.c
and in make this becomes
.c~ -> .c -> .o (with perhaps intermediate steps) -> (nothing)
This is pretty ugly. Does anyone out there remember
the first version of SCCS to run on UNIX which had the name
of the SCCSfile as plain file?
get file -> file.c (or .a or .s if the internal language flag
was set to C, unrecognized, or assembler respectively)
The above statement about SCCS versions means that there was an
original version of SCCS written by Mark Rochkind at BTL PY which
was either in spitbol or snobol4 and used the Librarian package
as its primmary storage medium. He then transferred this to PWB
UNIX as SCCS 2 in about 1974 or thereabouts. This was subsequently
completely redone by Alan Glasser in say 1976 as SCCS 3 which went
out to the public as simply SCCS. As far as I know the original
version of SCCS is still being used by BCR at PY.
Joseph L. Wood, III
AT&T Information Systems
Laboratories, Holmdel
(201) 834-3759
ariel!jlwjlw@ariel.UUCP (10/20/84)
It occurred to me upon reading my article that I completely forgot to mention that the first version of SCCS ran on IBM hardware under either OS/MFT or OS/MVT. Joseph L. Wood, III AT&T Information Systems Laboratories, Holmdel (201) 834-3759 ariel!jlw
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (10/22/84)
> We're maintaining a large group of programs and would like to use > either sccs or rcs, but they don't seem to be compatible with make. > Has anyone had any experience with using these together? ??? "Make" and SCCS have been very well integrated ever since UNIX System III.
chris@pixutl.UUCP (chris) (10/25/84)
> Wednesday: Source Administrator makes global > change to headers of all project source > files. > > Thursday: Programmer `make's a new version > and wipes out two day's work. > The problem of overwriting source files if the SCCS parent file was modified can be helped a great deal by changing the $(GET) lines in rules.c from: "\t$(GET) $(GFLAGS) -p $< > $*.c", to: "\t$(GET) $(GFLAGS) $<", and let 'get' check if the file is writable. I have done this and prefer it to the original. I have also modified 'make' to look for SCCS files in a ./SCCS directory if it doesn't find them in the current directory (I like to keep SCCS files in a their own directory), and if anybody is interested, I will send them the changes or post them. Chris -- Chris Bertin : (617) 657-8720 x2318 Pixel Computer Inc. : 260 Fordham Rd. : {allegra|ihnp4|cbosgd|ima|genrad|amd|harvard}\ Wilmington, Ma 01887 : !wjh12!pixel!pixutl!chris
jlw@ariel.UUCP (J.WOOD) (10/28/84)
I like Chris's proposal in the current environment. My scenario still holds, but this time the programmer gets a make error message. Joseph L. Wood, III AT&T Information Systems Laboratories, Holmdel (201) 834-3759 ariel!jlw
ekb@link.UUCP (Eric K. Bustad) (10/29/84)
> > We're maintaining a large group of programs and would like to use > > either sccs or rcs, but they don't seem to be compatible with make. > > Has anyone had any experience with using these together? > ??? "Make" and SCCS have been very well integrated ever since UNIX > System III. "Very well integrated?" Some kludges were added to Make so that it could halfway reasonably handle SCCS files. I'm not knocking what was done, as it would have required a complete redesign for Make to interface reasonably with SCCS or RCS. But they are hardly "very well integrated!" = Eric Bustad (AT&T Bell Laboratories, Holmdel NJ) (201)949-6257 ihnp4!eric.bustad or link!ekb
crl@pur-phy.UUCP (Charles LaBrec) (10/29/84)
Sometime this summer, I submitted to the USENIX organization a modified 4.1 BSD version of make that includes support for RCS. I'm not sure whether or not the USENIX tape was ever released. If it was, then I'd appreciate hearing about it, and whether or not it works at your site. As far as I know, it works on V7, 2.8 BSD, and 4.x BSD. I described it once before, so I won't again, unless everyone really wants me to post it again. Charles LaBrec UUCP: pur-ee!Physics:crl, purdue!Physics:crl INTERNET: crl @ pur-phy.UUCP
jss@sftri.UUCP (J.S.Schwarz) (10/30/84)
>
The underlying cause of the problem is SCCS's peculiar notion of the
meaning of the "w" bit. It is not just "make" that doesn't understand
this idea. Almost all other utilities (such as "cp" and "rm") believe
that you will turn off the "w" bit if you want a file to be treated
with extra care. SCCS believes exactly the opposite. For example, you
have gotten several files in a directory, some with -e and some
without. You now accidentally do an "rm *". What happens? The
files you have spent hours editing are removed, but the ones you can
easily recreate are not.
Jerry Schwarz
Bell Labs
Summit, N.J.arnold@ucsfcgl.UUCP (Ken Arnold%UCB) (11/02/84)
>The underlying cause of the problem is SCCS's peculiar notion of the >meaning of the "w" bit. It is not just "make" that doesn't understand >this idea. Almost all other utilities (such as "cp" and "rm") believe >that you will turn off the "w" bit if you want a file to be treated >with extra care. SCCS believes exactly the opposite. For example, you >have gotten several files in a directory, some with -e and some >without. You now accidentally do an "rm *". What happens? The >files you have spent hours editing are removed, but the ones you can >easily recreate are not. > >Jerry Schwarz >Bell Labs >Summit, N.J. I think we have a mistaken idea here. The 'w' bit controls whether the file is writeable. It does NOT mean "take extra care with this file". The behavior you note is consistent with this meaning. rm If you can't write a file, should you really be deleting it entirely? sccs, rcs If you don't have a file checked out for editing, you shouldn't be modifying the contents. If you check out a file to edit it, you damn well better be able to write on it. You are mistaking "rm" and "mv"'s behavior as "This file is precious". It is really just saying "Removing this file seems strange, are you sure?" 'w' == write access. If you want something like this, you'll have to add a "precious" bit. Ken Arnold