brown@vidiot.UUCP (Vidiot) (10/08/89)
I received the answer that I needed in order to get RCS working on this SysV PC. I have also found out that there is a version 4 of RCS that works under both BSD and SysV. Unfortunately, I don't know where to fetch it. In any event, here is what was needed to fix the problem: >From texbell.swbt.com!letni!doug Below is an ftime() replacement; ------------------------------------------------------------------------------- #ifdef SCCSID static char *SccsId = "@(#)ftime.c 2.5 4/26/85"; #endif /* SCSCID */ #include <sys/types.h> /* The following structure can be placed in /usr/include/sys/timeb.h. That way that part of maketime.c doesn't have to be changed. The rest of this is just added to the end of maketime.c */ struct timeb { time_t time; unsigned short millitm; short timezone; short dstflag; }; extern long timezone; extern int daylight; ftime(tp) struct timeb *tp; { long t; time(&t); tp->time = t; tp->millitm = 0; tp->timezone = timezone/60; tp->dstflag = daylight; } -- harvard\ att!nicmad\ Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown rutgers/ decvax!nicmad/ ARPA/INTERNET: @spool.cs.wisc.edu,@astroatc:brown@vidiot
brown@vidiot.UUCP (Vidiot) (10/08/89)
In article <78@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes:
<
<I received the answer that I needed in order to get RCS working on this SysV
<PC. I have also found out that there is a version 4 of RCS that works under
<both BSD and SysV. Unfortunately, I don't know where to fetch it.
Never mind. I found a source.
--
harvard\ att!nicmad\
Vidiot ucbvax!uwvax..........!astroatc!vidiot!brown
rutgers/ decvax!nicmad/
ARPA/INTERNET: @spool.cs.wisc.edu,@astroatc:brown@vidiotbilld@fps.com (Bill Davidson) (10/08/89)
In article <78@vidiot.UUCP> brown@vidiot.UUCP (Vidiot) writes: >I received the answer that I needed in order to get RCS working on this SysV >PC. I have also found out that there is a version 4 of RCS that works under >both BSD and SysV. Unfortunately, I don't know where to fetch it. I've seen several requests for this and I've sent mail to people but it seems to be time for a post. RCS Version 4.2 is available by anonymous ftp from arthur.cs.purdue.edu (128.10.2.1). I believe this is the main distribution point. Uunet also keeps a version but the last I checked, I think they were still at 4.0. The compressed tar file is 208301 bytes (581632 uncompressed). They no longer distribute rdiff or rdiff3 so you should keep the old ones if your system diff and diff3 aren't up to snuff (or get gnu diff). I brought 4.2 up on Microport System V/AT release 2.2 (talk about a hostile environment!). The only problem I had was with a file which wouldn't compile because Microport's compiler and assembler are broken (Have you ever gotten a syntax error from your assembler from code generated by your compiler? >^( The fix was to take the pointer to a function out of the data declaration and assign it at runtime. I can't remember the module but if you do it on a similarly broken system, you'll know when you see the error :-). I also made a hack to rcsfnms.c to simulate symbolic links by making pairfilenames() look for a file called "RCS_link" which, if it existed would contain the path of the RCS directory. It seems to work quite well. I was thinking of sending diffs to Purdue to see if they wanted to offer it as an option to poor System V victims. Would anyone else like to see this? I'd have to check with "the powers that be" to make sure I even could give it away but I think I could. In the past, I also ported 3.0 to System V and that was living hell. I had to fix the previously mentioned time function and a zillion things that expected pointers and int's to be the same size and that they were all 32 bits etc. 4.2 doesn't seem to have any such problems. The code is looks much cleaner and better structured. A number of things which used to be cheap hacks have been fixed to be done the right way. Those purdue people have done a great job fixing it up. Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS? --Bill
hastings@baobab.Berkeley.EDU (Mark Hastings) (10/10/89)
In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes: > >Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS? NOTE: I'm not speaking for anyone else at Berkeley, particularly not BSD folk. One reason to use SCCS is that it's there and it works. SCCS has been included in every version of *nix I've come across (granted limited experience with those Sys-V packages that make *everything* an optional accessory). After using SCCS for many years, our project looked at "moving up" to RCS. But we'd become so attached to the features of the sccs front end that RCS lacked (sccs info, etc..) that we decided to wait until there was a complete, upwardly-compatible RCS package. Familiarity over technological superiority. >--Bill --Mark Hastings (415) 642-4611 hastings@ernie.berkeley.edu ..!ucbvax!ernie!hastings
rob@PacBell.COM (Rob Bernardo) (10/11/89)
In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes:
+Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS?
Because make (at least the augmented version of make) understands SCCS.
--
Rob Bernardo ...![backbone]!pacbell!pbhyf!rob -or- rob@pbhyf.PacBell.COM
Product engineer, UNIX/C Reusable Code Library Editor, "Go `C' UNIX"
Office: (415) 823-2417 Pacific * Bell, San Ramon, California
Residence: (415) 827-4301 R BAR JB, Concord, Californiabilld@fps.com (Bill Davidson) (10/12/89)
In article <6218@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: >In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes: >+Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS? > >Because make (at least the augmented version of make) understands SCCS. The make on my System V machine does know about SCCS but only if the SCCS file is in the current directory. I keep mine in sub-directories so it doesn't do me much good. I really hate keeping everything in one directory. The ,v is already handled by the .SUFFIXES on any make since all you need are rules like: .c,v.c: $(CO) $(COFLAGS) $< and have ".c,v" be after ".c" in your ".SUFFIXES" line. So any make understands RCS as well as my System V make understands SCCS. True, you have to make your own ".SUFFIXES" and a few new implicit rules but it's better than naming every bleeding dependancy. I have heard some good reasons but IMHO this isn't one of them. The make I have on my Berkeley systems is also modified so that it accepts a ".PREFIXES" target, much in the same manner as ".SUFFIXES". We typically put a line like: .PREFIXES ./RCS/ in our makefiles. I haven't tried a "s." in the prefixes line yet but I suspect it would work. I don't use SCCS where I don't have to. I wish I could get this in my System V make. I believe VPATH is supposed to be the same thing but it doesn't work in the System V make that I have. In any case, since I do use subdirectories, I'm cursed with explicit dependancies. For those of you who are curious, here are the reasons that I think are valid that I've heard so far: 1. One person said that they had a vast amount of code and that conversion would be a monumental task. I'm going through this myself with several megabytes of code right now. I can see why one would be afraid to do it. sccstorcs is slow (actually it's slow because it uses get and ci to do most of the work and they are slow). Also, you have to change all your makefiles. This is a definite deterent to conversion :-). 2. Another person had a lot of code which had many branches and he used a lot of old revisions. When you do a lot of this kind of thing SCCS is faster than RCS. RCS is only faster when you are grabbing the latest revision. I grab the latest revision about 95% of the time so this means nothing for me but I can see how it could matter to others. 3. SCCS allows you to lock more than one revision of a file at a time. This is from the same person mentioned in reason #2. If you deal with a lot of branches, I can see this. I don't so I don't care. --Bill Davidson
art@felix.UUCP (Art Dederick) (10/13/89)
In article <18167@pasteur.Berkeley.EDU> hastings@baobab.Berkeley.EDU (Mark Hastings) writes: >But we'd become so attached to the features of the sccs front end that RCS >lacked (sccs info, etc..) that we decided to wait until there was a complete, I would like to see a list of features you claim is missing from RCS. I've been using RCS for years and cannot imagine what could be missing. Art Dederick felix!art (714)966-3618
prs@tcsc3b2.tcsc.com (Paul Stath) (10/13/89)
Of course with a little ingenuity, make will also handle RCS. Just use
$ make -fp < /dev/null 2>/dev/null >rules.c
to get a list of the default inference rules. Then hack out the ones that don't
have a '~' in them. Replace the ~ with a ',v' place them in a file called
rcs.rules or something and use the make include directive like this:
include "/usr/lib/rcs.rules"
This will effectively give you additional rules to use RCS. The only drawback
is that make only looks for {makefile, Makefile, s.makefile or s.Makefile}
(Guess not everything can be perfect.)
This means that you have to extract a copy of the makefile before you can
run make. Which is not a problem for me because I usually need to retreive
old as well as current versions. (Old retrieves sure are _fast_ in RCS!)
--
===============================================================================
Paul R. Stath The Computer Solution Co., Inc. Voice: 804-794-3491
------------------------------------------------+------------------------------
INTERNET: prs@tcsc3b2.tcsc.com | "There was no diety involved,mhyman@hsfmsh.UUCP (Marco S. Hyman) (10/13/89)
In article <6218@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes: +Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS? Because make (at least the augmented version of make) understands SCCS. Try this in your next Makefile: SOURCES= <list of source files> HEADERS= <list of header files> OBJECTS= $(SOURCES:.c=.o) RCSDIR= . RCSFILES= $(SOURCES) $(HEADERS) ... CO= co -q COFLAGS= ... $(RCSFILES): $(RCSDIR)/RCS/$$@,v $(CO) $(COFLAGS) $(RCSDIR)/RCS/$@,v This works with both Sun makes (the new and old versions) as well as System V make (tested on an HP [SysV.2] and on SysV/386 3.2). Or use GNU make. The advantage (and disadvantage) of the above is that it will ALWAYS co the version from the RCS directory if it is newer than the one in the current directory. --marc -- // Marco S. Hyman home: {ames,sun}!pacbell!dumbcat!marc // UUCP: ...!hoptoad!hsfmsh!mhyman I-net: hsfmsh!mhyman@sfsun.west.sun.com
chip@ateng.com (Chip Salzenberg) (10/13/89)
According to rob@PacBell.COM (Rob Bernardo): >In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes: >+Does anyone know why Berkeley (or anyone in their right mind) >+still uses SCCS? >Because make (at least the augmented version of make) understands SCCS. And GNU Make understands both SCCS and RCS. (Oxymoron of the day: "AT&T Augmented Make." Down with NIH!) -- You may redistribute this article only to those who may freely do likewise. Chip Salzenberg at A T Engineering; <chip@ateng.com> or <uunet!ateng!chip> "'Why do we post to Usenet?' Naturally, the answer is, 'To get a response.'" -- Brad "Flame Me" Templeton
allbery@NCoast.ORG (Brandon S. Allbery) (10/15/89)
As quoted from <1367@celit.fps.com> by billd@fps.com (Bill Davidson): +--------------- | They no longer distribute rdiff or rdiff3 so you should keep the old ones if | your system diff and diff3 aren't up to snuff (or get gnu diff). +--------------- I wondered how they got around AT&T.... +--------------- | I brought 4.2 up on Microport System V/AT release 2.2 (talk about a hostile > . . . | In the past, I also ported 3.0 to System V and that was living hell. I had to | fix the previously mentioned time function and a zillion things that expected | pointers and ints to be the same size and that they were all 32 bits etc. 4.2 | doesn't seem to have any such problems. The code is looks much cleaner and +--------------- Puh-LEEZE! Don't ascribe to System V the limitations of the 80286 processor. On a 680x0 or an 80386, System V has sizeof (int) == sizeof (char *), so Berzerk stupidity can be handled as is. +--------------- | Does anyone know why Berkeley (or anyone in their right mind) still uses SCCS? +--------------- Because more people have access to it, presumably. (Me, I use RCS.) ++Brandon -- Brandon S. Allbery, moderator of comp.sources.misc allbery@NCoast.ORG uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu bsa@telotech.uucp 161-7070 (MCI), ALLBERY (Delphi), B.ALLBERY (GEnie), comp-sources-misc@backbone [comp.sources.misc-related mail should go ONLY to comp-sources-misc@<backbone>] *Third party vote-collection service: send mail to allbery@uunet.uu.net (ONLY)*
simpson@trwarcadia.uucp (Scott Simpson) (10/16/89)
>In article <1367@celit.fps.com> billd@fps.com (Bill Davidson) writes: >+Does anyone know why Berkeley (or anyone in their right mind) >+still uses SCCS? I like SCCS because it has a "fix" command. I don't recall there being one in RCS. But RCS has a $Log$ keyword which I like. (The interaction of these two features may be related. How do you delete a $Log$ entry when you need to do a "fix"?) Also, I understand that RCS stores the last version of the file and deltas to previous versions, while SCCS stores the first version and deltas from then onward. Since you usually check out the latest version of a file, RCS is probably a little faster. Scott Simpson TRW Space and Defense Sector usc!trwarcadia!simpson (UUCP) trwarcadia!simpson@usc.edu (Internet)
rsalz@bbn.com (Rich Salz) (10/16/89)
> I understand that RCS >stores the last version of the file and deltas to previous versions, This is correct. It means that to get old versions lots of work has to be done (and you can just about forget about branches :-). >while SCCS stores the first version and deltas from then onward. This is WRONG. It's an urban legend. SCCS stores diffs, and flags indicating whether those diffs are present in a particular edit or not. This means that to get ANY SCCS version the amount of time needed will be the same. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
bronson@mfci.UUCP (Tan Bronson) (10/16/89)
>I would like to see a list of features you claim is missing from RCS. >I've been using RCS for years and cannot imagine what could be missing. > >Art Dederick >felix!art >(714)966-3618 I've spent a fair number of years hacking RCS to write higher level tools, and while I tend to agree that RCS is very complete. I've added: rlog -H (dump revision number of the header) rlog -S<symbol> (dump revision number of symbol) rcs -B<reason> break a lock and send mail One tool I'd love to see is a graphical display of the branch structure of a RCS file. I'm starting to use branches now much more and I'm worried that someday I'll hit a limit... I'd also like to see a clean subroutine library to access RCS files. (I've got code which reads symbols + locks from an RCS file) Tan Bronson Multiflow Computer Inc UUCP(work): {yale,uunet}!mfci!bronson 30 Business Park UUCP(home): {yale,mfci}!bronson!tan Branford, Ct 06405 Phone(work):(203)-488-6090
peter@ficc.uu.net (Peter da Silva) (10/17/89)
The question: why does anyone use SCCS? The answer: 14 character file names. A related problem: I'm getting tired of having the same problem with pack/compress/compact/..., and I'm considering a better solution than either a prefix or suffix: % ls foo.c % pack foo.c foo.c: 32% compression. % ls foo.c/ % ls foo.c packed % ls -a foo.c ./ ../ packed % unpack foo.c foo.c: Unpacked. % ls foo.c Comments? (yes, I know Make won't like it, and so on... and no flames about 14 character file names, either) -- Peter da Silva, *NIX support guy @ Ferranti International Controls Corporation. Biz: peter@ficc.uu.net, +1 713 274 5180. Fun: peter@sugar.hackercorp.com. `-_-' "That particular mistake will not be repeated. There are plenty of 'U` mistakes left that have not yet been used." -- Andy Tanenbaum (ast@cs.vu.nl)
guy@auspex.auspex.com (Guy Harris) (10/17/89)
>I understand that RCS stores the last version of the file and deltas to >previous versions, True. >while SCCS stores the first version and deltas from then onward. Possibly true of ancient versions of SCCS, but not true of the versions of SCCS that come with any version of UNIX people are likely to run (i.e., not true of the S3 or S5 versions of SCCS - the SunOS version is basically the S3 version). Those versions use a scheme that requires the same amount of time to retrieve any version.