woods@gpu.utcs.toronto.edu (Greg Woods) (08/16/88)
>I wrote: >> I find SCCS is by far the more powerful and capable of the two. In article <3435@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > Spoken like somebody who has used both of them and is thus in a >position to "compare and contrast". Please do -- unsupported "X is better >than Y" statements leave the reader cold. [ I received a similar note in the mail, but I not only had to re-send my reply several times because of bounces, I've also lost my local copy of it! So here goes with a re-write. Hope nobody dozes off. ] First, I've seen a few discussions about this very topic, and since I don't >>always<< like to repeat things already said, I didn't embark on a full explanation :-). [ Besides, I rather enjoy being terse the first time around. Then I can say I-told-you-so, or, you-asked-for-it! ] Confession: I've only used RCS in a trivial manner, and never for an entire large project. I have, however, used Polytron VCS for a very large project. For those who don't know, Polytron VCS is an RCS clone for MS-DOS, VMS, and (RSN) Unix; with a few additions and deletions in the features category. It is not file-format compatible with RCS, nor SCCS, nor with and other system I know of (maybe it itsn't an RCS clone, though it sure seems like one when you use it!). For the most part, my discussion of RCS applies to VCS. VCS has a slightly better directory management scheme, and it is fully integrated into Polytron Make as well (at least after I got through with "builtins.mak" it was!). Since I last used it, Polytron have added a neat-o forms/menu driven full-screen front-end to VCS. It seems this feature is an un-shakeable requirement in the DOS world. Support: I have used SCCS in several large projects, and I use it to track all local modifications to Usenet and other outside sources. Disclaimer: I use Eric Allman's sccs front-end driver. With it, and a couple of aliases, I can make SCCS appear very much like RCS, and make it just as easy to use. My reason for doing so, besides the inherit ease of use, is to allow the stuffing of all those hideous s-file's and p-file's into a subdirectory. At one time, RCS's automatic capability to do so with it's database files was a major attraction. SCCS disadvantages: For me, SCCS is only missing one necessary feature, and one handy feature: 1. No "automatic" capability to mark a set of files with a "version" (as opposed to revision) tag. 2. No "state" tag. [ HELP! Anyone know how to USE vc? I think it can be used to do this. ] Both of these are very similar, and one might wonder why RCS provides both when simple naming conventions with (1) can probably satisfy the requirements that may have driven the creation of (2). At least we did quite well without (2) using VCS. I'm not sure if VCS has (2) or not. We didn't use it. Of small note, and of complete indifference to me, is SCCS's in-ability to include the comments, MR numbers, and other interesting information (that the prs command is able to extract and display from the s-file) into the g-file (actual source). It is slightly annoying that the get keyword list is slightly different, and much restricted, in respect to that of prs. Although I haven't examined all of the possible collisions, I believe this situation could be rectified quite easily. Also of complete indifference to me is the relatively steep learning curve for SCCS (I know it all :-). To offset this, there is a simple online help facility (more of a reminder service). It is aptly named 'help' :-). (In case you didn't guess, this is also a disadvantage.) This isn't really a disadvantage any more, but old versions of SCCS silently truncated filenames, if the s. prefix made them too long. This is now an error, and if you want to store this file with SCCS, you'll have to come up with a shorter name. I've no experience with RCS's handling of names-too-long (BSD allows wonderfully long names). If it does nothing, it could be in more danger, cause it put's it "id" on the tail of a filename. SCCS Advantages: Despite claims to the contrary, I feel the SCCS id keyword syntax is quite easy to learn, and very useful. I can include as much, or as little, information about the file, and current revision, as I care to, and in almost any context. Keyword expansion can be turned off, and often "escaped" to prevent expansion. SCCS seems to allow much more flexible merging of revisions. A list, and/or range(s) of revisions can be specified to be included, or excluded from a get. Rcsmerge seems to allow only two revisions to be merged. I suppose a script of Rcsmerge's could eventually accomplish the same result, with a lot more care. Both systems mark conflicting changes. SCCS is, in fact, more flexible than RCS in dealing with sub- directories. Not only can directory names be specified on the command line of any SCCS member program, so can it read a list of files (and possibly directories, I haven't checked) from stdin! Along with a suitable driver, such as the aformentioned sccs, file manipulation is a piece of cake! RCS Disadvantages: (Other than those implicitly mentioned above.) RCS keywords are very limited, and cannot be disabled. RCS Advantages: (Other than those implicitly mentioned above.) I believe, though I haven't actually verified this, that RCS will allow infinite branching; ie: you could have a revision 1.1.1.1.1.1.1.1.1.1.1. SCCS is much more limited in its world view, and only allows release, level, branch, and sequence id's: ie: only 1.1.1.1. RCS seems to allow zero (0) as a revision component. I haven't had any success getting SCCS to use such. RCS will automatically create the database when using ci, or it can be done explicitly with rcs, (ala admin in SCCS). Who cares? So can a fastidious driver program using SCCS (unlike sccs), as did the shell scripts I wrote and used before using sccs. According to something I read in the RCS manuals, RCS "simplifies software distribution ... [such that] ... customer changes can be merged into distributed versions locally, or by the development group". This probably isn't as easy as it implies. It certianly isn't that easy with SCCS. At least not without L. Wall's Patch utility. I've never tried such a feat without it. The sccs driver leaves something to be desired when creating context diffs too. I can't find anything in the RCS manuals to replace patch, so you probably need it when using RCS too. > Me? I'm a true-blue RCS fan (RCS vs. SCCS has to rank up there >with Sys5 vs. BSD and emacs vs. vi for silly religious wars). I find RCS >basicly does everything I need to do. On the other hand, if somebody could >show me why SCCS is better in concrete terms, I might consider changing my >mind. I guess that means I not a True Believer. You're right. For the most part, in general use, RCS will do everything you need it to, and more. However, SCCS is a standard tool, and, in my view, provides more functionality and power than RCS. (I know, W. Tichy tried to make RCS standard by putting it on the BSD tape. Too bad he still charges a license fee, and too bad he didn't try/succeed in selling it to AT&T. If it was PD, I'm sure it would win hands down. AT&T might even have picked it up too.) [ Why have I seen RCS advertised for annonymous ftp (and UUCP?) lately. Has the license been voided? Is this only for BSD source licensee's? ] In my case, it's not a religious war. I have both at my finger tips. I spent lots of time and effort making VCS work, and I liked the results. Then I tried SCCS, 'cause nobody had RCS for Xenix. I had enough bad experiences with SCCS to try RCS again when I could. RCS lost. VCS would lose too, except it has no competition (that I have any experience with) in the MS-DOS world. RCS watch out, VCS is coming to a system near you ;-). BTW: I like Sys V, and emacs (in particular, Jove). Hope this allows all concerned to categorize me and dismiss my remarks I don't fit their mold. [ roy@phri.UUCP (Roy Smith) signed article <3435@phri.UUCP>: ] >-- >Roy Smith, System Administrator >Public Health Research Institute >{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net >"The connector is the network" In short, (I know, I wasn't) SCCS is the more capable, flexible, and powerful of the two. Admittedly it is hard to learn, and in some cases, hard to use, but isn't everything that's more powerful and flexible? :-) [ How's that for tootin' your own horn? Ok, everyone, WAKE-UP! ] [ Roy: I was going to say "Don't you like Sun?", but on further reflection of your quote, I see that Sun's "motto" follows directly from it. ] -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
allbery@ncoast.UUCP (Brandon S. Allbery) (08/20/88)
As quoted from <1988Aug16.010040.16706@gpu.utcs.toronto.edu> by woods@gpu.utcs.toronto.edu (Greg Woods): +--------------- | SCCS disadvantages: For me, SCCS is only missing one necessary feature, | and one handy feature: 1. No "automatic" capability to mark a set of | files with a "version" (as opposed to revision) tag. 2. No "state" tag. | | [ HELP! Anyone know how to USE vc? I think it can be used to do this. ] +--------------- A shell script front-end to SCCS can use the %Q% and %T% keywords for this. If you really want to play with vc, I've used it... send me mail. +--------------- | Of small note, and of complete indifference to me, is SCCS's in-ability | to include the comments, MR numbers, and other interesting information | (that the prs command is able to extract and display from the s-file) | into the g-file (actual source). It is slightly annoying that the get +--------------- I once had a front-end that incorporated an RCS-style log into a source file, via prs. (Why past tense? I use RCS now, if I use anything at all. Generally it's easier to just save "old" and "new" versions of the source directory, since I usually end up tweaking more than just a few files.) +--------------- | level, branch, and sequence id's: ie: only 1.1.1.1. RCS seems to allow | zero (0) as a revision component. I haven't had any success getting | SCCS to use such. +--------------- SCCS translates an "0" to a "1", usually. This can vary based on branching. +--------------- | According to something I read in the RCS manuals, RCS "simplifies | software distribution ... [such that] ... customer changes can be merged | into distributed versions locally, or by the development group". This | probably isn't as easy as it implies. It certianly isn't that easy with | SCCS. At least not without L. Wall's Patch utility. I've never tried +--------------- That quote refers to the ability to read an expanded RCS keyword in a "ci"'d file and use the keywords to determine the new delta's revision level. +--------------- | In short, (I know, I wasn't) SCCS is the more capable, flexible, and | powerful of the two. Admittedly it is hard to learn, and in some cases, | hard to use, but isn't everything that's more powerful and flexible? :-) +--------------- When I'm working on source, I don't want the stupid version control system to get in my way. RCS is much nicer than SCCS in this regard, although (as I said above) in my case a "low-tech" solution tends to be even nicer. ++Brandon -- Brandon S. Allbery, uunet!marque!ncoast!allbery DELPHI: ALLBERY For comp.sources.misc send mail to ncoast!sources-misc
woods@gpu.utcs.toronto.edu (Greg Woods) (08/21/88)
In article <12261@ncoast.UUCP> allbery@ncoast.UUCP (Brandon S. Allbery) writes: > As quoted from <1988Aug16.010040.16706@gpu.utcs.toronto.edu> by ME: [ WOW! Those article id's really are a mile long :-). ] > | [ HELP! Anyone know how to USE vc? I think it can be used to do this. ] > > A shell script front-end to SCCS can use the %Q% and %T% keywords for this. Actually I thought of this, but it isn't nearly flexible enough for me. I want RCS's version names, and I'd use RCS's file states, if available. > I once had a front-end that incorporated an RCS-style log into a source > file, via prs. That sounds like over-kill, since the revision management software should automatically do this for you. Actually, I guess it would eliminate the problem of storing the comments in the database twice :-). > | According to something I read in the RCS manuals, RCS "simplifies > | software distribution ... [such that] ... customer changes can be merged > | into distributed versions locally, or by the development group". > > That quote refers to the ability to read an expanded RCS keyword in a "ci"'d > file and use the keywords to determine the new delta's revision level. I still don't see any way of doing it without patch, or a copy of the version database. I suppose that is of some use, though a very simple front end could do the same thing for SCCS, if one had a standard for what strings. I've thought of doing this with sccs.c. In fact, the sccs front-end is missing the ability to easily, and automatically create SCCS files where necessary, and this could be an option to that capability. > When I'm working on source, I don't want the stupid version control system > to get in my way. RCS is much nicer than SCCS in this regard, although (as > I said above) in my case a "low-tech" solution tends to be even nicer. The only time it gets in my way is initially, when I have to set everything up in a new directory. After that, simple habit makes things quite easy. When you have to do it for large projects, the same task, for small projects, and day-by-day maintenance becomes automatic. -- Greg Woods. UUCP: utgpu!woods, utgpu!{ontmoh, ontmoh!ixpierre}!woods VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
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)