petej@itcode.Eng.Sun.COM (Pete Jolly) (10/20/90)
I come from an environment that used RCS rather heavily and now I am forced (much to my disgust) to use SCCS for source archive control. I don't like SCCS because in my opinion it is too hard to get started with and doesn't offer the overall flexibility that RCS does. I will concede that it may be much more powerful for those large scale projects that have multiple programmers working on the same software. One such thing that I found missing is the ability to store source code revision history in the source file itself. RCS lets you do this by replacing a history variable with the history of the revisions. This allows you to place the history where you want it to go in the extracted version. SCCS has the "prs" option which allows you to print out the revision history on stdout but that, of course, is not in the original source. If someone has a copy of the source file and wants to know what the revision history is, they also need access to the SCCS files. Does anyone out there have any ideas on how to incorporate revision history into SCCS source files?? Thanks in advance, Pete Jolly.
woods@eci386.uucp (Greg A. Woods) (10/25/90)
[ BTW, "Followup-to: poster" doesn't work... :-), and I've dropped the comp.lang cross-posting too.... ] In article <143950@sun.Eng.Sun.COM> petej@itcode.Eng.Sun.COM (Pete Jolly) writes: > I come from an environment that used RCS rather heavily and > now I am forced (much to my disgust) to use SCCS for source > archive control. I don't like SCCS because in my opinion > it is too hard to get started with and doesn't offer the > overall flexibility that RCS does. I will concede that > it may be much more powerful for those large scale projects > that have multiple programmers working on the same software. Have you tried sccs (i.e. Eric Allman's front-end)? It makes using SCCS a breeze. There are even a few other front ends.... I believe SCCS has more overall flexibility than RCS. Just how do you arbitrarily create a custom format for $Header? Sure there are some features in RCS that are useful, such as symbolic tags, but this can be done with a reasonably simple database for SCCS too. I see SCCS as a set of tools, and RCS as a "system". > Does anyone out there have any ideas on how to incorporate > revision history into SCCS source files?? There are several ways I can think of doing this with standard UNIX tools, but my question is why? I find this in-line history stuff rather redundant and it gets in the way of my code. Even if I put it at the end of the file. Prs is always there, again with flexible format. A better place for the history info is in a change-log file, or in some form of release notes. (IMHO) [ Sorry, this might sound pessimistic, or inflamitory, but I want to point out that the original question seems the same way to me! ] -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
rob@b15.INGR.COM (Rob Lemley) (10/27/90)
In <1990Oct25.163501.16809@eci386.uucp> woods@eci386.uucp (Greg A. Woods) writes: >Have you tried sccs (i.e. Eric Allman's front-end)? It makes using >SCCS a breeze. There are even a few other front ends.... Can anyone elaborate on these front ends? Availability, functionality, etc? Thanks, Rob -- Rob Lemley System Consultant, Scanning Software, Intergraph, Huntsville, AL 205-730-1546 ...!uunet!ingr!b15!rob OR b15!rcl@ingr.com
woods@eci386.uucp (Greg A. Woods) (10/29/90)
In article <1762@b15.INGR.COM> rob@b15.INGR.COM (Rob Lemley) writes: > In <1990Oct25.163501.16809@eci386.uucp> woods@eci386.uucp (Greg A. Woods) writes: > >Have you tried sccs (i.e. Eric Allman's front-end)? It makes using > >SCCS a breeze. There are even a few other front ends.... > > Can anyone elaborate on these front ends? Availability, functionality, etc? I use Eric Allman's front-end sccs. It provides for hiding all of the s. and p. files in a subdirectory, usually SCCS. It can be integrated with make, but I usually keep my Makefiles simple, and pretend that the SCCS files don't even exist. Sccs makes this easy, since it's default is to keep complete copies of everything in the working directory. Sccs makes creation of the s. files quite easy, and provides a simple interface to checking in and out by using only the base filename. You don't have to have all files in the SCCS databse, so what I commonly do for local mod's is make everything read-only, and only create s.'s for what I have to change. The read-only status makes it easy to remember to check out something before you modify it. With a simple set of shell functions or aliases, the SCCS directory can indeed be somewhere in a central system or project wide location. (In fact, this could be done with a minor modification to sccs, to handle environment variables). I use sccs with a set of aliases (ksh or csh) that make the interface much like a product called VCS from Polytron. Sccs can be used as a setuid front-end to SCCS, providing some protection to source files in a common directory. Sccs does not provide access control lists. Sccs is covered by the Berkeley Software Distribution copyright, and is essentially freeware. Also in use at our company is a tool called 's'. It has the added advantage of being designed to provide set-uid features that can provide both protection to the source libraries, as well as providing default environments for particular libraries. One example is the "make" option which invokes make in the directory prefix specified. and uses the environment (and user-id) of the librarian. I continue to use SCCS, since it can do almost everything s can do, with a more familiar interface. S is always set-uid, and has something similar to access control lists, providing per-project specification of user access privileges. S has full support for Modification Requests, and can insist on every delta matching a previously supplied MR. S was developed by one of my colleagues, and I don't know if we can release it or not. One problem I've found with using any of these tools (including RCS), has to do with multi-developer projects. If you have a common location for the official sources for a project, owned by the librarian, you have four options for effectively using these tools. 1. You have lots of disk space, and everyone keeps a working directory up-to-date with a full copy of the project. This option works for small to mid-sized projects, but would be a nightmare with something like a complete O/S, etc. 2. You do everything on a single filesystem and everyone has hard links to source files (and maybe objects and libraries) in the project directory. Everyone is very careful about not destroying the links. 3. You have symbolic links, and use them effectively to create a mirror image of the project directory. This is the most flexible option. 4. You have smart makefiles and build scripts which use the versions of sources and objects in the project directory, unless a more recent version exists in the current directory, and only targets affected by stuff in the current directory gets re-built. This is the option I often choose, since I rarely build large projects on systems with symlinks. -- Greg A. Woods woods@{eci386,gate,robohack,ontmoh,tmsoft}.UUCP +1-416-443-1734 [h] +1-416-595-5425 [w] VE3-TCP Toronto, Ontario CANADA
johnl@iecc.cambridge.ma.us (John R. Levine) (10/29/90)
In article <1990Oct28.190212.21838@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >Sccs is covered by the Berkeley Software Distribution copyright, and >is essentially freeware. That's hard to believe. SCCS was written at Bell Labs for PWB. Every version I've ever seen looks to be largely unchanged from the original code. Perhaps you're thinking of RCS which is now under the Gnu copyleft. As far as SCCS front ends go, I've been quite satisfied with some smallish (on the order of 100 lines) shell scripts which I've written many times that let you maintain parallel local source and global sccs trees. For example, if you are in your directory foo/bar and say "Get filexx" it turns into a get of /usr/sccs/foo/bar/s.filexx. A little more shell hackery keeps in each directory a list of checked out files in that directory, for use in "Put" scripts to check them all back in at once, and in makefiles to force recompilation of all the checked out sources. -- John R. Levine, IECC, POB 349, Cambridge MA 02238, +1 617 864 9650 johnl@iecc.cambridge.ma.us, {ima|spdcc|world}!esegue!johnl "Although the moon is smaller than the earth, it is also farther away."
jmm@eci386.uucp (John Macdonald) (10/30/90)
In article <1990Oct29.053733.20959@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: |In article <1990Oct28.190212.21838@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: |>Sccs is covered by the Berkeley Software Distribution copyright, and |>is essentially freeware. | |That's hard to believe. SCCS was written at Bell Labs for PWB. Every |version I've ever seen looks to be largely unchanged from the original code. |Perhaps you're thinking of RCS which is now under the Gnu copyleft. | |As far as SCCS front ends go, [...] Greg is out of town for the rest of the week, so I'll pick up the torch for him. Sccs, the suite of programs including get, delta, admin, etc. was written at Bell Labs for PWB. This suite of programs does not include a program named sccs. Sccs, the program, was a front end from Berkely. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386
rob@b15.INGR.COM (Rob Lemley) (10/31/90)
In <1990Oct29.053733.20959@iecc.cambridge.ma.us> johnl@iecc.cambridge.ma.us (John R. Levine) writes: >In article <1990Oct28.190212.21838@eci386.uucp> woods@eci386.UUCP (Greg A. Woods) writes: >>Sccs is covered by the Berkeley Software Distribution copyright, and >>is essentially freeware. >That's hard to believe. SCCS was written at Bell Labs for PWB. Every >version I've ever seen looks to be largely unchanged from the original code. >Perhaps you're thinking of RCS which is now under the Gnu copyleft. Greg Woods was writing about the SCCS frontend command called "sccs" written by Eric Allman of Berkeley (late 70's to 1980?). A bit of history: RCS was written by Walter F. Tichy, Purdue University (Copyright 1982). The original (prototype) implementation of SCCS (not the frontend sccs) was started in 1972 on the IBM 370 under OS/MVT, coded in SNOBOL4, using the SPITBOL compiler. SCCS was originally designed by Marc J. Rochkind and D.A. Nowitz at Bell Labs. The current(?) implementation of SCCS was written for PWB circa 1973 on the PDP 11/45 under Unix. REFERENCES: Marc J Rochkind, "The Source Code Control System", IEEE Transactions on Software Engineering, Vol SE-1(4), 364-370, Dec 1975. Walter F. Tichy, "RCS -- A System for Version Control", Software--Practice and Experience, Vol 15(7), 637-654, Jul 1985. -- Rob Lemley System Consultant, Scanning Software, Intergraph, Huntsville, AL ...!uunet!ingr!b15!rob OR b15!rcl@ingr.com 205-730-1546
guy@auspex.auspex.com (Guy Harris) (10/31/90)
>>Sccs is covered by the Berkeley Software Distribution copyright, and >>is essentially freeware. > >That's hard to believe. SCCS was written at Bell Labs for PWB. Yes, but "sccs" was written at Berkeley by Eric Allman. One minor disadvantage of an otherwise reasonable name for Eric's utility is that you can get confusion of this sort....