paulina (02/26/83)
This is the long awaited summary of my request for information comparing SCCS and RCS. I have sent a copy of the unedited responses to the people who requested them. If you would like a copy and did not get one, let me know. ...megatest!ubvax!paulina Paulina Knibbe I received seven responses from people who had experience with either SCCS, RCS or both. People who had used both all preferred RCS. SCCS only --------- recommend 3 not recommend 1 RCS only --------- 0 both --------- prefer SCCS 0 prefer RCS 3 The following list is some of the specific comments about the two systems. ******************** I have used SCCS and found it quite handy, but the user interface was a little arcane in places. I have heard that RCS is supposed to be a public domain version of SCCS -- different user interface but basically the same power. ********************* We anticipate distributing RCS in 4.2BSD. We cannot distribute SCCS now or in the future because of licensing constraints. The main points to consider when comparing SCCS to RCS are: 1. Speed of version retrieval SCCS uses forward deltas whereas RCS uses reverse deltas. This means that if a file has undergone a number of revisions, then RCS will be able to generate the most recent versions quicker than SCCS. 2. System configuration RCS has a symbolic name facility which enables the programmer to attach a unique label to all of the files making up a particular configuration, thus providing an easy way to regenerate systems. 3. Availability SCCS is only available if you have a PWB UNIX or UNIX System III license. RCS is freely available. ******************************************************************** RCS is from Purdue university, purdue!cak is the distribution contact. It will, I understand, also be available with the 4.2BSD distribution from Berkeley. We've used SCCS for the last major project here at Zehntel. It worked (along with a more useful front end). It isn't ideal in many ways. get and delta aren't terribly reasonable to use. You must know the SCCS name of the file (and I refuse to keep track of anything the machine should be able to). We typically had SCCS subdirectories in each of the development areas. You had to say get -e SCCS/s.longname.c to get what you wanted. Also, there is no reasonable way to coerce make into understanding about SCCS files (since they are prefix oriented). RCS was designed after looking carefully at SCCS. It is suffix oriented, assumes that there is an RCS subdirectory (or not, it looks first). RCS files can be integrated into make elegantly. As an aside, there is a USENIX distribution with a make from Lincoln Labs that makes it even easier (I'm running it. Holler if you want more info). Information entered at delta time in SCCS is simply stuffed in the SCCS file and is not readily availabe to the developers and maintainers. With RCS, this edit information can be inserted directly into the source as comments. There is a feature to specify a prefix to each of these lines to ensure that they are comments. It is easier to create branches with RCS (if you wish). Another problem with SCCS was to update the revision numbers from whatever they were to 2.1 for all routines. With SCCS, you get them at revision 2.1 (regardless of what they are). With RCS, simply co (check out) at the current revision and ci (check in) at 2.1. This is more reasonable. RCS allows symbolic names to all revisions, allows each revision to be in some state (like released, stable, testing, experimental). Each user can choose his own set of states. I recommend that the project supervisors make that choice. You can then say, check out the last stable revision. Great when some one goes into a program, hacks around and leaves it broken. *************************************************************** SCCS loses, hands down. I haven't used RCS yet, but it can't be worse than SCCS. Everything in SCCS is done wrong: archives are named s.file rather than file+ (or some other prefix), recording a change in the archive removes the file itself, all SCCS programs have a zillion options for useless and obscure things, and more. Avoid SCCS if possible. **************************************************************** I can't really offer you any info. I've used SCCS and found it to be very good, but then all I had to compare it to was nothing! I also have RCS. I've only gotten as far as building the commands and reading the documentation. At first glance it seems slightly easier to use, has some better defaults, and uses a different sort of branching than SCCS. I've heard that RCS is faster and more efficient than SCCS. Various people on the net have been singing its praises in comparison with SCCS. Also, RCS works better with "make." You can get a copy of RCS for free from Purdue. The guy handling the distribution is Chris Kent, purdue!cak.
guy (02/27/83)
For what it's worth, the System III and later "make"s DO interface to SCCS. We have not used either extensively (in fact, I only brought System III "make" up on our 4.1BSD VAX last night), but the few things I tried with a directory with NO .c files (only s..c files) and NO Makefile (only s.Makefile) seemed to work (i.e., it properly did "get"s on s.Makefile and s.*.c, and cleaned up the Makefile and *.c when it was done; it also didn't do a get or remove the .c if it already existed). Thanx for the info anyway; we may end up using one or the other and I think we either have RCS or can get it, so we'll look over the replies, ask around, and possibly play with both and choose. I hadn't heard much about RCS until this item, and now (if it offers all the functionality of SCCS and an interface with "make" of equal power to SCCS's, and does so better than SCCS) we may use it instead. Guy Harris RLG Corporation ...!decvax!mcnc!rlgvax!guy ...!seismo!rlgvax!guy