pete@esosun.UUCP (06/04/87)
Is RCS fading away? Who is distributing it with their systems
these days -- Sun and Alliant do not. I always thought RCS
had more features and is faster then SCCS; why does Sun prefer
SCCS? On what machines can I count on make supporting
either RCS or SCCS?
--
{seismo,sdcsvax}!esosun!pete (Pete Ware) (619) 458-2520avolio@decuac.UUCP (06/04/87)
pete@esosun.UUCP (Pete Ware) asks: >Is RCS fading away? Who is distributing it with their systems >these days -- Sun and Alliant do not. I always thought RCS >had more features and is faster then SCCS; why does Sun prefer >SCCS? On what machines can I count on make supporting >either RCS or SCCS? Ultrix-32 has both SCCS and RCS. RCS is under the Unsupported subsets while SCCS is Supported. (Read warrantied for support...) By the way, SCCS with Ultrix is System V's SCCS, not the one distributed with BSD. I don't use either enough to comment on why one is better than the other. Fred
snoopy@doghouse.gwd.tek.com (Snoopy) (06/04/87)
In article <41@esosun.UUCP> pete@esosun.UUCP (Pete Ware) writes: |Is RCS fading away? Who is distributing it with their systems |these days -- Sun and Alliant do not. I always thought RCS |had more features and is faster then SCCS; why does Sun prefer |SCCS? On what machines can I count on make supporting |either RCS or SCCS? |-- | |{seismo,sdcsvax}!esosun!pete (Pete Ware) (619) 458-2520 UTek comes with RCS, and we use it extensively internally. SCCS is also provided. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com Disclaimer: This is me speaking, not Tektronix.
rbj@icst-cmr.arpa (06/05/87)
From: Pete Ware <pete@esosun.uucp> Date: 4 Jun 87 00:24:10 GMT Is RCS fading away? Who is distributing it with their systems these days -- Sun and Alliant do not. I always thought RCS had more features and is faster then SCCS; why does Sun prefer SCCS? On what machines can I count on make supporting either RCS or SCCS? Sequent distributes RCS as part of their system. They are basically 4.2 based, altho they run Doug Gwyn's System V emulation, supporting parallel `universes' much like Pyramid does. Sequent also distributes GNU EMACS as User Contributed software. I don't know why SUN doesn't, altho they seem bent towards Unipress in a lisp distribution I saw. I guess vendors stick together. (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688
guy@gorodish.UUCP (06/05/87)
> Is RCS fading away? Define "fading away". Have people *stopped* providing or supporting it? If it's just that some people never *started* providing it or supporting it, this can hardly be said to indicate that it's "fading away". > I always thought RCS had more features and is faster then SCCS; why does > Sun prefer SCCS? Define "prefer". We use SCCS in house, for what is probably a combination of technical and historical reasons. We only supply SCCS with our systems, probably because we don't want to have to support the user-supplied software that comes with 4.3BSD (note that DEC doesn't support RCS, either, they just supply it - see the article from Frederick Avolio of DEC). In short, we "prefer" to use SCCS, and we "prefer" not to have to support RCS. RCS has features that SCCS doesn't, and *vice versa*; the only really big feature that RCS has and SCCS doesn't that I wish SCCS did is symbolic version numbers. RCS is faster for the common case where you're retrieving the latest version, although SCCS is faster for retrieving earlier versions and, I'm told, when dealing with branches. (The time to retrieve a version from SCCS is pretty much constant; the time to retrieve a version from RCS increases the older the revision or, more generally, the more changes have to be applied to the version "currently" stored in the RCS file.) If you have the source to the version of RCS that came with 4.3BSD, and are running SunOS 3.2 or later, you can bring up RCS by applying a patch to keep it from dereferencing a null pointer. It won't be supported by us, but as I mentioned other people don't support RCS either, even though they supply it. Here's the patch; it also includes other bug fixes from Jay Lepreau, Ray Chen, and me: diff -c old/ci.c new/ci.c *** old/ci.c Tue Jan 27 13:43:23 1987 --- new/ci.c Tue Jan 27 13:58:01 1987 *************** *** 123,128 **** --- 123,129 ---- { register int i; register char * sp, *tp; + char * nametest; char * cmdusage; /* holds command format */ char command[NCPPN+50]; /* holds diff commands */ char curdate[datelength];/* date for new delta */ *************** *** 194,200 **** if ((*argv)[2]!='\0'){ if (symbol!=nil)warn("Redefinition of symbolic name"); symbol = (*argv)+2; ! checkid(symbol,' '); } else warn("Missing name for -n option"); break; --- 195,202 ---- if ((*argv)[2]!='\0'){ if (symbol!=nil)warn("Redefinition of symbolic name"); symbol = (*argv)+2; ! if (!(nametest=checkid(symbol,' '))||*nametest) ! faterror("Name %s must be one word",symbol); } else warn("Missing name for -n option"); break; *************** *** 203,209 **** if ((*argv)[2]!='\0'){ if (symbol!=nil)warn("Redefinition of symbolic name"); symbol = (*argv)+2; ! checkid(symbol,' '); } else warn("Missing name for -N option"); break; --- 205,212 ---- if ((*argv)[2]!='\0'){ if (symbol!=nil)warn("Redefinition of symbolic name"); symbol = (*argv)+2; ! if (!(nametest=checkid(symbol,' '))||*nametest) ! faterror("Name %s must be one word",symbol); } else warn("Missing name for -N option"); break; diff -c old/rcs.c new/rcs.c *** old/rcs.c Tue Jan 27 13:43:25 1987 --- new/rcs.c Tue Jan 27 13:56:32 1987 *************** *** 988,993 **** --- 988,995 ---- trail = &dummy; while (next!=nil) { numr = strcmp(num, next->delta->num); + if (num!=nil) + numr = strcmp(num, next->delta->num); if ((whor=strcmp(who,next->login))==0 && (num==nil || numr==0)) break; /* found a lock */ diff -c old/rcsdiff.c new/rcsdiff.c *** old/rcsdiff.c Tue Jan 27 13:43:26 1987 --- new/rcsdiff.c Tue Jan 27 13:55:10 1987 *************** *** 2,8 **** * RCS rcsdiff operation */ static char rcsid[]= ! "$Header: rcsdiff.c,v 3.7 86/05/19 02:36:16 lepreau Exp $ Purdue CS"; /***************************************************************************** * generate difference between RCS revisions ***************************************************************************** --- 2,8 ---- * RCS rcsdiff operation */ static char rcsid[]= ! "$Header: rcsdiff.c,v 3.8 86/06/18 15:02:32 lepreau Exp $ Purdue CS"; /***************************************************************************** * generate difference between RCS revisions ***************************************************************************** *************** *** 20,25 **** --- 20,29 ---- /* $Log: rcsdiff.c,v $ + * Revision 3.8 86/06/18 15:02:32 lepreau + * I broke -c<number> in last rev. + * Also, mixing a bopt with an otheropt was broken. + * * Revision 3.7 86/05/19 02:36:16 lepreau * Pass on new diff options, and allow them to be clustered. * *************** *** 42,47 **** --- 46,52 ---- * Initial revision. * */ + #include <ctype.h> #include "rcsbase.h" static char rcsbaseid[] = RCSBASE; *************** *** 56,61 **** --- 61,67 ---- char * temp1file, * temp2file; char bops[10] = "-"; + char otherops[10] = "-"; main (argc, argv) int argc; char **argv; *************** *** 75,81 **** register c; catchints(); ! otheroption=""; boption = bops + 1; cmdid = "rcsdiff"; cmdusage = "command format:\n rcsdiff [-biwt] [-cefhn] [-rrev1] [-rrev2] file"; --- 81,87 ---- register c; catchints(); ! otheroption = otherops + 1; boption = bops + 1; cmdid = "rcsdiff"; cmdusage = "command format:\n rcsdiff [-biwt] [-cefhn] [-rrev1] [-rrev2] file"; *************** *** 106,113 **** case 'f': case 'h': case 'n': ! if (*otheroption=='\0') { ! otheroption= argp-2; } else { faterror("Options c,e,f,h,n are mutually exclusive"); } --- 112,126 ---- case 'f': case 'h': case 'n': ! if (otheroption == otherops + 1) { ! *otheroption++ = c; ! if (c == 'c' && isdigit(*argp)) { ! while (isdigit(*argp)) ! *otheroption++ = *argp++; ! if (*argp) ! faterror("-c: bad count"); ! argp = ""; ! } } else { faterror("Options c,e,f,h,n are mutually exclusive"); } *************** *** 117,125 **** }; } /* end of option processing */ if (boption != bops + 1) { ! *boption = ' '; boption = bops; } if (argc<1) faterror("No input file\n%s",cmdusage); /* now handle all filenames */ --- 130,142 ---- }; } /* end of option processing */ if (boption != bops + 1) { ! *boption = ' '; boption = bops; } + if (otheroption != otherops + 1) { + *otheroption = ' '; + otheroption = otherops; + } if (argc<1) faterror("No input file\n%s",cmdusage); /* now handle all filenames */ *************** *** 166,172 **** } if (revnums<=1) { temp2file=workfilename; ! diagnose("diff %s%s -r%s %s",boption,otheroption,xrev1,workfilename); } else { temp2file=mktempfile("/tmp/",TMPFILE2); diagnose("retrieving revision %s",xrev2); --- 183,189 ---- } if (revnums<=1) { temp2file=workfilename; ! diagnose("diff %s%s-r%s %s",boption,otheroption,xrev1,workfilename); } else { temp2file=mktempfile("/tmp/",TMPFILE2); diagnose("retrieving revision %s",xrev2); *************** *** 176,184 **** error("co failed"); continue; } ! diagnose("diff %s%s -r%s -r%s",boption,otheroption,xrev1,xrev2); } ! sprintf(command,"%s %s %s %s %s\n",DIFF,boption, otheroption, temp1file, temp2file); exit_stats = system (command); if (exit_stats != 0 && exit_stats != (1 << BYTESIZ)) { --- 193,201 ---- error("co failed"); continue; } ! diagnose("diff %s%s-r%s -r%s",boption,otheroption,xrev1,xrev2); } ! sprintf(command,"%s %s%s%s %s\n",DIFF,boption, otheroption, temp1file, temp2file); exit_stats = system (command); if (exit_stats != 0 && exit_stats != (1 << BYTESIZ)) { diff -c old/rcsutil.c new/rcsutil.c *** old/rcsutil.c Tue Jan 27 13:43:31 1987 --- new/rcsutil.c Tue Jan 27 13:51:20 1987 *************** *** 178,188 **** void catchints() { ! signal(SIGINT,catchsig); signal(SIGHUP,catchsig); ! signal(SIGQUIT,catchsig); signal(SIGPIPE,catchsig); ! signal(SIGTERM,catchsig); } void ignoreints() { signal(SIGINT,SIG_IGN); signal(SIGHUP,SIG_IGN); --- 178,196 ---- void catchints() { ! cksignal(SIGINT); cksignal(SIGHUP); ! cksignal(SIGQUIT); cksignal(SIGPIPE); ! cksignal(SIGTERM); } + + cksignal(sig) + int sig; + { + if (signal(sig,SIG_IGN) != SIG_IGN) + VOID signal(sig,catchsig); + } + void ignoreints() { signal(SIGINT,SIG_IGN); signal(SIGHUP,SIG_IGN); *************** *** 204,210 **** while ((--inf->_cnt)>=0) { putc(*inf->_ptr++&0377,outf); } ! fflush(outf); /*now read the rest of the file in blocks*/ while ((rcount=read(fileno(inf),buf,BUFSIZ))>0) { --- 212,220 ---- while ((--inf->_cnt)>=0) { putc(*inf->_ptr++&0377,outf); } ! if (fflush(outf) == EOF) { ! faterror("write error"); ! } /*now read the rest of the file in blocks*/ while ((rcount=read(fileno(inf),buf,BUFSIZ))>0) { Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
guy@gorodish.UUCP (06/05/87)
> By the way, SCCS with Ultrix is System V's SCCS, not the one distributed > with BSD. I don't use either enough to comment on why one is better than > the other. The SCCS distributed with System V is infinitely superior to the one distributed with BSD, for one simple reason - the one distributed with BSD doesn't exist. The "sccs" front-end command is distributed with 4BSD, but none of the SCCS commands are. (This raises an interesting question about "dual-universe" systems - do they supply the "sccs" front end only in the 4BSD universe and the SCCS commands only in the System V universe, and if so can the "sccs" front end use the SCCS commands?) Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/05/87)
Speaking of SCCS, I recently fixed a problem I had introduced into the version shipped as part of the BRL UNIX System V emulation for 4.nBSD. Unless you received your tape within the past month, there is a good chance that "prs", "comb", and perhaps one other infrequently-used SCCS utility reports that an SCCS archive is corrupted when it isn't. The bug appeared when I integrated in a fix that Gould had come up with; their fix wasn't quite right, but my attempt to fix the fix was totally wrong! If your version has this problem, please contact me and I'll send you instructions about how to fix the fixed fix.
csg@pyramid.UUCP (Carl S. Gutekunst) (06/05/87)
In article <20394@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >This raises an interesting question about "dual-universe" systems - do they >supply the "sccs" front end only in the 4BSD universe and the SCCS commands >only in the System V universe, and if so can the "sccs" front end use the >SCCS commands? On Pyramid's dual port, anyway, we just used hard links to bring all the SCCS commands from /usr/bin in the System VR3 universe (/usr/.attbin) into /usr/bin in the BSD universe (/usr/.ucbbin). That seemed to be what most users wanted, and those that don't like it are encouraged to make libaral use of rm. :-) The alternatives would be to either run the BSD sccs command in the 'att' universe, att /usr/.ucbucb/sccs or to add /usr/.attbin to the PATH environment variable. I do this anyway, so that I get the BSD versions of commands when they exist, but I automatically get SVR3-unique commands too. Most other dual-ports should behave similarly. (Note that system calls and libraries are bound at load time, while directory trees are determined at run time.) BTW, Pyramid also provides RCS as a fully-supported product. We've also made local enhancements (such as preservation of m_time on checkin and checkout). It lives in /usr/new, which is visible from both universes. <csg>
pete@esosun.UUCP (06/05/87)
In article <20393@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >Define "fading away". Fading away means it is available at proportionally fewer sites compared to some short time ago. Dying means it is availabe at fewer sites then some short time ago. >Define "prefer". Preferring SCCS means it is used in house and supported whereas RCS is not used in house and is not provided. I certainly sympathize with not wanting to support two source control systems, however I would like to be able to choose one or the other (even if one is not supported). I was looking for a technical reason (which is why I sited Sun, because I knew they used SCCS and I knew you (Guy) would provide a response) for using SCCS vs RCS. The chief argument against RCS is that SCCS is more widely available (and supported). On the other hand, I was hoping to get a slew of responses saying, "Yes, RCS is supported/provided on our machine" and remove this argument against RCS. > (The time to retrieve a >version from SCCS is pretty much constant; the time to retrieve a >version from RCS increases the older the revision or, more generally, >the more changes have to be applied to the version "currently" stored >in the RCS file.) > I thought the time to retrieve a version from SCCS was proportional to the number of changes since the original version was created. In other words, a lot of versions implies slow retrieve time for SCCS. I'd imagine the time to retrieve intermediate versions (i.e. between 1.1 and the current version) is completely dependant on the number of changes between (1.1 for SCCS and current version of RCS) and the desired version. I mentioned make because I also wanted to know those systems that I can count on typing "make" and have it retrieve the appropriate files from SCCS/RCS without having to go and check out every file in sight. Thanks for posting the diffs. I'm sure many people will appreciate it -- {seismo,sdcsvax}!esosun!pete (Pete Ware) (619) 458-2520
guy@gorodish.UUCP (06/06/87)
> Fading away means it is available at proportionally fewer sites compared > to some short time ago. Dying means it is availabe at fewer sites then > some short time ago. What if it's available at more, but proportionally fewer, sites than some short time ago? "Fading away" is a loaded term, implying that it is losing favor; it may just not be *gaining* sufficient favor to encourage more vendors to adopt it. > I thought the time to retrieve a version from SCCS was proportional > to the number of changes since the original version was created. In > other words, a lot of versions implies slow retrieve time for SCCS. > I'd imagine the time to retrieve intermediate versions (i.e. between 1.1 > and the current version) is completely dependant on the number of changes > between (1.1 for SCCS and current version of RCS) and the desired version. Nope. The time to retrieve a version from SCCS is proportional to the size of the file, and to the number of lines that have been changed in all the versions checked in, but is independent of the version being retrieved. SCCS does not store forward "diff"s; it stores text lines, and control lines that say "the next batch of lines first appear in version N", "the next batch of lines disappear in version M", etc.. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
kai@uicsrd.UUCP (06/09/87)
Sequent distributes RCS with their systems (binary only). Alliant distributes SCCS with their systems, but I'm told that they actually use RCS in house. I wrote to Walter Tichey (the author of RCS) for permission for me to bring RCS up on KAI's Alliant FX/8 as well. Someone on campus at University of Illinois did some comparisions between revision control systems. I forget what program it was that was chosen as the best, but I do remember that RCS was better rated than SCCS. Patrick Wolfe internet: pat@kai.com System Manager uucp: seismo!kailand!pat Kuck & Associates, Inc. bitnet: pat%kailand@uiucuxc 1808 Woodfield Dr. csnet: pat%kailand%uxc@uiuc.csnet Savoy, IL 61874 milnet: pat%kailand@uiucuxc.arpa (217) 356-2288 telex-2: 9102409772
allbery@ncoast.UUCP (Brandon Allbery) (06/11/87)
As quoted from <42@loki.esosun.UUCP> by pete@esosun.UUCP (Pete Ware): +--------------- | I mentioned make because I also wanted to know those systems that I | can count on typing "make" and have it retrieve the appropriate files | from SCCS/RCS without having to go and check out every file in sight. +--------------- Well, if you're willing to forego the RCS directory (TDI's and ncoast's versions of SCCS don't have subdirectories, so I never bothered to use RCS subdirectories), you can build RCS-handling make dependencies. I generally put an "include $(HOME)/.makedefs" in my Makefiles; this file sets SHELL to /bin/sh (since I use csh) and sets up the following rules: CO = co .SUFFIXES: .c,v .h,v .c,v.o: $(CO) -q $*.c $(CC) $(CFLAGS) -c $*.c /bin/rm -f $*.c .c,v.c: $(CO) -q $*.c .h,v.h: $(CO) -q $*.h It works fine, with a standard SysIII/SysV augmake. The only minor problem is that .h files checked out don't get removed afterward; I usually keep .h files checked out anyway, so it doesn't bother me much. ++Brandon -- Copyright (C) 1987 Brandon S. Allbery. Redistribution permitted only if the redistributor permits further redistribution. ---- Moderator for comp.sources.misc ---- Brandon S. Allbery {decvax,cbosgd}!cwruecmp!ncoast!allbery aXcess Company {ames,mit-eddie,talcott}!necntc!ncoast!allbery 6615 Center St. #A1-105 necntc!ncoast!allbery@harvard.HARVARD.EDU Mentor, OH 44060-4101 +01 216 974 9210 (also eddie.MIT.EDU)
mayer@rocksanne.UUCP (Jim Mayer) (06/18/87)
Another way to use RCS with make is to:
1. Make all dependencies explicit in the makefile. The best way
is to generate them automatically with one of the "make depends"
hacks that are floating around the network. On 4.3 systems you
can use "cc -M" to generate a list of dependencies.
2. Add a ".DEFAULT" entry to your makefile that tries to check
out the "to be made" file.
This scheme works even with the use of an RCS directory. For example,
under 4.3 you can use:
----------------------- START OF EXAMPLE ------------------------
depends: all your source files
mv -f Makefile Makefile.orig
(sed -e '/^#DEPENDS/,$$d' Makefile.orig ; \
echo "#DEPENDS" ; \
cc -M $(CFLAGS) $$< \
) > Makefile
.DEFAULT:
co -q $@
------------------------ END OF EXAMPLE -------------------------
If you don't have "cc -M", you can replace it with call to the
following shell script (cc -E just invokes "cpp"):
----------------------- START OF SCRIPT ------------------------
#! /bin/sh
#
# Produce a list of object file dependencies from a list of sources.
#
# depends [options] name...
#
options=
while true
do
case "${1-xxx}" in
-I|-o)
options="$options $1 ${2?No second argument for -I}"
shift; shift
;;
-*)
options="$options $1"
shift
;;
*)
break
;;
esac
done
for file in $@
do
object=`expr "$file" : "\(.*\)\..*"`.o
if test ".o" = "$object"
then
object="$file.o"
fi
cc $options -E $file | sed -n -e "s/^# 1 \"\(.*\)\"\$/$object: \1/p"
done
------------------------ END OF SCRIPT -------------------------
-- Jim
--
(Grapevine) mayer.wbst (Arpa) mayer.wbst@Xerox.com
(NS) mayer:wbst128:xerox (Phone) (716) 422-9407
(UUCP) {seismo|allegra}!rochester!rocksanne!mayerchris@mimsy.UUCP (Chris Torek) (06/19/87)
In article <392@rocksanne.UUCP> mayer@rocksanne.UUCP (Jim Mayer) writes: > -I|-o) > options="$options $1 ${2?No second argument for -I}" > shift; shift The -I flag takes the include path without a space, i.e., cc -I. -I../h foo.c so this should be modified a bit. > object=`expr "$file" : "\(.*\)\..*"`.o > if test ".o" = "$object" > then > object="$file.o" > fi > cc $options -E $file | sed -n -e "s/^# 1 \"\(.*\)\"\$/$object: \1/p" This last fails if "$file" contains slashes: ... -I. -I../h ../gorp/foo.c Here is the script I provide with the current ctex. I avoided `cc -E', assuming that the -E option may not exist in some `cc's. It should be obvious how to change this as appropriate for your system. The dependency extraction scheme here is rather more complex, so as to depend less upon whatever features are peculiar to the Reiser cpp. Whether it will be successful is another matter. : getdep - get dependency lists. : change ":" comments to "#" comments if your shell supports those; : the result will run faster. : find cpp cpp=unknown for where in /lib /usr/lib /bin /usr/bin; do if test -f $where/cpp; then cpp=$where/cpp; break; fi done if test $cpp = unknown; then echo "I cannot find cpp, sorry" 1>&2; exit 1 fi : handle arguments incl= for i do case "$i" in -I*) incl="$incl $i";; *) : assume source file : put '$dep' in front of dependencies dep=`echo "$i" | sed -e 's,/,\\\\/,g' -e 's/\.c$/.o/'` : Find includes, remove leading numerics, remove ./, : remove double quotes, and remove trailing numerics. : Sort that, discarding duplicates, and add '$dep'. $cpp $incl "$i" | grep "^#" | sed -e 's/# [0-9]* //' -e 's,"./,",' -e 's/"\(.*\)"/\1/' \ -e 's/ [ 0-9]*$//' | sort -u | sed -e "s/^/$dep: /";; esac done -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: seismo!mimsy!chris
roger@celtics.UUCP (06/19/87)
In article <42@loki.esosun.UUCP> pete@esosun.UUCP (Pete Ware) writes: >I was hoping to get a slew of responses saying, "Yes, RCS is >supported/provided on our machine" and remove this argument against RCS. OK, here goes... "Yes, RCS is supported/provided on our machines." (Both provided and supported.) (Then again, so is SCCS...) -- ///==\\ (No disclaimer - nobody's listening anyway.) /// Roger B.A. Klorese, CELERITY (Northeast Area) \\\ 40 Speen St., Framingham, MA 01701 +1 617 872-1552 \\\==// celtics!roger@seismo.CSS.GOV - seismo!celtics!roger
jerryp@tektools.TEK.COM (Milan Moncilovich) (06/21/87)
In article <2615@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: >As quoted from <42@loki.esosun.UUCP> by pete@esosun.UUCP (Pete Ware): >+--------------- >| I mentioned make because I also wanted to know those systems that I >| can count on typing "make" and have it retrieve the appropriate files >| from SCCS/RCS without having to go and check out every file in sight. >+--------------- > >Well, if you're willing to forego the RCS directory (TDI's and ncoast's >versions of SCCS don't have subdirectories, so I never bothered to use >RCS subdirectories), you can build RCS-handling make dependencies. If your flavor of make has a .PREFIXES list, you can use RCS subdirectories, too. Just add this .PREFIXES list: .PREFIXES: ./RCS Then, if make can't find the RCS (,v) file in the current directory, it'll look in the ./RCS subdirectory. Since "co" doesn't mind checking out files from other directories, this trick works great. --Jerry Peek uucp-style: {allegra,decvax,hplabs,ihnp4,ucbvax}!tektronix!tektools!jerryp Domain-style: jerryp@tektools.TEK.COM I don't speak for Tektronix or its employees.