CAROFF@ames-vmsb.ARPA (06/29/84)
Could someone point me in the direction of documentation on SCCS and particularly RCS. I know sccs is of berkeley origin, but what about rcs. Would makes it? Are there other system which help maintain software which are better. Thanks Michael Dove caroff@ames-vmsb ------
mike@BRL-TGR.ARPA (06/29/84)
From: Mike Muuss <mike@BRL-TGR.ARPA> The feature that I like best is RSCMERGE (aka "co -j"). This allows changes from two diverging streams of development to be merged. Personally, I use this to cope with merging local changes to the kernel with changes from elsewhere. Both systems have a common origin (the distribution). SCCS may have this capability, but I couldn't say. -Mike
gwyn@BRL-VLD.ARPA (06/30/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> Funny that you should know that SCCS is of Berkeley origin. I rather thought Mashey & crew had developed it as part of the PWB project at Bell Labs. SCCS is now a standard part of UNIX System III and V, and is described in the documentation accompanying those systems. RCS started as a "public domain" equivalent (by Walter Tichy of Purdue) and is distributed with 4.2BSD. We use both at BRL and they each have strong and weak points. One of the nicest things about SCCS these days is the support for it in the "make" utility. Many of our application codes are maintained as a collection of SCCS archives; typing "make install clobber" in the appropriate directory extracts the makefile and all the required sources from the archives, and cleans up after the product has been tested and installed. Automation is great. A complete software project management system would need much more than just a source document revision control system. There have been many such more complete systems discussed at USENIX conferences (MASCOT comes to mind, and Mashey discussed such a system a couple years ago).
dave@rlgvax.UUCP (Dave Maxey) (07/10/84)
You may obtain information by contacting the author of RCS at Purdue:
U.S.nail:
Walter F. Tichy
Department of Computer Science
Math Science Building
Purdue University
West Lafayette, Indiana 47907
Phone:
(317) 494-1998
Net:
tichy@purdue
or
allegra!purdue!tichy
or (if the above doesn't work)
seismo!harpo!pur-ee!purdue!tichy
Good hunting!
- Dave Maxey (alias tbm)
{seismo,mcnc,brl-bmd,allegra}!rlgvax!daveguy@rlgvax.UUCP (07/13/84)
"make" can be easily modified to support RCS as well; we've modified the
System III "make" to do it. Instead of using the "~.c.o" rules (which
require you to change the "~.c.o" rule every time you want to change the
".c.o" rule), we used some built-in code (used to automatically "get" the
Makefile) and hardcoded the checkout stuff. It's fairly smart - it knows
about RCS subdirectories, knows that to "check out" "../includes/foobar.h"
it should do "cd ../includes;co foobar.h", and doesn't check out things
only needed to remake things that it isn't going to remake.
One problem with not keeping source checked out, though, is that "grep"ping for
things is a *R*O*Y*A*L* *P*A*I*N*. Also, the System III/System V rebuild
procedures are unhappy, because if they don't find "frobozz.c" in
"/usr/src/cmd" they don't know that there's a "frobozz" command to be made.
(Then again, if they see "frobozz.c" and "frobozz.mk" or "frobozz.rc", they
make "frobozz". TWICE. So I'm not sure those rebuild procedures are that
great, anyway.) It also makes it hard to make source distribution tapes
if you aren't distributing the SCCS/RCS files (the 4.2BSD "tar" has a "-F"
option, presumably for making source distribution tapes, that has some
stuff to avoid writing things like SCCS directories), and makes it a pain to
FTP (or UUCP) source from other machines.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guygail@calmasd.UUCP (Gail Hanrahan) (07/13/84)
>A complete software project management system would need much more than >just a source document revision control system. There have been many >such more complete systems discussed at USENIX conferences (MASCOT >comes to mind, and Mashey discussed such a system a couple years ago). We're currently looking for a more complete system -- could someone please send me pointers to MASCOT, and anything else that might be available? Thanks, Gail Bayley Hanrahan {decvax,ucbvax}!sdcsvax!calmasd!gail Calma Company, San Diego P.S. I would have mailed this to gwyn@BRL-VLD.ARPA, but every time I attempt to send mail to arpanet sites, it gets bounced back to me as undeliverable. *sigh*
chris@umcp-cs.UUCP (07/14/84)
There is a version of make that goes with RCS (called---what else?
---rcsmake) which should probably be distributed with RCS. (I don't
know if it *is*, but it ought to be.) It sounds like it's pretty
much equivalent to SCCS make.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci (301) 454-7690
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandbarto@celerity.UUCP (07/16/84)
Believe it or not, we here at celerity have been using RCS-make
for about a year now. It really exists and does work.
We have a version as done by parsec!fuka on 4/15/83, from
the sources posted to net.source by unc!jem.
I should like to here from them on the issue. This also has the nice
feature of a '.PREFIXES', to list the method of search in directories.
(It defaults to '. ./RCS'!)
--
barto (david barto) Tele : (619) 271 9940
uucp : {decvax || ucbvax || ihnp4}!sdcsvax!celerity!barto
uucp : akgua!celerity!barto
arpa : sdcsvax!celerity!barto@NOSCgwyn@BRL-VLD.ARPA (07/16/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> There is a paper on MASCOT by Ken Jackson of Systems Designer Ltd., Systems House, 1 Pembroke Road, Camberley, Surrey, England in the /usr/group / USENIX Association / Software Tools Users Group Joint Conference Proceedings, Boston, July 1982, on p. 93 ff. There is a reference given: "Official Handbook of MASCOT", MASCOT Suppliers Association, RSRE, Malvern, Worcs, U.K.
crl@pur-phy.UUCP (Charles LaBrec) (07/31/84)
Well, I guess I can let the cat out of the bag now. We run RCS here on a PDP-11/44 running 2.8 BSD, and we immediated noted the problems using RCS with make. I therefore undertook the project of improving make. As of this date, the software has been given to the USENIX tape people, so please refrain from asking me for a copy--they do a much better job at redistributing licensed code than I could do. It has been tested on 2.8 BSD, 4.1, 4.1c, and 4.2, and seems to be bug free (well, I think so, at least). Here's how it works: Two modes were added to make, auto-checkout and auto-delete. By default, both of these are on. When make looks up a file, say "foo.h", if it doesn't exist and auto-checkout is on, it looks in "RCS/" first and then "." for a "foo.h,v". If it finds one, it remembers the fact that the file is in RCS and uses the mtime of the RCS file as the mtime of the (non-existent) working file. If at some time it needs to invoke a rule that depends on this working file, it invokes the rule ".CO:" which is usually "co -q $@", for every working file that does not already exist. Furthermore, it sets the mtime of the checked out file to be equal to that of the RCS file. This is important, because it means that a .h file auto-checked out does not cause recompilation of all later objects. If auto-delete is on, it remembers this checked out file for later deletion. On exit, these files are removed unless the normal ".PRECIOUS" rule applies. Comparing this to the Sys V make, I believe it is better because of the games it plays with modified times. Furthermore, it lints! I have no idea when the USENIX tape will be ready for distribution. Charles LaBrec UUCP: pur-ee!Physics:crl, purdue!Physics:crl INTERNET: crl @ pur-phy.UUCP