Path: utzoo!attcan!uunet!zephyr!tektronix!orca!anvil!stank From: stank@anvil.WV.TEK.COM (Stan Kalinowski) Newsgroups: comp.software-eng Subject: Re: Source Code Control Message-ID: <3776@orca.WV.TEK.COM> Date: 5 Jul 89 01:22:40 GMT References: <597@pegasus.ATT.COM> <791@redsox.bsw.com> Sender: nobody@orca.WV.TEK.COM Reply-To: stank@anvil.WV.TEK.COM (Stan Kalinowski) Organization: Tektronix, Inc., Wilsonville, OR Lines: 67 In article <791@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes: >I'm not too familiar with SCCS, but with RCS it seems that you could >use the "state" field to identify product versions. For instance, >if we're going to make a snapshot/baselevel of the source library and >call it V1.01.02, we could do: > > rcs -sV1.01.01 RCS/* We are currently using a tool that is a layer on top of RCS that does a similar thing. It uses the symbolic name feature of RCS instead of the state field. Using the symbolic name allows multiple product versions to share the same version number of an individual file, thus eliminating redundant "forced" check-ins on files that didn't change between releases. This makes it easy to identify which files changed between releases or builds of different "flavors". The symbolic name "Release_V1_01_01" would be attached to a given version (12.34) with the following command: rcs -nV1_01_01:12.34 The syntax of RCS does not allow decimal points (".") in the symbol string so we generally substitute the underbar ("_") character. An added benifit of all this is that a simple "rlog -h " quickly reveals all activity on the given file. We also maintain a version list for each build that contains the version information for every file used in that build. I think someone called this an "slist". Basically, the file is a C source file with an RCS "$HEADER" as a literal C string definition that can be reported by the software on demand. (Actually we parse it and report in our own format.) The header information for all files used to build the system appears as a C comment in the same file. The file is, of course, maintained with RCS and symbolic names are attached significant versions. With this file, it is possible to reconstruct every build of the system that was ever released and even the development builds that occurred in between. Mind you, it may take awhile for RCS to checkout really old versions because all the deltas must be applied, each in turn. I should also note that in our approach, we have abandoned modification dates as a means of knowing when files need to be checked out, several parallel projects share the common RCS file for a given module and we don't want a change on one version branch to cause recompilation for a project on a different branch. At checkout time, the version number associated with a symbolic name that marks the "latest-and-greatest" is compared with the version in the local directory and a new one is checked out as needed. Of course the engineer has the option of building against the "good old stuff" if he's afraid of bugs introduced by his cohorts. What I'm curious about is, how are people managing their binaries? Right now we are using a scheme that allows engineers to use binaries kept out on our fileserver for local development builds but we aren't very smart about maintaining dependancy information. (They can only grab the latest released binaries of whole subsystems, not individual module binaries. Sometimes, when a global header file changes, they must do much local recompiling of their own local expermental subsystem, duplicating effort that was done on other machines.) I have thought of using an RDBMS to track the dependancies but they all seem to be horribly slow. (Another group here is using that approach.) stank US Mail: Stan Kalinowski, Tektronix, Inc., Interactive Technologies Division PO Box 1000, MS 61-028, Wilsonville OR 97070 Phone:(503)-685-2458 e-mail: {ucbvax,decvax,allegra,uw-beaver}!tektronix!orca!stank or stank@orca.WV.TEK.COM