markv@ingr.UUCP (Mark VandenBrink) (12/09/88)
I have, what I hope is a simple problem. A thousand pardons if this question
has been asked "billions and billions" of times.
In developing a product under SCCS, we have, finally, gotten to the point
where we need to make a release. So far no problems; however, I would like
to "remember" or baseline our platform so that some later time (fixes release,
etc.) I can automagically recreate the platform.
I've kluged up shell scripts to ferret out the "highest" delta from the s-file,
and I save a file that has lines: "/usr2/ee/ti/src/SCCS/s.ti.c 1.3". And
I can write a shell script to read this file and "get -r1.3...." But there
has got to be a better way (ala the VAX/VMS CMS command baseline).
Finally, the question. _IS_ there a better way?? The Unix SYSV 3.1 release
we use has a program called vc(1) that purports to be a version control
filter for SCCS files, but darned if I can see how it is any help.
Send email, post here, send smoke signals, anything!!! :-)
Many thanks in advance.
--
Mark VandenBrink
Intergraph Corp.
...uunet!ingr!b17b!b109i2!markv
(205) 772-1770gwyn@smoke.BRL.MIL (Doug Gwyn ) (12/10/88)
In article <3217@ingr.UUCP> markv@ingr.UUCP (Mark VandenBrink) writes: >In developing a product under SCCS, we have, finally, gotten to the point >where we need to make a release. So far no problems; however, I would like >to "remember" or baseline our platform so that some later time (fixes release, >etc.) I can automagically recreate the platform. Well, UNIX System V has a "comb" utility that can help combine deltas, but if your project is organized like ours, you may want to do what we plan to do, which is to run a massive find on the source tree and for each SCCS archive, do a "get -e", remove the archive, and "admin -i" a replacement archive with SCCS ID 1.1. Something similar but not so drastic could then be done for subsequent releases, so that there are no unreleased changes in the archives except for the current developmental work.
norm@oglvee.UUCP (Norman Joseph) (12/13/88)
From article <9125@smoke.BRL.MIL>, by gwyn@smoke.BRL.MIL (Doug Gwyn ): > In article <3217@ingr.UUCP> markv@ingr.UUCP (Mark VandenBrink) writes: >>In developing a product under SCCS, we have, finally, gotten to the point >>where we need to make a release. So far no problems; however, I would like >>to "remember" or baseline our platform so that some later time (fixes release, >>etc.) I can automagically recreate the platform. > > ... run a massive find on the source tree and for > each SCCS archive, do a "get -e", remove the archive, and "admin -i" a > replacement archive with SCCS ID 1.1. Something similar but not so > drastic could then be done for subsequent releases ... If the version levels of all your source files are of the form `1.*', you may also try doing a `get -e -r2' followed by a `delta'. This will bring the version level of all your source up to `2.1', which you may consider a baseline. At the next release, use `get -e -r3', etc. If you follow this approach after using Doug's suggestion, you should have a history of baseline releases of the form `1.1', `2.1', `3.1'... Intermediate bug fixes and mods will have in-house version levels of the form `<release>.<level>' where `<level>' is > 1. Norm \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\*////////////////////////////////////// Norm Joseph | UUCP: ...!{pitt,cgh}!amanue!oglvee!norm Oglevee Computer System, Inc. | "Everything's written in stone, until the Connellsville, PA 15425 | next guy with a sledgehammer comes along." /////////////////////////////////////*\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
asa@unisoft.UUCP (Asa Romberger) (12/14/88)
In article <3217@ingr.UUCP> markv@ingr.UUCP (Mark VandenBrink) writes: >In developing a product under SCCS, we have, finally, gotten to the point >where we need to make a release. So far no problems; however, I would like >to "remember" or baseline our platform so that some later time (fixes release, >etc.) I can automagically recreate the platform. > ... Why not bump up the MAJOR sccs number by one for the release. Suppose that your current files are version 2.* for all files get -r3 s.filename delta s.filename << COMMENT UPDATE VERSION FOR RELEASE 3 COMMENT get s.filename Since the specified release (-r3) is greater than what is in the file, the current most recent version will be retrieved, but the new version will be 3.1. (See the almost unreadable table under the get(1) manual page!)
clewis@ecicrl.UUCP (12/15/88)
In article <9125@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <3217@ingr.UUCP> markv@ingr.UUCP (Mark VandenBrink) writes: >>In developing a product under SCCS, we have, finally, gotten to the point >>where we need to make a release. So far no problems; however, I would like >>to "remember" or baseline our platform so that some later time (fixes release, >>etc.) I can automagically recreate the platform. > >Well, UNIX System V has a "comb" utility that can help combine deltas, >but if your project is organized like ours, you may want to do what we >plan to do, which is to run a massive find on the source tree and for >each SCCS archive, do a "get -e", remove the archive, and "admin -i" a >replacement archive with SCCS ID 1.1. Doug is using the "change everything in the release to the same SID" approach. Which I don't like because you lose a lot of history on the files. Somewhat less drastic is to use the SCCS "cutoff" facility - specify the date at which the release was frozen to "get" via the "-c" flag. Eg, make GFLAGS="-c880204" Which will cause make to get every SCCS file with the last version before the date specified. Using this method, we used to be able to recreate whole UNIX kernels and utility sets that were byte-per-byte identical. (Mind you, this was before COFF and it's compilation date headers...) -- Chris Lewis, Markham, Ontario, Canada {uunet!attcan,utgpu,yunexus,utzoo}!lsuc!ecicrl!clewis Ferret Mailing list: ...!lsuc!gate!eci386!ferret-request (or lsuc!gate!eci386!clewis or lsuc!clewis)
bak@csd-v.UUCP (Bruce A. Kern) (12/17/88)
In article <3217@ingr.UUCP> markv@ingr.UUCP (Mark VandenBrink) writes: > >In developing a product under SCCS, we have, finally, gotten to the point >where we need to make a release. So far no problems; however, I would like >to "remember" or baseline our platform so that some later time (fixes release, >etc.) I can automagically recreate the platform. > >I've kluged up shell scripts to ferret out the "highest" delta from the s-file, >and I save a file that has lines: "/usr2/ee/ti/src/SCCS/s.ti.c 1.3". And >I can write a shell script to read this file and "get -r1.3...." But there >has got to be a better way (ala the VAX/VMS CMS command baseline). > >Finally, the question. _IS_ there a better way?? The Unix SYSV 3.1 release >we use has a program called vc(1) that purports to be a version control >filter for SCCS files, but darned if I can see how it is any help. > For years I have been on a crusade to get my coworkers to include the following lines in every file: static char *file_name = "whetever.c"; static char *file_date = " Fri Dec 16 22:30:49 EST 1988 "; And then (and this is the important thing) redefine the exit key (not the quit) to search for the date string and replace it with teh current date on exit. If this system is followed then every module in an executable is date stamped, on-line in ascii, as well as every listing. This has saved me many hours of frustration when debugging with an out of date listing. Also it is very easy to draw a thread through an executable and reconstruct it from SCCS under unix or CMS on a vax. Finally when going to the field or giving telephone help to some one in the field a useful set of listings can be compiled. The key is however that the dating be enforced by the painless method of redefining the editor exit key so that the correct date is simply there by default. The programmer has to go out of his/her way to screw things up, almost maliciously since the procedure is so simple. -- Bruce A. Kern 1-203-270-0399 Computer Systems Design Voice: 730 - 1700 Mon. thru Fri. 29 High Rock Road Data: All other times Sandy Hook, Ct. 06482
guy@auspex.UUCP (Guy Harris) (12/18/88)
>And then (and this is the important thing) redefine the exit >key (not the quit) to search for the date string and replace >it with teh current date on exit. Err, umm, "redefine the exit key"? In order to enforce that, you're going to have to enforce the use of an editor that 1) has an exit key, 2) lets you redefine it, and 3) lets you redefine keys to mean "search for a given string and insert the current date". I happen to like such editors. However, it's going to be an uphill climb, at best, to get *everybody* to choose them.
meissner@xyzzy.UUCP (Michael Meissner) (12/19/88)
In article <3217@ingr.UUCP> markv@ingr.UUCP (Mark VandenBrink) writes: | In developing a product under SCCS, we have, finally, gotten to the point | where we need to make a release. So far no problems; however, I would like | to "remember" or baseline our platform so that some later time (fixes release, | etc.) I can automagically recreate the platform. The simplest way is to use branch delta's if your version of SCCS supports them (System V.3 supports them and earlier versions did as well. Sun 3.5 doesn't seem to support them). In preparation to use branch delta's, do the following: admin -fb s.* (ie, set the 'b' flag, which allows branch deltas). You probably want to set up whatever scripts you use to create new sccs files to include -fb automatically. After you make the release, then do the following: get -e -b s.* delta -y"Revmark for release xx" s.* admin -fd2 s.* get s.* The "get -e" line checks out all of your sources as a branch (ie, version numbers will start at 2.1 now instead of 1.xx). The delta checks things back in as always. The admin line sets flag d to 2 (ie, the default version will be the highest delta in release 2). For the next release, you would use 3 instead of 2. The final get just gets the current version of the source (and also is useful to see if there are errors). If you ever want to get the source for release 1, just use the -r1 switch on the get. You can even make changes in release 1 for update type fixes, providing you don't freeze the release with -fc<number> or -fl<list>. Again, on the Sun 3.5 system I tried it on, using -r gave errors. I was able to move sccs files between systems, so if you have a system V-type box, but have to use a broken SCCS, you might be able to move the s.* files to the System V system, do the above steps, and move them back. To be fair to Sun, I seem to remember that I had the exact same problems on DG's port of UNIX (native = DG/UX, hosted = MV/UX). On early rev's which were based on System III and later System V.1, everything worked. When we upgraded to System V.2 (release 3.10 of DG/UX), branch delta's stopped working, though I could move the files to an older system, do the work, and when I moved them back, everything was cool. Finally when we upgraded to System V.3 (release 4.00 of DG/UX), branch delta's worked again. So maybe SunOS 4.00 fixes the problem (which may have been a System V.2 source problem). -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net
meissner@xyzzy.UUCP (Michael Meissner) (12/19/88)
In article <2432@xyzzy.UUCP> meissner@xyzzy.UUCP (Michael Meissner) writes: | (ie, set the 'b' flag, which allows branch deltas). You probably want to | set up whatever scripts you use to create new sccs files to include -fb | automatically. (I know, following up to my own posting) If you do use branch delta's, you also need to modify whatever you use to create new sccs files to add: -r<rel>.1 -fd<rel> where <rel> is the current release number. An alternative to branch delta's is to use WHAT(1) strings that are created by sccs. You have to modify the code, so that each module has lines of the form: #ifndef lint static char sccs_id[] = "%W% %G% %U%"; #endif and then by executing the what command on the binary, it will give you a list of sources, their version number, and the day/time the last change was made. Note, for include files, you have to do something tricky, like define a macro whose body is a string containing "%W% %G% %U%", and have one routine initialize another static char array with the macro. -- Michael Meissner, Data General. Uucp: ...!mcnc!rti!xyzzy!meissner Arpa: meissner@dg-rtp.DG.COM (or) meissner%dg-rtp.DG.COM@relay.cs.net