home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ferkel.ucsb.edu!taco!rock!stanford.edu!ames!sun-barr!cs.utexas.edu!sdd.hp.com!think.com!enterpoop.mit.edu!eru.mt.luth.se!lunic!sunic!seunet!lorelei!hoh
- From: hoh@lorelei.approve.se (Goran Larsson)
- Newsgroups: comp.lang.c
- Subject: Re: SCCS eats good code -- help requested
- Message-ID: <1992Dec20.201522.28201@lorelei.approve.se>
- Date: 20 Dec 92 20:15:22 GMT
- References: <1992Dec18.215413.65833@evolving.com>
- Organization: Home of the Hacker of Hackefors
- Lines: 37
-
- In article <1992Dec18.215413.65833@evolving.com> jww@evolving.com (John W. Woolley) writes:
-
- >Evolving Systems recently began using a new source control system,
- >CMVC, which as I understand it is a wrapper around SCCS. The new
- >source control system interacted with our code in an unintended way.
-
- >We had a chunk of source so:
- > if (strftime(time_str, 64, "%w%H%M%S", time_struct) != 7)
- >
- >Nice normal ANSI C. But SCCS had spotted the string %H% in the
- >above bit of code, and had done its replacement thing so:
- >
- > if (strftime(time_str, 64, "%w12/14/92M%S", time_struct) != 7)
- >
- >which caused strftime to yield results differing somewhat from those
- >intended.
-
- The handling of these version strings is in itself a very good reason
- to avoid SCCS. The decision to only expand version strings when compiling
- is wrong. If I send source to someone, I want to expand version strings
- so "someone" can report problems - but "someone" might also want to
- keep the source under revision control system. SCCS can't do this. RCS can.
-
- >So does anyone know anything good we can do about this? We can't be
- >the first site ever to struggle with format strings and SCCS.
-
- 1) find /usr -name sccs -exec rm -rf {} \;
-
- 2) Install RCS
-
- 3) Use RCS
-
- btw :-)
- --
- Gvran Larsson Phone: +46 13 155535 FAX: +46 13 160533
- Approve AB +46 589 12810 +46 589 16901
- hoh@lorelei.approve.se ...!uunet!mail.swip.net!lorelei!hoh
-