Xref: utzoo comp.software-eng:5584 comp.sys.apollo:8996 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!spool.mu.edu!cs.umn.edu!uc!apctrc!zdlc03 From: zdlc03@trc.amoco.com (Dan L. Cummings) Newsgroups: comp.software-eng,comp.sys.apollo Subject: (Summary) SCCS/RCS/DSEE/NSE Message-ID: <1991May10.193856.6952@trc.amoco.com> Date: 10 May 91 19:38:56 GMT Sender: usenet@trc.amoco.com (News) Organization: Amoco Production Company Lines: 1101 X-Checksum-Snefru: a5a2118f 4c4b63bc 92285959 5fb407b7 This is the accumulation of responses I received to my request for opinions on source code control & configuration management tools. (I did no editing other than to remove a question/response pair related to DSEE not being case sensitive. This has not been an issue for 2 years now.) This file is approx 1100 lines. ------------- cut here --------------- From rdm@cernapo.cern.ch Tue May 7 08:57:08 1991 Date: Tue, 7 May 91 15:44:53 +0300 From: rdm@cernapo.cern.ch (Alphonse Rademakers) To: zdlc03@trc.amoco.com (Dan L. Cummings) In-Reply-To: zdlc03@trc.amoco.com's message of 6 May 91 22:04:25 GMT Subject: Opinions wanted: sccs/rcs/dsee/nse Status: RO Here some reference to a code management system used by a large number of people in the high energy physics world. It is very powerful and runs on a large number of platforms. It is used by a large number of physics institutes in Europe and the States (SSC, Cornell, ...). ========================= CMZ A Source Code Management System CMZ is an advanced, interactive, fast, customizable, machine-independent and PATCHY (1) compatible source code management system for FORTRAN 77 and C source code and text files. We call CMZ advanced because it offers code management facilities that go beyond simple bookkeeping and version archiving. CMZ supports the developer during the project development phase: instantaneous access to any routine in the local editor; check for undefined variables; automatic indentation of routines; display of routine calling tree; renumbering of statement labels; reordering of decks in alphabetical order; storage of related decks in directories; single command to compile a routine and update the object library; import and export of source and text files. In the maintenance phase CMZ offers the user: an extensive history mechanism; generation of a correction set by comparing the changed routines with the routines in the master library; using the correction set for generating a new object library; updating the master library by applying the correction set. We call CMZ interactive because it provides a UNIX like shell in which you give commands. Every command gives you direct feedback. In case you issue a wrong command, argument or parameter you get an appropriate error message and in case of successful completion you get a new prompt. CMZ also provides a batch mode to execute a series of commands without intervention from the user. CMZ is fast because it stores the source code in a RZ direct-access file. This makes it possible to access any routine instantaneously for editing, copying, compiling, searching, etc. RZ is the database management part of the ZEBRA (2) package. Customizable means that you can redefine or rename CMZ commands. For example, if a user prefers to use the UNIX ls command to list the contents of a directory instead of the CMZ command DIR, he/she can have it. It is also possible to write entirely new commands using a MACRO facility. In a MACRO you can combine a number of commands to act as one new command. These facilities are offered by the KUIP user interface package, which also provides the user interface for PAW (3). CMZ is machine-independent. This means that the operation of CMZ is completely independent of the underlying hardware. For example, the CMZ command to compile a routine behaves the same on any machine. Currently CMZ is running on Apollo, IBM VM/CMS, IBM MVS, IBM RS/6000, VAX/VMS, Ultrix, Gould UTX, Cray Unicos, Sun, SGI, HPUX. PATCHY compatible means that CMZ uses the same source code directives as the successful but 20 year old batch oriented PATCHY source code manager. This makes it trivial to convert an existing PATCHY master (PAM) file into a CMZ library file. CMZ in the Code Development Phase After creating a new CMZ library file with MAKE or connecting an existing one with FILE, material can be stored into this file. Up to 50 CMZ library files can be connected to CMZ at one time without any degradation in access time. The commands YTOC, FTOC, CCTOC and TTOC import source material in PAM, FORTRAN, C and text format, respectively. With the command EDIT material can be edited using the local editor. The commands CFOR, CFLIB, MKALL, FOR and LIB provide transparent access to the local FORTRAN or C compilers and archiver. With the commands CTOY, CTOF and CTOT the contents of the CMZ library file can be exported again in PAM, FORTRAN or C and text format, respectively. Due to the interface with the local editor, compilers and archiver the edit-compile cycle of CMZ is at least twice as short as that of any of its competitors. Furthermore CMZ has a number of utility commands. The utility commands can be separated into commands that move (COPY, DELETE, MOVE, etc.) or locate (GREP, FIND, DIFF, etc.) material stored in a CMZ library file, commands that check and tidy FORTRAN code (UNDEF, TREE, LABEL, INDENT) and commands that control the user interface. CMZ in the Code Maintenance Phase During the code development phase the emphasis is on speed, interactivity, fast access to the local editor, compiler and archiver. During the code maintenance phase the emphasis is on version management, generation and usage of correction sets and batch performance. With the VERSION command the current state of a CMZ library file can be marked as belonging to a certain version or release. Once decks have been marked with a version number they can be operated on by the commands CTOF, CTOY, CTOT, CFLIB, CFOR, etc. Once programs reach a certain size and become fairly stable it is no longer efficient to distribute after every change the whole CMZ library file. In this case it is much more efficient to distribute only a correction set. A CMZ correction set can be generated by the YCORR command. The commands USE and UPDATE use the correction set to update a CMZ library file to reflect the original CMZ file. Availability CMZ will be distributed, via CERN, to all European High Energy Physics laboratories and institutes as part of the CERN program library. Non HEP institutes and non European HEP institutes can obtain CMZ after paying a license fee. For more information contact codeme@cernapo.cern.ch. =============================== (1) PATCHY is a batch oriented source code control system used in the world of high energy and nuclear physics (more than 10000 users and many milion lines of code). (2) ZEBRA is a Fortran based memory management package. Besides memory management it also provides for machine independent binary file transfer. (3) PAW stands for Physics Analysis Workstation. It is an extremely powerful scientific data analysis and visualisation program. Orignally developed for the data analysis of high energy physics experiments it is now used in almost all fields of physics. From lubkin@apollo.com Tue May 7 14:27:09 1991 Received: by apsa.trc.amoco.com ( 5.52 (84)/SMI-4.0) id AA03048; Tue, 7 May 91 14:27:03 CDT Received: from netserv2 (netserv2.trc.amoco.com) by trc.amoco.com (4.1/SMI-4.1) id AA12857; Tue, 7 May 91 14:28:03 CDT Received: from uc.msc.edu by netserv2 (4.1/SMI-4.0) id AA16224; Tue, 7 May 91 14:00:38 CDT Received: from amway.ch.apollo.hp.com by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA08852; Tue, 7 May 91 14:27:28 -0500 Received: from xuucp.ch.apollo.hp.com by apollo.com id Tue, 7 May 91 15:15:54 EDT Received: by xuucp.ch.apollo.hp.com id ; Tue, 7 May 91 15:13:40 EDT Message-Id: <9105071913.AA16749@xuucp.ch.apollo.hp.com> Received: by daphne.ch.apollo.hp.com id AA24229; Tue, 7 May 91 15:01:25 EDT Received: by fireball.apollo.hp.com id ; Tue, 7 May 91 14:59:38 EDT From: lubkin@apollo.com (David Lubkin) Date: Tue, 7 May 91 14:59:37 EDT Subject: DSEE To: dcummings@trc.amoco.com Status: R For information on DSEE V4, see my paper for the 3rd International Workshop on Software Configuration Management or the HP Journal article. For cross-product comparisons, see the papers/articles by Dart, Feiler, and Forte. If you have any specific questions about DSEE, I'll be glad to answer them. You can also pose them to the DSEE mailing list, which I note that you are on. ( post to info-dsee@apollo.hp.com ; requests to info-dsee-request@apollo.hp.com ) I'm also forwarding a set of comments that users have made about DSEE in a separate message. -- David Lubkin. Partial DSEE Bibliography Robert P. Chase, Jr., David B. Leblang, and Howard Spilke, "Parallel Building: Experience with a CASE System for Workstation Networks," Proceedings of the Second IEEE Workstations, 1988, pp 2-11. Robert P. Chase, Jr. and Howard Spilke, Device for Managing Software Configurations in Parallel in a Network, U.S. Patent No. 4,951,192. Susan A. Dart, "Concepts in Configuration Management Systems," 3rd International Workshop on Software Configuration Management, Trondheim, Norway, 12-14 June 1991. Also available as Technical Report CMU/SEI-90-TR-11, Software Engineering Institute, Carnegie-Mellon University. David W. Eaton, "Cross Development of Multi-Million Line Software Using DSEE 3.0," distributed at 1988 ADUS Conference, Wash., D.C. Peter H. Feiler, "Configuration Management Models in Commercial Environments," Technical Report CMU/SEI-91-TR-7 ESD-9-TR-7, March 1991, Software Engineering Institute, Carnegie-Mellon University. Gene Forte, "Configuration Management Survey," CASE OUTLOOK 90(2), 1990. David B. Leblang and Robert P. Chase, Jr., "Computer-Aided Software Engineering: a Distributed Workstation Environment," ACM SIGPLAN/SIGSOFT Conf. on Practical Software Development Environments, Apr. 84. Published in a combined issue of ACM Software Engineering Notices and ACM SIGPLAN Notices, May 1984, pp. 104-112. David B. Leblang and Gordon D. McLean, Jr., "Configuration Management for Large-Scale Software Development Efforts," Workshop on Software Engineering for Programming-in-the-Large, Harwichport, Mass. Jun. 10-12 1985 (Sponsor: GTE Labs, Waltham, Mass.). David B. Leblang and Robert P. Chase, Jr., "The Domain Software Engineering Environment for Large-Scale Software Development Efforts," Proceedings of the First IEEE International Conference on Computer Workstations, 1985, pp 266-280. David B. Leblang and Robert P. Chase, Jr., "Parallel Software Configuration Management in a Network Environment," IEEE Software, Nov. 1987, pp 28-35. David B. Leblang, Gordon McLean, Jr., Howard Spilke, and Robert P. Chase, Jr., Computer Device for Aiding in the Development of Software System, U.S. Patent No. 4,809,170. David B. Leblang, Robert P. Chase, Jr., and Howard Spilke, "Increasing Productivity with a Parallel Configuration Manager," Proceedings of the International Workshop on Software Version and Configuration Control. Stuttgart: B.G. Teubner, 1988. David Lubkin, "DSEE: The Cure for CM Blues," Proceedings Of The First Hewlett-Packard Software Engineering Productivity Conference, San Jose, Calif., Aug. 1990. David Lubkin, "Integrated Text Management," International Workshop on UNIX-Based Software Development Environment, Dallas, Texas, 15-18 Jan. 1991. David Lubkin, "Heterogeneous Configuration Management with DSEE," 3rd International Workshop on Software Configuration Management, Trondheim, Norway, 12-14 June 1991. David Lubkin, "DSEE: A Software Configuration Management Tool," HP Journal, June 1991. David Lubkin, Heterogeneous Software Configuration Management Apparatus, U.S. Patent Pending. McCreary, D., Networking Unties OS Development Knot," ESD Magazine, Feb. 1988. ------- From lubkin@apollo.com Tue May 7 14:40:50 1991 Received: by apsa.trc.amoco.com ( 5.52 (84)/SMI-4.0) id AA03054; Tue, 7 May 91 14:40:42 CDT Received: from netserv2 (netserv2.trc.amoco.com) by trc.amoco.com (4.1/SMI-4.1) id AA12923; Tue, 7 May 91 14:41:39 CDT Received: from uc.msc.edu by netserv2 (4.1/SMI-4.0) id AA16236; Tue, 7 May 91 14:14:09 CDT Received: from amway.ch.apollo.hp.com by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA09158; Tue, 7 May 91 14:40:52 -0500 Received: from xuucp.ch.apollo.hp.com by apollo.com id Tue, 7 May 91 15:31:43 EDT Received: by xuucp.ch.apollo.hp.com id ; Tue, 7 May 91 15:29:27 EDT Message-Id: <9105071929.AA16842@xuucp.ch.apollo.hp.com> Received: by daphne.ch.apollo.hp.com id AA24311; Tue, 7 May 91 15:14:34 EDT Received: by fireball.apollo.hp.com id ; Tue, 7 May 91 15:12:46 EDT From: lubkin@apollo.com (David Lubkin) Date: Tue, 7 May 91 15:12:44 EDT Subject: DSEE/SCCS/RCS comments To: dcummings@trc.amoco.com Status: R Article 475 of comp.software-eng: Path: apollo!ulowell!m2c!husc6!uwvax!dogie!uwmcsd1!marque!uunet!mcvax!ukc!stl!stc!idec!camcon!igp From: igp@camcon.uucp (Ian Phillipps) Newsgroups: comp.software-eng,comp.unix.wizards Subject: Usage of sccs - a summary of replies Keywords: sccs control project Message-ID: <1431@titan.camcon.uucp> Date: 29 Apr 88 11:22 GMT Organization: Cambridge Consultants Ltd., Cambridge, UK Lines: 84 Xref: apollo comp.software-eng:475 comp.unix.wizards:7786 A few weeks ago I posted a request for 'sccs' users to tell me of hints or problems. Here is a short summary of the responses; more info on request. >From Marc Evans .. BSD sccs assumed... - Create a directory structure in which the SCCS sources will be placed. All of these directories should be owned by sccs, group set to sccs, and mode 750 or 755. - Create a second directory structure which is a mirror image of the first, but this time the owners, and groups can be almost anything. If you want anybody to be able to use any of the directories, set the mode to 777. In each of these directories, create the standard SCCS symbolic link to the corresponding directory in the first directory structure. - Have each programmer copy (not move) their code into the proper directory in the second directory structure. You should then create the SCCS version of each before they do any more work (sccs create -r1 [other admin flags] source files). Also, archive onto tape the orignal sources from their original directories, and then delete them. - Chances are, each programmer has created makefiles in their own manner. You will probably want to create all of the makefiles yourself, following some standard. At the end of this message, I will enclose a makefile generator and dependancy list generator that I use here. This can make your job alot easier. [Sun's 'cc' will generate dependancy lists from c sources] - When creating the makefiles, remember that you need 2 things to happen; they should traverse directories, and also make targets. I also had a reply from Robert Hartman , who is in charge of the Sun 'make' and 'sccs' files, who also mentioned symbolic linking. (It also made sure I read the make and sccs manuals more thoroughly :) He also dealt with techniques like /usr/src/lib/foo/libfoo.a: FORCE cd $(@D) ; make $(@F) FORCE: # null rule to perform nested makes. Andy Greener writes: Administer everything, even README files. It makes things easier in the long run, even if it sounds like overkill. The major problem with SCCS is the lack of any sort of "symbolic" tagging of versions. ... However it can be dealt with. We have built some tools for automatically constructing releases from ... snapshot files. Avoid SCCS branching. It sucks (basically!). Use SCCS id keywords in sources so they appear in the binaries... We use: "%Z%%Q%%M% %I%" , where %Q% is set to the path segment from the root of the source tree to the current dir. Beware of administering non-printable files (e.g. icons). Charles Lambert : .. Keep a System Description File that lists all the version-numbered sources needed for a correct build. This is simply a text document that has to be kept up to date. Since nobody remembers to keep documents up to date, it is wise to have your shell scripts do it automatically: every time someone deltas a file, the new version number gets written into the SDF. John Dempsey At home, I have a Unix PC ... I really don't see any pitfalls to using SCCS. However, RCS is the better source code control system, because it will instantly give you the most recent version of a source file. ... I think SCCS is pretty straight forward. Thanks to everyone who replied. -- UUCP: ...!ukc!camcon!igp | Cambridge Consultants Ltd | Ian Phillipps or: igp@camcon.uucp | Science Park, Milton Road |----------------- Phone: +44 223 358855 | Cambridge CB4 4DW, England | Article 10059 of comp.unix.wizards: Path: apollo!ulowell!bbn!husc6!uwvax!rutgers!bellcore!clyde!watmath!water!utgpu!woods From: woods@gpu.utcs.toronto.edu (Greg Woods) Newsgroups: comp.unix.wizards Subject: Date: 16 Aug 88 05:00 GMT References: <16791@adm.ARPA> <1988Aug12.234138.18684@gpu.utcs.toronto.edu> <3435@phri.UUCP> Reply-To: woods@gpu.utcs.Toronto.EDU (Greg Woods) Organization: G. A. W. Constulting Lines: 171 Checksum: 13261 >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 Article 2563 of comp.sys.apollo: Path: apollo!ulowell!bbn!usc!hacgate!lori From: lori@hacgate.scg.hac.com (Lori Barfield) Newsgroups: comp.sys.apollo Subject: DSEE Opinions Message-ID: <3860@hacgate.scg.hac.com> Date: 30 May 89 23:48 GMT Organization: Hughes Aircraft Company, El Segundo CA Lines: 7 I'll be evaluating DSEE for purchase soon. Anyone have any gotchas, favorite features, comparisons with other products, or other potential "I told you so"s to share? Thanks in advance, ..lori Article 2565 of comp.sys.apollo: Path: apollo!ulowell!m2c!husc6!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CIM-VAX.HONEYWELL.COM!derstad From: derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") Newsgroups: comp.sys.apollo Subject: Re: DSEE Opinions Message-ID: <8905311318.AA02799@umix.cc.umich.edu> Date: 31 May 89 13:56 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 25 We've used DSEE here since 1985. My project was the first at our site to make use of DSEE, and we've been relatively happy. Favorite bells include concurrent building on multiple nodes (easy to set up, just use a "set builder //gollum //frodo //gimli //sauron //ugluk" or whatever), which dramatically decreases the amount of wall-clock time required to build, especially at the tail end of release cycles where we're typically rebuilding entire software systems; the revision archiving and audit trail facilities; and the task list manager, which we use to keep things from slipping through the cracks and to keep junior programmers and students on track. For reference, we do software as part of an integrate package for ASIC design (along with cell libraries). We have about 150 to 200 thousand lines of text in DSEE, mostly code, in about 80 modules. I couldn't imagine doing my job without DSEE anymore. Dave Erstad DERSTAD@cim-vax.honeywell.com Principal Design Automation Engineer Honeywell SSEC Article 2600 of comp.sys.apollo: Path: apollo!ulowell!m2c!husc6!cs.utexas.edu!uunet!hi-csc!slocum From: slocum@hi-csc.UUCP (Brett Slocum) Newsgroups: comp.sys.apollo Subject: Re: DSEE Opinions Message-ID: <43a6dde5.805@hi-csc.UUCP> Date: 5 Jun 89 16:52 GMT References: <3860@hacgate.scg.hac.com> Reply-To: slocum@hi-csc.UUCP (Brett Slocum) Organization: csdd Lines: 21 In article <3860@hacgate.scg.hac.com> lori@hacgate.scg.hac.com (Lori Barfield) writes: >I'll be evaluating DSEE for purchase soon. Anyone have any gotchas, >favorite features, comparisons with other products, or other potential >"I told you so"s to share? > >Thanks in advance, > >...lori I would confirm Dave Erstad's comments about DSEE. We used DSEE on a huge SW project involving a team of programmers that changed often, 100-200 K lines of code, and software that was full of kludges, etc. We performed so efficiently, that we had extra contract funds left over for additional functionality. About half the code was new development, and the other half was existing code that needed massive reworking, enhancements, input and output filters, and maintenance. The DSEE performed both of these functions well. -- Brett Slocum | If you keep your head, while everyone or | else loses theirs, you'll be the only or | one needing a haircut. Article 2602 of comp.sys.apollo: Path: apollo!ulowell!m2c!husc6!rutgers!cs.utexas.edu!uunet!tiamat!quintro!reb From: reb@quintro.UUCP (Roger E. Benz) Newsgroups: comp.sys.apollo Subject: Re: DSEE Opinions Message-ID: <349@quintro.UUCP> Date: 5 Jun 89 16:13 GMT References: <3860@hacgate.scg.hac.com> <11400011@uicsrd.csrd.uiuc.edu> Reply-To: reb@quintro.UUCP (Roger E. Benz) Organization: none Lines: 31 Release 3.2 and 3.3 of DSEE is case-sensitive. 3.2 is for SR9.7 nodes and 3.3 is for SR10 nodes. Also, I have been using DSEE for three years and I really like it. Its best features are: Remote building using NCS, -target option for building different versions of the software for different platforms, multi-user and multi-node support DSEE can be ran from either a node or a terminal connected to a serial port. As far as task lists and monitors we don't use them (they could be useful, however). One thing I have learned is that for just one person on a project DSEE is a little more cumborsome than using 'make'. But if two or more people are involved DSEE is nice. -- Roger E. Benz Phone = (217) 223-3211 Quintron Corporation Quincy, Il UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken Article 2613 of comp.sys.apollo: Path: apollo!ulowell!m2c!husc6!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!CIM-VAX.HONEYWELL.COM!derstad From: derstad@CIM-VAX.HONEYWELL.COM ("DAVE ERSTAD") Newsgroups: comp.sys.apollo Subject: Re: DSEE Opinions Message-ID: <8906062322.AA19681@umix.cc.umich.edu> Date: 6 Jun 89 21:08 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 18 Just a minor point. Contrary to what some Apollo publications might imply, DSEE does not use NCS for remote builds. Instead, the remote build stuff was kludged in by the DSEE writers. If you ask someone they'll generally confirm that. For that matter, it must be true because no location brokers are needed to run DSEE. I would think that at some point in the future this might change, especially since sys_admins are going to have to learn enough NCS-ese to handle the registrys at SR10, so adding DSEE builders isn't as big a step. This information is correct as of 3.2.1 Dave Erstad Principal Design Automation Engineer Honeywell SSEC DERSTAD@cim-vax.honeywell.com Article 3192 of comp.sys.apollo: Path: apollo!hp-sdd!ucsdhub!sdcsvax!network.ucsd.edu!ucsd!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!tiamat!quintro!reb From: reb@quintro.uucp (Roger E. Benz) Newsgroups: comp.sys.apollo Subject: Re: Any DSEE users out there? Message-ID: <1989Sep9.171023.26488@quintro.uucp> Date: 9 Sep 89 17:10 GMT References: <2260001@hpcuhc.HP.COM> Reply-To: reb@quintro.UUCP (Roger E. Benz) Organization: none Lines: 12 In article <2260001@hpcuhc.HP.COM> edwardm@hpcuhc.HP.COM (Edward McClanahan) writes: >Anybody out there in Apollo User Land have experience with DSEE? Forgive me >if this has been discussed "ad nasueum" in this notesgroup before... We have been using DSEE for about 3 years now and generaly like it. It has a few problems but many nice features. If you (or anyone) has any questions please feel free to contact me. -- Roger E. Benz Phone = (217) 223-3211 Quintron Corporation Quincy, Il UUCP: tiamat!quintro!reb@uunet or quintro!reb@lll-winken Article 19815 of comp.unix.questions: Path: apollo!hp-sdd!hplabs!hpda!hpcuhc!runyan From: runyan@hpcuhc.HP.COM (Mark Runyan) Newsgroups: comp.unix.questions Subject: Re: RCS vs. SCCS Message-ID: <250003@hpcuhc.HP.COM> Date: 16 Mar 90 18:47 GMT References: <1990Mar15.204111.4923@csmil.umich.edu> Organization: HP GSY/USO/UKL Cupertino, CA, USA Lines: 68 >/ hpcuhc:comp.unix.questions / holtz@csmil.umich.edu / 12:41 pm Mar 15, 1990 / > >What are the differences between RCS and SCCS? >---------- A simple questions that has a complicated and long answer. Possible short answers. 1. SCCS is supported by AT&T. RCS isn't. 2. RCS allows you treat a set of files as a family of files while SCCS is meant primarily for keeping the revision history of files. RCS has the ability to use symbolic names to point to sets of revisions. 3. [religious argument] RCS has an easier interface for first time users. SCCS has more options for determining when a specific line of code was added to a system. 4. RCS files are directly editable. SCCS files should only be acted on by the SCCS tools. 5. RCS keeps history in files with a ",v" suffix. SCCS keeps history in files with a "s." prefix. 6. Locks are kept in separate files for SCCS. A lock on an RCS file is kept in the RCS file. 7. RCS stores its revisions so retrieval of the latest revision is quick and easy, but early revisions take longer. SCCS stores revisions so that recovering any given revision takes a constant amount of time which increases with the number of revisions stored. 8. You can translate SCCS to RCS, but not the other way. 9. They use different keywords that are expanded in the text. For SCCS the keyword "%R%" is replaced with the revision number if the file is checked out for reading. In RCS, the keyword $Revision$ has the revision number added to it when the file is checked out (either locked or not). Other than that (and a few more others may throw in) they are essentially the same. As a comparison of the commands: SCCS Command RCS Command Explanation admin -i -nfile s.file ci file,v Checks in the file for the first time, creating the revision history file. get s.file co file,v Check out a file for reading. get -e s.file co -l file,v Check out a file for modification delta s.file ci file,v Check in a file previously locked prs s.file rlog file,v Print a history of the file. sccsdiff -rx -ry s.file rcsdiff -rx -ry file,v Compare two revisions. ??? rcs -l file,v Lock the latest revision ??? rcs -u file,v Unlock the latest revision. Possible to break another's lock, but mail is sent to the other person to explain why. For more details, read "RCS - A system for Version Control", Walter Tichy, _Software_Practice_and_ Experience_, Vol 15(7), 637-654 (July 1985) "Design, Implementation, and Evaluation of a Revision Control System", Walter Tichy, _IEEE_, 58-67, (??? 1982) Article 2978 of comp.software-eng: Path: apollo!hp-sdd!ncr-sd!ncrcae!hubcap!emory!samsung!cs.utexas.edu!mailrus!cornell!uw-beaver!Teknowledge.COM!unix!hplabs!hpda!hpcuhc!runyan From: runyan@hpcuhc.HP.COM (Mark Runyan) Newsgroups: comp.software-eng Subject: Re: Need guidance in Software Configuration Management (SCM( Message-ID: <2480009@hpcuhc.HP.COM> Date: 19 Mar 90 17:37 GMT References: <398@fltk.UUCP> Organization: HP GSY/USO/UKL Cupertino, CA, USA Lines: 68 >/ dnb@fltk.UUCP (David Buonomo) / 9:24 am Mar 16, 1990 / >Does anybody know of any literature that pertains to Software Configuration >Management in a UNIX environment. Experience and horror stories are welcome. General books: _Software_Configuration_Management_:_Coordination_for_Team_Productivity_, by Wayne A. Babich, Addison-Wesley, 1986, ISBN 0-201-10161-0. _The_Program_Development_Process_, by J.D. Aron, Addison-Wesley, 1983, ISBN 0-201-14451-4. _Software_Configuration_Management_:_An_Investment_in_Product_Integrity_, by E. Bersoff, V. Henderson, and S. Siegel, Prentice-Hall, 1980, ISBN 0-13-821769-6. Papers: "RCS - A System for Version Control", Walter Tichy, _Software-Practice_and_ Experience_, Vol 15(7), p637-654, (July 1985). "Build-A Software Construction Tool", V. Erickson and J. Pellegrin, _AT&T_Bell_Lab_Technical_Journal_, Vol 63(6), p1049-1059, (July-August 1984). "Design, Implementation, and Evaluation of a Revision Control System", Walter Tichy, _IEEE_, Vol ?(?), p 58-67, (??? 1982). "Project Hygiene", Vic Stenning, _USENIX_Workshop_Proceedings_on_Software_ _Management_, p1-9, (April 3-4, 1989). "Software Manaagement Using a CASE Environment", M. Honda and T. Miller, _USENIX_Workshop_Proceedings_on_Software_Management_, p11-16, (April 3-4, 1989). "Boxes, Links, and Parallel Trees: Elements of a Configuration Management System", Andy Glew, _USENIX_Workshop_Proceedings_on_Software_Management_, p17-28(April 3-4, 1989). "Controlling Software for Multiple Projects", Dale Miller, _USENIX_Workshop_ _Proceedings_on_Software_Management_, p39-50, (April 3-4, 1989). "CCSLAND", Nathaniel Bronson III, _USENIX_Workshop_Proceedings_on_Software_ _Management_, p87-94, (April 3-4, 1989). "The Release Engineering of 4.3BSD", M. McKusick, M. Karels, and K. Bostic, _USENIX_Workshop_Proceedings_on_Software_Management_, p95-100, (April 3-4, 1989). "Rtools: Tools for Software Management in a Distributed Computing Environment", H harrison, s. Schaefer, T. Yoo, _USENIX_Conference_ _Proceedings_, p85-106, (June 20-24, 1988). "A Schema for Configuration Management", Terrence Miller, _Proceedings_of_the_2nd_Int'l_Workshop_on_Software_Configuration_Management, October 24-27 1989, Princeton. Published as ACM SIGSOFT Software Engineering Notes, Volume 17(8) pp 26-29, November 1989. >We are planning on using RCS on multiple platforms. Thanks in advance for >any help. You will probably have to build tools around RCS to make the system easier to deal with. Spend some time designing the tools so you can live with them. You might want to look into the SHAPE/AFS toolset floating around on the network. Mark Runyan From: boundy (David Boundy) Date: mon, 6 may 91 11:46:51 Subject: DSEE heterogenous builds Sender: boundy To: rch@hpcupt3.cup.hp.com, runyan@hpcuhc.cup.hp.com Cc: lubkin Mark & Bob: Re: hetero DSEE builds. I'm in the compiler group in Chelmsford. We are not doing real hetero builds yet, though now that we have our compilers targeted and hosted on PA / OSF, that's going to happen within weeks. Thus, I can't address your question dead on, but I can give you a data point on the edge of an answer. First to set the stage: To rebuild an entire compiler takes about 10 miscellaneous tool invocations, 180 compilations, 7 intermediate binds ( ld for UNIX folks ), and one final bind. Since our compilers, optimizers, and debuggers all work together, we do our development with the optimizer turned on and the resultant explosion of the amount of information it takes to describe the resultant code to the optimizer. A debuggable compiler is 22 Megabytes, a stripped compiler is a bit over 1 Meg. We have noticed for some time that the slow step in building a compiler is the final bind. For instance, in the build I just did, the compile took 80 sec, the intermediate bind took 70 sec, and the final bind took about 5 minutes. SOmtimes it takes almost 10. This final bind takes about 90 seconds of CPU time. If you just do the math, almost the entire difference between the 5 minutes of clock time and the 90 seconds is accounted for by pumping 40 Meg over a 10 Mbit/sec network. So, the network really is the bottleneck for this process, and you really do have to be quite concerned about this. But note that this network delay has very little to do with DSEE -- packets don't slow down nor ( dramatically ) multiply in number just because the build is proceeding under DSEE's control. To get the time for this final linkedit down closer to the 90 seconds of CPU ( plus some disk latency time ), we'd have to remove both the costs and the benefits of the network -- maybe implementing a network with removable media as the physical layer. :-) DSEE harnesses the power of the network, but can't do it any faster than network bandwidth allows. But, what do you get in return? Several of the rebuild-everything include files have changed since I did my last build. Thus, in a naive world, I would have to rebuild EVERYTHING. Even with DSEE parallel building with 20 DN10000's banging away, this still takes 2 hours. But because of DSEE's shared pool scheme ( and a layer of insulation I'll describe in a moment ), I have a 10-to-15-minute process instead. The time for "make" to digest a Makefile this large is not insubstantial. But I do a "set system / set model / build" first thing when I walk in every morning, then get my morning cup of water and read my mail. Long before I'm done with those tasks, I've got a compiler built, and for the rest of the day I get a compiler built in about 10 minutes ( 15 if the network is really slow ). We've done a few things to reduce the load; for instance, we have a script that runs every midnight that name-versions everything [today] and [yesterday], then builds everything. That way, everything's already built when I walk in ( except for the things I have reserved ). Replaces of big include files don't set everyone on ear. And because they don't, the standard of morality is much higher here than it is in shops where changes are put where it's expedient rather than where it's right. This latter improvement in the quality of our software is the big win: I'd be willing to pay even more cost to the CASE tool if it means I spend less time debugging bugs that crawled in just becasue somebody was too daunted by the task of "fixing it right." Yeah, DSEE has it's problems. Some projects just don't map well onto the "DSEE model of the world." And I suspect that there are a lot of arrows still to go into the backs of those who start using it in a hetero environment in a big way. But I wouldn't trade it for any other set of CASE tools in the world -- I certainly wouldn't trade it for merely Mips. Our group is easily twice as productive with DSEE and 7-to-14 Mips 68000 machines as it would be with infinitely fast PA machines with SCCS/make-quality tools. There are some tools that just make automate the same old tasks, reliving some of the repetitive motion syndrome. DSEE fundamentally changes the way we work. I don't know of another CASE environment that can make that same claim. DSEE really is designed for "software in the large." For small projects, one or two people, "make" competes pretty well. But in our group of 30 engineers, DSEE is the single biggest factor in keeping us as fleet as 10 independent 3-person groups -- we're largely freed from the little day-to-day stability concerns that lead to conservative, slow moving, risk averse, techno-phobic organizations. Go for it! -boundless (-: I find your phrase "a network versus an Apollo ring" a bit jarring. Every non-Apollo thing that calls itself a "network" that I've ever seen is based on NFS. You can't get to a network starting from NFS. :-) ------- From apctrc!uc!shamash!timbuk!uunet!fernwood!portal!gdc!nms!bergquis Wed May 8 08:26:31 CDT 1991 Article 4855 of comp.software-eng: Path: apctrc!uc!shamash!timbuk!uunet!fernwood!portal!gdc!nms!bergquis >From: bergquis@nms.gdc.portal.com (Brett Bergquist) Newsgroups: comp.software-eng Subject: Re: Multi Site RCS Message-ID: <247@wimpy.nms.gdc.portal.com> Date: 7 May 91 12:18:28 GMT References: <1991May3.142232.9405@searchtech.com> Organization: General DataComm, Middlebury CT Lines: 27 mra@searchtech.com (Michael Almond) writes: > We are currently in a situation where we are doing software develop here > at our lab. This software is then taken to another lab to be integrated with > other systems while development continues here. > > Does anyone know of any set of procedures or utilities for doing multi-site > revision control? > > We are currently using RCS. > Try using Brian Berliner's CVS package on top of RCS. It includes a facility to manage vendor software distributions which could possibly used if you consider the software developed at you lab as a vendor distribution and the other labs as end users. Its available on UUNET: volume22/cvs-berliner/part[01-07] volume22/cvs-berliner/patch1 Hope this helps. -- Brett M. Bergquist, Principal Engineer | "Remind me" ... "to write an General DataComm, Inc., | "article on the compulsive reading Middlebury, CT 06762 | of news." - Stranger in a Strange Land Email: bergquis@nms.gdc.portal.com or ...!portal!gdc!nms!bergquis From hildebrand@pan.ssec.honeywell.com Wed May 8 10:17:32 1991 Received: by apsa.trc.amoco.com ( 5.52 (84)/SMI-4.0) id AA03349; Wed, 8 May 91 10:17:30 CDT Received: from netserv2 (netserv2.trc.amoco.com) by trc.amoco.com (4.1/SMI-4.1) id AA07678; Wed, 8 May 91 10:18:36 CDT Received: from uc.msc.edu by netserv2 (4.1/SMI-4.0) id AA16876; Wed, 8 May 91 09:51:16 CDT Received: from SRC.Honeywell.COM by uc.msc.edu (5.65/MSC/v3.0z(901212)) id AA00731; Wed, 8 May 91 10:18:09 -0500 Return-Path: Received: from pan.ssec.honeywell.com (isildur.ssec.honeywell.com) by src.honeywell.com (4.0/smail2.6.3/SRCv0.25); Wed, 8 May 91 10:18:00 CDT id AA26099 for dcummings@trc.amoco.com at trc.amoco.com Posted-Date: Wed, 8 May 91 10:06:25 -0500 Received: by pan.ssec.honeywell.com (5.61/1.34) id AA08329; Wed, 8 May 91 10:06:25 -0500 Date: Wed, 8 May 91 10:06:25 -0500 From: hildebrand@pan.ssec.honeywell.com (Jeff Hildebrand) Message-Id: <9105081506.AA08329@pan.ssec.honeywell.com> To: dcummings%trc.amoco.com@src.honeywell.com Cc: hildebrand@pan.msc.edu, thompson@pan.msc.edu Subject: re: Opinions wanted: sccs/rcs/dsee/nse Status: R > I would like to hear your observations on the captioned tools. > Functionality is the principle concern rather than user interface. > Dan <<<< dcummings@trc.amoco.com I think DSEE is great. I've (at times) exceeded it's limits (the number of libraries accessible by one model in particular), but found ways around such things relatively easily. I really think that some projects we've done here and Honeywell - SSEC could not have been accomplished (at least not to cost and schedule) without the DSEE tool. Functions I like: Audit Trails Compare versions name versions / use specific version / roll back to earlier versions models The DSEE models I think are easy to use (once you have experience, of course) but are cryptic and difficult for beginners. As a beginner, I usually just copied a model from an expert user and modified it for my purposes. Now that I've been using it for ~5 years, it's much easier. The models are also very flexible and allow for handling of a real variety of controllable objects. I've controlled program source, documentation, IC layout data, Vendor specific technology description files, notes and regression tests with DSEE. We've even got people here using it to control models for software like spice. I would be interested in seeing the summary of what you hear from the net. Jeff Hildebrand addresses (in order of decreasing preference): hildebrand@pan.ssec.honeywell.com hildebrand@animal.ssec.honeywell.com hildebran@cim-vax.honeywellcom ------------- cut here --------------- Dan <<<< dcummings@trc.amoco.com