charles@dragon.UUCP (Charles Wolff) (12/09/87)
I'm involved in a project which is going to have a fairly large source
code base, and we're currently in the process of deciding whether to
use sccs or rcs for source code control. Would like to hear from anyone
who:
1) is familiar with both SCCS and RCS. _AND_
2) can give me examples of things that they are doing with one
that couldn't be done with the other.
Thanks in advance...
--
I Pit My Wits Against Those Silicon Chips.. | Charles Wolff
But I've Still Got the Animal Inside of Me! | Motorola Microsystems
-Thompson Twins | Tempe, AZ (602) 438-3432poetry@gpu.utcs.toronto.edu (David Goodman) (12/10/87)
In article <743@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, x3432) writes: >I'm involved in a project which is going to have a fairly large source >code base, and we're currently in the process of deciding whether to >use sccs or rcs for source code control. Would like to hear from anyone >who: > > 1) is familiar with both SCCS and RCS. _AND_ > > 2) can give me examples of things that they are doing with one > that couldn't be done with the other. > >Thanks in advance... I would love to hear about this, too. Thanks.
robf2@pyuxf.UUCP (robert fair) (12/16/87)
In article <1987Dec9.235431.11368@gpu.utcs.toronto.edu>, poetry@utgpu.UUCP writes: > > In article <743@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, x3432) writes: > >I'm involved in a project which is going to have a fairly large source > >code base, and we're currently in the process of deciding whether to > >use sccs or rcs for source code control. Would like to hear from anyone > >who: > > > > 1) is familiar with both SCCS and RCS. _AND_ > > > > 2) can give me examples of things that they are doing with one > > that couldn't be done with the other. > > > >Thanks in advance... > > > I would love to hear about this, too. Thanks. Me, Three. Thanks Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler
skh@hpclskh.HP.COM (01/13/88)
/ hpclskh:comp.unix.questions / robf2@pyuxf.UUCP (robert fair) / 6:43 am Dec 16, 1987 / In article <1987Dec9.235431.11368@gpu.utcs.toronto.edu>, poetry@utgpu.UUCP writes: > > In article <743@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, x3432) writes: > >I'm involved in a project which is going to have a fairly large source > >code base, and we're currently in the process of deciding whether to > >use sccs or rcs for source code control. Would like to hear from anyone > >who: > > > > 1) is familiar with both SCCS and RCS. _AND_ > > > > 2) can give me examples of things that they are doing with one > > that couldn't be done with the other. > > > >Thanks in advance... > > > I would love to hear about this, too. Thanks. Me, Three. Thanks Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler Poster Filler ---------- My only comment to you would be this: the versions of SCCS I have seen store the original source file and differences from that file. RCS versions tend to store the latest source file and differences from previous versions. This means that SCCS takes longer to give the the latest version of a file; RCS takes longer to get back to a previous version. When I am in program development, I find it much easier to have fast access to the most recent version of a file. I find that I need older versions much less often, and I am willing to wait. Naturally, if you think you will be working on older versions more often (such as after a product release), SCCS may be a better choice. Instant disclaimer: Not all versions of SCCS and RCS have this property. Disclaimer #2: No other comments about ease of use. skh
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/14/88)
In article <720003@hpclskh.HP.COM> skh@hpclskh.HP.COM writes: >My only comment to you would be this: the versions of SCCS I have seen >store the original source file and differences from that file. RCS versions >tend to store the latest source file and differences from previous versions. SCCS archives are not the way you describe. >This means that SCCS takes longer to give the the latest version of a file; >RCS takes longer to get back to a previous version. Since SCCS "get" does not in fact have to apply each delta separately, but rather applies them all in one sequential scan, it is fairly fast. It takes SCCS "get" about a second on a VAX-11/780 to retrieve the latest version of a 1000-line program that has undergone from 4 to 10 revisions.
ntm1458@dsacg3.UUCP (John Darby) (01/15/88)
in article <720003@hpclskh.HP.COM>, skh@hpclskh.HP.COM says: > >> >who: >> > >> > 1) is familiar with both SCCS and RCS. _AND_ >> > >> > 2) can give me examples of things that they are doing with one >> > that couldn't be done with the other. We have both SCCS and RCS here at DLA and we are trying to decide which to use. 1. SCCS is supported by the vendor as part of the contract. 2. RCS is public domain. Support from netland seems very reliable. I think RCS is easier to use. For the people writing applications and supporting them RCS is similar to the software we use to support IBM mainframe applications. 3. Basically right now we use both and leave it up to the individual or group to decide. -- John T. Darby, (DLA Systems Automation Center, DSAC-TMM, P.O. Box 1605 Columbus, OH, ntm1458, 614 238-9174) UUCP: {...cbosgd!osu-cis}!dsacg1!jdarby Any opinions expressed are my own, not those of my employer.
wheels@mks.UUCP (Gerry Wheeler) (01/19/88)
In article <580@dsacg3.UUCP>, ntm1458@dsacg3.UUCP (John Darby) writes: > We have both SCCS and RCS here at DLA and we are trying to decide > which to use. > 1. SCCS is supported by the vendor as part of the contract. > 2. RCS is public domain. Support from netland seems very reliable. > I think RCS is easier to use. Is it public domain? I don't think so, but I don't have any hard evidence one way or the other. Another point in RCS's favour (for those who have to use more than one operating system) is that it is now available for MS-DOS too. The RCS files generated by the two versions are identical, so they can be ported directly from one system to the other. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
cramer@optilink.UUCP (Clayton Cramer) (01/22/88)
> In article <580@dsacg3.UUCP>, ntm1458@dsacg3.UUCP (John Darby) writes: > > We have both SCCS and RCS here at DLA and we are trying to decide > > which to use. > > 1. SCCS is supported by the vendor as part of the contract. > > 2. RCS is public domain. Support from netland seems very reliable. > > I think RCS is easier to use. > > Is it public domain? I don't think so, but I don't have any hard > evidence one way or the other. No, it's not public domain -- but you can ask Mr. Tichy for permission to get it from someone who does it have it, and it's only a minor nuisance to do so, and there's no charge. > Another point in RCS's favour (for those who have to use more than one > operating system) is that it is now available for MS-DOS too. The RCS > files generated by the two versions are identical, so they can be ported > directly from one system to the other. > > Gerry Wheeler Phone: (519)884-2251 > Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels Interesting! Does MKS offer RCS as a product for MS-DOS? If so, how much? This might be of general interest to PC users. Clayton E. Cramer
ericb@athertn.Atherton.COM (Eric Black) (01/23/88)
In article <377@mks.UUCP> wheels@mks.UUCP (Gerry Wheeler) writes: >In article <580@dsacg3.UUCP>, ntm1458@dsacg3.UUCP (John Darby) writes: >> [...] >> 2. RCS is public domain. > >Is it public domain? I don't think so, but I don't have any hard >evidence one way or the other. No, it is not public domain. The author retains the copyright to the code, but in the past, at least, has been quite liberal in giving permission for using and/or distributing the code for no direct profit (in other words, you can get permission to include it in a commercial product as long as the product costs the same with it as without it). Just ask him beforehand. I quote the copyright notice contained in the source: * Copyright (C) 1982 by Walter F. Tichy * Purdue University * Computer Science Department * West Lafayette, IN 47907 * * All rights reserved. No part of this software may be sold or distributed * in any form or by any means without the prior written permission of the * author. Of course, Tichy is now at University of Karlsruhe, West Germany, at net address <tichy%germany.csnet>. I further quote from a letter he sent me in November, 1987: If you received RCS via Berkeley Unix, then no further permission for distribution is required from my side. I've also been informed that AT&T no longer claims ownership of diff and diff3, so you need not replace these components. I interpret this to mean that if you had legitimate access to 4BSD sources, then you have legitimate access to RCS source; this is not the only way to legitimately get it. I have not personally verified that AT&T has abandoned claims to diff and diff3 source; unless this is so, then legitimate access to sources for RCS, which includes files directly derived from the diff and diff3 code for UNIX, requires the UNIX license. Even if AT&T has not given away diff, then if those files are not present in your collection of RCS sources, then you should be OK. There are many various versions of "diff" available; some hacking is required to make any suitable for use in RCS, but it is apparently not necessary. More from that same letter: However, there is a newer release of RCS, release 4. This release is a much improved version, and upward compatibel [sic] with release 3...In addition, I now have a version of MAKE that is integrated with RCS. ... I can offer release 4 of RCS together with the new MAKE at a one-time fee of $5000 for a world-wide non-exclusive license. I don't know any more (yet) about it. We are looking into version 4, and I'll post something when I do have more to say about it. -- Eric Black "Garbage in, Gospel out" UUCP: {sun!sunncal,hpda}!athertn!ericb Domainist: ericb@Atherton.COM
guy@gorodish.UUCP (01/24/88)
> There are many various versions of "diff" available; some hacking is > required to make any suitable for use in RCS, but it is apparently not > necessary. The 4.3BSD version of "diff" (which is derived from AT&T code, and thus would require an AT&T license unless they truly *have* abandoned any claim to ownership) has had all the changes made to "diff" for RCS folded into it. This version is provided with a number of UNIX systems; for instance, SunOS provides it with release 3.2 and all subsequent releases. The main such change was the addition of the "-n" flag. Check your man page; if a "-n" flag is listed and described in terms such as "produce(s) a script similar to that of '-e', but in the opposite order and with a count of changed lines on each insert or delete command", you probably have the 4.3BSD version. > I don't know any more (yet) about it. We are looking into version 4, > and I'll post something when I do have more to say about it. Version 4 incorporates: 1) the changes made by Jay Lepreau, which are in the version that came with 4.3BSD, to make "rcsdiff" support all the options that the 4.3BSD "diff" does (including options such as the new "-w" and "-i" options); 2) changes to make it pass "lint" with many fewer complaints, so it can work on e.g. systems with 16-bit "int"s and 32-bit pointers; 3) changes to make it work on S3/S5 systems (although you'll have to dig up a modified "diff" for many of those systems); 4) changes to make it work on systems that disallow dereferencing null pointers; 5) a number of bug fixes. I don't know what else it has. I don't know what the arrangements are for getting Version 4, but if you can get it, you probably should do so. Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com
wheels@mks.UUCP (Gerry Wheeler) (01/26/88)
In article <1867@optilink.UUCP>, cramer@optilink.UUCP (Clayton Cramer) writes: } > Another point in RCS's favour (for those who have to use more than one } > operating system) is that it is now available for MS-DOS too. The RCS } > files generated by the two versions are identical, so they can be ported } > directly from one system to the other. } > } > Gerry Wheeler Phone: (519)884-2251 } > Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels } } Interesting! Does MKS offer RCS as a product for MS-DOS? If so, how } much? This might be of general interest to PC users. } } Clayton E. Cramer Yes, we have just completed a port of RCS to MS-DOS. It is available for $189 (US dollars). Call or write for more details and info. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
wheels@mks.UUCP (Gerry Wheeler) (01/26/88)
In article <163@teak.athertn.Atherton.COM>, ericb@athertn.Atherton.COM (Eric Black) writes: } Of course, Tichy is now at University of Karlsruhe, West Germany, at net } address <tichy%germany.csnet>. I further quote from a letter he sent } me in November, 1987: } } However, there is a newer release of RCS, release 4. This release } is a much improved version, and upward compatibel [sic] with } release 3...In addition, I now have a version of MAKE that is } integrated with RCS. } ... } I can offer release 4 of RCS together with the new MAKE at a } one-time fee of $5000 for a world-wide non-exclusive license. } -- } Eric Black "Garbage in, Gospel out" } UUCP: {sun!sunncal,hpda}!athertn!ericb } Domainist: ericb@Atherton.COM The port that MKS did for MS-DOS is from these newer version 4 sources, which we licensed directly from Mr. Tichy. The only major changes we had to make were in the areas of file name conventions (DOS doesn't allow names like "foo.c,v") and file locking. Other than that, it is all pretty well generic C code. -- Gerry Wheeler Phone: (519)884-2251 Mortice Kern Systems Inc. UUCP: uunet!watmath!mks!wheels 35 King St. North BIX: join mks Waterloo, Ontario N2J 2W9 CompuServe: 73260,1043
woods@tslanpar.UUCP (Greg A. Woods ) (01/26/88)
I have used both SCCS, and an MS-DOS (yeah, I know...) version called VCS
(Polytron). I have had little exposure to RCS.
From my experience with SCCS, and from what I know of RCS, VCS is more of an
RCS look-alike, though the authors (marketeers) say they took the best
features of all.
The one thing that is missing from SCCS that was quite simple with VCS is
meta-version naming scheme. (Product version names, as opposed to file
revision ID's, where a version incorporates many files of different
revisions.) I would imagine that RCS has this.
One thing that is MUCH more difficult with SCCS than it was with VCS is to
hide all of the special files in another directory. What makes it hard with
SCCS is that none of the commands support an option or environment variable
to accomplish this task, and none of the make rules properly support such a
feature either. (One could write a new set of make rules, and use the little
documented "include" feature).
If I have missed something with the use of SCCS, or if another simple tool
exists to facilitate version naming, I would like to hear about it.
--
Greg Woods.
UUCP: utgpu!woods, utgpu!{ontmoh, tmsoft!tslanpar}!woods, woods@tslanpar
VOICE: (416) 242-7572 LOCATION: Toronto, Ontario, Canadarunyan@hpirs.HP.COM (Mark Runyan) (01/27/88)
>/ gwyn@brl-smoke.ARPA (Doug Gwyn ) / 3:08 am Jan 14, 1988 / >In article <720003@hpclskh.HP.COM> skh@hpclskh.HP.COM writes: >>My only comment to you would be this: the versions of SCCS I have seen >>store the original source file and differences from that file. RCS versions >>tend to store the latest source file and differences from previous versions. > >SCCS archives are not the way you describe. Perhaps what he said was a little too general, but that is a quick explanation. A better was is to say that SCCS stores the original and the interleaves the deltas when a check in is done. This means that the "get" must always scan the entire file to retrieve a document no matter how far back you go. >>This means that SCCS takes longer to give the the latest version of a file; >>RCS takes longer to get back to a previous version. > >Since SCCS "get" does not in fact have to apply each delta separately, but >rather applies them all in one sequential scan, it is fairly fast. > >It takes SCCS "get" about a second on a VAX-11/780 to retrieve the latest >version of a 1000-line program that has undergone from 4 to 10 revisions. The retrieval of a file in SCCS vs the speed of retrieval in RCS has been much debated, with different values always stated. Perhaps someone would care to derive a table of values on different machines? :-) Mark Runyan ( RCS Warrior )
mark@ria-emh2.army.mil (Mark D. McKamey IM SA) (06/06/89)
Hello,
I am currently looking into implementing a revision control program
for numerous source files here locally. I am somewhat familiar with AT&T's
SCCS program, but have heard of a program called RCS (Revision Control System)
by Purdue University. What I am looking for is a detailed comparision
between SCCS and RCS. Any information concerning such comparison would be
greatly appreciated. Thank You,
Mark D. McKamey
mark@RIA-EMH2.ARMY.MILyuf@mentor.cc.purdue.edu (Kyle Grieser) (06/08/89)
In article <19885@adm.BRL.MIL> mark@ria-emh2.army.mil (Mark D. McKamey IM SA) writes: >by Purdue University. What I am looking for is a detailed comparision >between SCCS and RCS. Any information concerning such comparison would be >greatly appreciated. Thank You, We (here at PUCC) use RCS extensively for source management. Both SCCS and RCS do approximately the same thing, but in reverse. Let me try to explain. When you make changes in these two systems, they keep diffs for all of the different revisions. The main difference is that SCCS keeps diffs that apply to the original version and RCS keeps diffs that apply to the current version. Thus, RCS is much faster when retrieving the latest revision. In order for SCCS to get the latest version, it must apply all of its diffs to the original. The opposite it true for retrieving the original version. RCS will take longer than SCCS. Hope this helps (and that it is generally correct :-), ----- Kyle Grieser, Purdue University Computing Center yuf@mentor.cc.purdue.edu, mentor.cc.purdue.edu!yuf
erik@mpx2.mpx.com (Erik Murrey) (06/08/89)
In article <19885@adm.BRL.MIL> mark@ria-emh2.army.mil (Mark D. McKamey IM SA) writes: >by Purdue University. What I am looking for is a detailed comparision >between SCCS and RCS. Any information concerning such comparison would be >greatly appreciated. Thank You, One of the things I like most about RCS is that it can collapse keywords when checking in revisions. This way, if I forget to check out a file for locking, then I edit it, I can still check it in without losing the keywords. For example, in SCCS, a "%Z%" gets expanded into "@(#)" when checked out (for compiling), but it cannot collapse that back to "%Z%" if I check that version in. In RCS, a "$Id: $" gets expanded to "$Id: whatever $", which can be collapsed back to "$Id: $" when checked in. This also makes distribution and updates much easier. This was very important in making our decision to use RCS. .... Erik -- Erik Murrey /| // /~~~~/ | / MPX Data Systems, Inc. / | / / /____/ |/ erik@mpx.com / / / / /| Data Systems, Inc. {vu-vlsi, bpa, cbmvax}!mpx1!erik / / / / |====================
syd@dsinc.DSI.COM (Syd Weinstein) (06/08/89)
In article <2934@mentor.cc.purdue.edu> yuf@mentor.cc.purdue.edu (Kyle Grieser) writes: :In article <19885@adm.BRL.MIL> mark@ria-emh2.army.mil (Mark D. McKamey IM SA) writes: :>by Purdue University. What I am looking for is a detailed comparision :>between SCCS and RCS. Any information concerning such comparison would be :>greatly appreciated. Thank You, : :We (here at PUCC) use RCS extensively for source management. Both SCCS and :RCS do approximately the same thing, but in reverse. I suggest you see my article in the most recent issue of the C Users Journal. I did a brief introduction to Source Code Librarians and in doing so contrasted SCCS and RCS showing their main differences and the many simularities. -- ===================================================================== Sydney S. Weinstein, CDP, CCP Elm Coordinator Datacomp Systems, Inc. Voice: (215) 947-9900 syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235
guy@auspex.auspex.com (Guy Harris) (06/09/89)
>When you make changes in these two systems, they keep diffs for all of the >different revisions. The main difference is that SCCS keeps diffs that apply >to the original version (Another one for the "frequently asked questions" list?) This isn't true; SCCS basically keeps all the versions in one big list, with "begin delta thus-and-such" and "end delta thus-and-such" entries. Thus, the time to retrieve a given delta is pretty much independent of the distance of the delta you're retrieving from the original version. RCS *does* apply the deltas to the latest revision, so the time pretty much increases as you move further away from that version. RCS may be a bit faster at retrieving the later version because it doesn't have to pay any attention to any deltas, while SCCS has to pay attention to the delta information on all retrievals.
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/09/89)
In article <2934@mentor.cc.purdue.edu> yuf@mentor.cc.purdue.edu (Kyle Grieser) writes: >When you make changes in these two systems, they keep diffs for all of the >different revisions. The main difference is that SCCS keeps diffs that apply >to the original version and RCS keeps diffs that apply to the current version. This appears to correctly describe how RCS operates, but it is NOT how SCCS operates. SCCS maintains a single interleaved-delta archive that can have a designated delta extracted in one sequential pass.
dhesi@bsu-cs.bsu.edu (Rahul Dhesi) (06/09/89)
In article <10006@mpx2.mpx.com> erik@mpx2.mpx.com (Erik Murrey) writes: >For example, in SCCS, a "%Z%" gets expanded into "@(#)" when checked >out (for compiling), but it cannot collapse that back to "%Z%" if I >check that version in. This is a design bug in SCCS. There is a way around it, provided you use a standard set of sccs keywords in all files. For example: static char sccsid[] = "::[ %lots% %of% %sccs% %keywords% ]::"; Then when you lose keywords in a file, filter it through my "updid" script: #! /bin/sh # usage: updid file ... # Restores lost SCCS keywords between ::[ and ]:: in source files # Copyright 1989 Rahul Dhesi, All rights reserved. Use and # distribution permitted in accordance with the GNU license TMP=T$$ WORDS='::[ %lots% %of% %sccs% %keywords% ]::' for f do sed < $f > $TMP -e "s/::\[.*\]::/$WORDS/" && mv $TMP $f done -- Rahul Dhesi <dhesi@bsu-cs.bsu.edu> UUCP: ...!{iuvax,pur-ee}!bsu-cs!dhesi Career change search is on -- ask me for my resume
dmg@ist.CO.UK (Dave McGlade) (06/13/89)
Both RCS and SCCS have two major shortcomings, in my humble opinion (what? !!) Firstly, both require write access to the file containing old versions, (perhaps under some other user id). This means that, potentially, I can corrupt old versions. From a project point of view, this is *BAD* news. Once filed away as 'write only' an old version should not be corruptable without forcing your resident guru to get out his code to access the disk as a raw device :-> [In fact I used to accidentally corrupt s. files all the time when I tried to save documents produced by CASE tools and have had to put some stuff on the front of SCCS to stop me checking in things that might corrupt the "s." files. ] The second problem is like the first: the failure modes of SCCS/RCS should ensure nothing wrecks my carefully built up history. I had a good case of this recently when the disk filled up, screwed up the s. file and then carried on to delete my original. Dave McGlade IST
leo@philmds.UUCP (Leo de Wit) (06/15/89)
In article <1874@istop.ist.CO.UK> dmg@ist.CO.UK (Dave McGlade) writes: |Both RCS and SCCS have two major shortcomings, in my humble opinion (what? !!) |Firstly, both require write access to the file containing old versions, |(perhaps under some other user id). No, they need write access (by the effective user) to the directory containing the version file. The version file only has (some of) the read mode bits on. |This means that, potentially, I can corrupt old versions. |From a project point of view, this is *BAD* news. Just install the sccs frontend as setuid sccs (this is the default e.g. on Ultrix). Your system manager can chown sccs an SCCS directory for you (question: shouldn't this be an sccs command instead?); now you can get to the files only through the sccs frontend. You can go even further and create an access list for each RCS/SCCS file. | Once |filed away as 'write only' an old version should not be corruptable without |forcing your resident guru to get out his code to access the disk as a |raw device :-> If you file away old versions as 'write only', you shouldn't worry about them getting corrupted: you can't read them anyway 8-). Leo.
runyan@hpirs.HP.COM (Mark Runyan) (06/16/89)
>/ mark@ria-emh2.army.mil (Mark D. McKamey IM SA) / 7:36 am Jun 6, 1989 / > I am currently looking into implementing a revision control program >for numerous source files here locally. I am somewhat familiar with AT&T's >SCCS program, but have heard of a program called RCS (Revision Control System) >by Purdue University. ... RCS and SCCS are similiar. A quick comparason... SCCS RCS Meaning get s.file.c co file.c check out file get -e s.file.c co -l file.c check out for modification delta s.file.c ci file.c check in changes prs s.file.c rlog file.c display history admin -n -ifile.c s.file.c ci file.c put file under control admin -auser1,user2 s.file.c rcs -auser1,user2 file.c create a restricted access list SCCS advanatages over RCS - checks to determine if the contents of the s. file has been corrupted and reports an error. - can easily inform the user which revision added or deleted a given line. - faster check out times if you are dealing with revisions other than the "top of the trunk" RCS advantages - Has the ability to create a "relation" between families of files with the symbolic names. - simplier interface for doing common work - faster check in and check out times if you are dealing with revisions on the "top of the trunk" In most all other ways, RCS and SCCS have the same capabilities. RCS keeps all the locking information in the ",v" file while SCCS uses a "p." file to record locks, but the same types of locks are done. Both RCS and SCCS can deal with branches and have keywords that can be embedded in a file to be automatically expanded at check out time to explain which revision is being worked with (however, in SCCS the "get -e" does not expand the keywords when the file is checked out for modification). To ask which is better is like asking which editor is better: vi or emacs? The real answer is, you have to decide for yourself. Oh, and to indicate my bias so you know where I might have fudged :-) I'm an RCS (and emacs) user myself. Mark Runyan
jeffrey@algor2.UUCP (Jeffrey Kegler) (06/24/89)
In article <494@silence.princeton.nj.us> jay@silence.princeton.nj.us (Jay Plett) writes: > >Several people have discussed the relative merits of RCS and SCCS. >Did I just miss it, or has nobody mentioned the greatest advantage >that RCS has over SCCS? RCS is freely available as source code. > It is certainly an important point, though not an overwhelming advantage for all users. SCCS is more common, so if the stuff is to be ported and the people on the target are to be able to take advantage of the history, SCCS is better. RCS could be ported of course, but to ask that under some circumstances is not reasonable (or even where reasonable, not possible :- )) The fact that SCCS is AT&T supported makes it a better choice for some clients. Particularly, every programmer should know the basics of SCCS, even if they do not use it day to day. This is for the same reason that they should know ed, even though they always use vi or emacs, and that they should know sh, even though they use ksh or csh. IMHO, RCS is technically smoother, and the advantage of having source is overwhelming where I personally am concerned and porting to unknown environments is not a worry. I wind up using SCCS more, though. -- Jeffrey Kegler, President, Algorists, jeffrey@algor2.UU.NET or uunet!algor2!jeffrey 1762 Wainwright DR, Reston VA 22090
gst@wjh12.harvard.edu (Gary S. Trujillo) (06/25/89)
>/ mark@ria-emh2.army.mil (Mark D. McKamey IM SA) / 7:36 am Jun 6, 1989 / > I am currently looking into implementing a revision control program >for numerous source files here locally. I am somewhat familiar with AT&T's >SCCS program, but have heard of a program called RCS (Revision Control System) >by Purdue University. ... [discussion begun in comp.unix.questions - being cross-posted to comp.unix.wizards for purposes of informed discussion] I just joined this discussion, so I don't know if it's already been mentioned, but I wanted to point out that Eric Allman has written an article comparing the two systems in the March '89 issue (vol. 7, no. 3) of _UNIX_Review_ magazine in the "C Advisor" column (p. 72 ff). In the concluding section of the article [quoted from without permission], Eric says: One more important question must be asked: Which one should you use? As always, the answer is: it depends. SCCS is older and generally more mature. In my opinion, many of the funda- mental design elements of SCCS are superior to those of RCS. For example, I have seen RCS trash master files when the disk ran out of space at inopportune times, and RCS is much more cavalier about writing the master file than is SCCS. Specifically, SCCS does not rewrite the master file when you check out a file, changing it only when you check a new version in. All the same, the user interface of RCS is on the whole much nicer. RCS allows for the naming of versions, whcih is very useful when you have several files in one directory that make up a single system. RCS also assigns a *state* to each version, such as "Experimental" or "Release". This simplifies release management somewhat. It has been my experience, however, that in very large systems (several hundred files in several directories) more sophisticated version and release management is necessary. In such cases, the additional maturity of SCCS wins the day. My final conclusion is that, for medium-sized systems, RCS is still the easiest way to go. For large systems, where release mechanisms will likely have to be built anyway, SCCS is probably better. For small systems, it is really a toss-up. Of course, if you don't have SCCS--which, like everythying else from AT&T, is licensed and fairly expensive--the decision is an easy one. [The rest of Eric's article is really a brief tutorial on the use of each, and doesn't have much to say about which might be better for a specific purpose.] (Eric Allman is a senior programmer at the International Computer Science Institute, a research organization in Berkeley, California, where he is learning about neural networks and new technologies. He previously worked at Britton Lee Inc. and on the INGRES project at the University of California at Berkeley. He is the author of sendmail and of the -me macros, among other contributions to BCS UNIX.) _UNIX_Review_ (with which I have no connection, except as a satisfied reader) is published monthly by Miller Freeman Publications Co. [ISSN-0742-3136] Their snailing address is: UNIX Review 500 Howard Street San Francisco, CA 94105 Email may be sent to: {uunet,mtxinu,basis,attmail}!beast!editor Another good source on the subject is the article by Walter F. Tichy, the author of RCS, published in the Proceedings of the IEEE 6th International Conference on Software Engineering (Tokyo, 1982). The article seems to make a good case for the superior efficiency and performance of RCS, which seems due largely to the fact that most checkouts are of most- recent versions, which RCS can do quickly since it uses the scheme of storing the most recent version of files (incorporating embedded control information), and applies reverse deltas if older versions are requested. [0270-5257/82/0000/0058$00.75 (c) 1982 IEEE] I post this information hoping to promote some further discussion on the subject. I plan to undertake the use of one of the two systems on a major project within the next month, and would like to hear stories and opinions by users of one or both. -- Gary Trujillo (harvard!wjh12!gst)
gwyn@smoke.BRL.MIL (Doug Gwyn) (06/25/89)
In article <356@wjh12.harvard.edu> gst@wjh12.UUCP (Gary S. Trujillo) writes: >The article seems to make a good case for the superior efficiency and >performance of RCS, which seems due largely to the fact that most checkouts >are of most-recent versions, which RCS can do quickly since it uses the >scheme of storing the most recent version of files (incorporating embedded >control information), and applies reverse deltas if older versions are >requested. Some time ago, I measured the relative speeds for checking out versions of text files maintained by both SCCS and RCS. Checking out the most recent version was so fast for both systems that arguments based on relative "efficiency" are suspect. For checking out an arbitrary version, SCCS was considerably faster that RCS, taking approximately the same time as for the most recent version. Contrary to claims one often hears repeated, SCCS does not maintain a base document plus separate "forward deltas" which must be applied one after the other to arrive at a version; it keeps the delta information mixed into the document so that a one-pass extraction can be done. There are probably more UNIX systems licensed for SCCS, which has been a standard part of AT&T UNIX releases since System III (inclusive), than come with RCS already installed. Obtaining, installing, and maintaining RCS is probably not a big deal in a research environment, but it might be a factor for commercial use. Certainly both revision control systems have their problems, but they beat doing without.
jay@silence.princeton.nj.us (Jay Plett) (07/22/89)
Several people have discussed the relative merits of RCS and SCCS. Did I just miss it, or has nobody mentioned the greatest advantage that RCS has over SCCS? RCS is freely available as source code. jay@princeton.edu
louk@tslwat.UUCP (Lou Kates) (10/25/90)
Could anyone who is familiar with both sccs and rcs comment on the relative advantages and disadvantages of each, especially for an environment in which a group of people will be working on the same piece of software? Does either of these have facilities for handling the case where the people are at multiple sites connected only via uucp dialup links? If neither does, are there alternatives (especially free ones)? Does rcs have the capability for tracking Modification Requests (MRs) like sccs does? Lou Kates, Teleride Sage Ltd., tslwat!louk@watmath.waterloo.edu 416-596-1940 ext. 210