maujd@warwick.UUCP (Geoff Rimmer) (06/21/88)
Which out of RCS and SCCS do people prefer? I found rcs(1) by mistake in a manual page in our computer unit library - and I've found it very good. What are the good and bad points of each system? Geoff. ------------------------------------------------------------ Geoff Rimmer, Computer Science, Warwick University, UK. maujd@uk.ac.warwick.opal "Let's have a game of cricket. Rik, you're the stumps" ------------------------------------------------------------
mayerar@pyuxe.UUCP (A Mayer) (06/25/88)
In article <710@ubu.warwick.UUCP> maujd@warwick.UUCP (Geoff Rimmer) writes: >Which out of RCS and SCCS do people prefer? I found rcs(1) by mistake >in a manual page in our computer unit library - and I've found it very >good. What are the good and bad points of each system? > >Geoff. One good point of RCS is that it stores the most recent version and uses deltas to get back to the previous versions. SCCS stores the original version and uses deltas to get to the most recent version. Andrew J. Mayer BELLCORE {ariel,burl,clyde,floyd,gamma,harpo,ihnp4,mhuxl,rutgers}!pyuxe!mayerar
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/25/88)
In article <661@pyuxe.UUCP> mayerar@pyuxe.UUCP (80132-A Mayer) writes: >One good point of RCS is that it stores the most recent version and >uses deltas to get back to the previous versions. SCCS stores the >original version and uses deltas to get to the most recent version. No, it doesn't. I don't know who started this myth, but it's false. SCCS makes one sequential pass to do a "get".
g-rh@cca.CCA.COM (Richard Harter) (06/25/88)
In article <661@pyuxe.UUCP> mayerar@pyuxe.UUCP (80132-A Mayer) writes: >In article <710@ubu.warwick.UUCP> maujd@warwick.UUCP (Geoff Rimmer) writes: >>Which out of RCS and SCCS do people prefer? I found rcs(1) by mistake >>in a manual page in our computer unit library - and I've found it very >>good. What are the good and bad points of each system? >> >>Geoff. > >One good point of RCS is that it stores the most recent version and >uses deltas to get back to the previous versions. SCCS stores the >original version and uses deltas to get to the most recent version. This is misleading. RCS stores the most recent version and uses reverse deltas; that is true. The quoted material suggests that SCCS gets the latest version by taking the base and applying all intervening deltas (it doesn't say this but the implication is there). This is not true; SCCS does not work that way. SCCS uses what is sometimes known as interleaved deltas and is sometimes known as the selectable change model. The deltas are not stored separately; they are integrated into the controlled source. I won't go into the details on how this is done; the effect is that the cost of extracting *any* version is proportional to the total number of lines ever present in the controlled text. The cost of extracting a version is greater with SCCS, but only modestly so. The principle differences between RCS and SCCS are the commands and issues dealing with interacting with make. Most people rate RCS as being easier to use than SCCS. Neither is entirely adequate for complex version control problems, but SCCS can do more along those lines than RCS can. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
jfh@rpp386.UUCP (John F. Haugh II) (06/26/88)
In article <8158@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <661@pyuxe.UUCP> mayerar@pyuxe.UUCP (80132-A Mayer) writes: >>One good point of RCS is that it stores the most recent version and >>uses deltas to get back to the previous versions. SCCS stores the >>original version and uses deltas to get to the most recent version. > >No, it doesn't. I don't know who started this myth, but it's false. >SCCS makes one sequential pass to do a "get". just because get(1) only makes one pass over a file does not mean the SCCS file is stored in most-recent-version order. since it is possible to know which versions the desired version depends on, get(1) can follow the insert/delete commands in the s-file to create the desired version. if i start off with a file which reads Now is the time for all good men. and put it in an SCCS file, the results, sans extra cruft is ^AI 1 Now is the time for all good men. ^AE 1 and then you create a delta to make the file Now is the time for all good men. To come to the aid of their party. you end up with ^AI 1 Now is the time for all good men. ^AI 2 To come to the aid of their party. ^AE 2 ^AE 1 since the body for version 1 (as bracketed by the ^AI 1/^AE 1 pair) contains the text for version 2, i would say that SCCS does indeed store the original version and newer deltas. the other way would look like ^AI 2 Now is the time for all good men. ^AD 1 To come to the aid of their party. ^AE 1 ^AE 2 - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, Division "S" | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
g-rh@cca.CCA.COM (Richard Harter) (06/27/88)
In article <3255@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes: >In article <8158@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In article <661@pyuxe.UUCP> mayerar@pyuxe.UUCP (80132-A Mayer) writes: >>>One good point of RCS is that it stores the most recent version and >>>uses deltas to get back to the previous versions. SCCS stores the >>>original version and uses deltas to get to the most recent version. >>No, it doesn't. I don't know who started this myth, but it's false. >>SCCS makes one sequential pass to do a "get". It is my understanding that the original implementation of SCCS was in the form of the original version plus subsequent deltas and that it was changed to the present form (interleaved deltas) circa 1980. If anyone has precise knowledge on this point, could they please post it or send me e-mail. >just because get(1) only makes one pass over a file does not mean >the SCCS file is stored in most-recent-version order. since it is >possible to know which versions the desired version depends on, >get(1) can follow the insert/delete commands in the s-file to create ... specific example deleted ... The answer is, of course, that SCCS uses neither most-recent-version order nor oldest-version-order. It does not apply deltas in the sense of starting with a base version and applying a sequence of updates which produce a sequence of intermediate versions. It does apply deltas in the sense of checking, for each line ever present, the effect of the deltas on the line. The difference in performance between the two senses is enormous; the difference is due to the fact that, in schemes based on the first sense, each line must be processed once for each delta, whereas in the second sense each line is only processed once. It is true, however, that there is, in principle, a signifigant performance advantage for the RCS scheme versus the SCCS scheme. SCCS must process all lines including those not currently active; RCS need only process those that are currently active. Furthermore RCS does not need to do any processing on the line other than copying it out; SCCS has to check the control data for the line. On the other hand, RCS pays a penalty if the version being extracted is not the latest. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
joel@intelisc.UUCP (Joel Clark) (06/28/88)
In article <661@pyuxe.UUCP> mayerar@pyuxe.UUCP (80132-A Mayer) writes: >In article <710@ubu.warwick.UUCP> maujd@warwick.UUCP (Geoff Rimmer) writes: >>Which out of RCS and SCCS do people prefer? >> >>Geoff. > >One good point of RCS is that it stores the most recent version and >uses deltas to get back to the previous versions. SCCS stores the >original version and uses deltas to get to the most recent version. > > Andrew J. Mayer > BELLCORE > >{ariel,burl,clyde,floyd,gamma,harpo,ihnp4,mhuxl,rutgers}!pyuxe!mayerar Even though I have written software with similar functionality as SCCS, I have never understood this argument about storing the most recent version as opposed to storing the original version. For example given the following actual SCCS file: I 1 /* * module control port settings */ D 2 #define NPGM_DONE 0x01 E 2 I 2 #define RRCV 0x02 E 2 #define RLSRCV 0x02 #define NPROGRAM 0x80 E 1 We see the original and the most recent stored in the same manor, line by line. Any program trying to a extract version still has to look at every line to decide if that line is in the desired version or not. Can anyone explain to me how a program could store `the most recent version` such that each line in the file does not need to be examined to determine if it is in the most recent version? Joel Clark Intel Scientific Computers joel@intelisc.uucp.com Beaverton, OR {tektronix}!ogcvax!intelisc!joel (503) 629 7732
dberg@cod.NOSC.MIL (David I. Berg) (06/28/88)
In article <710@ubu.warwick.UUCP>, maujd@warwick.UUCP (Geoff Rimmer) writes: > Which out of RCS and SCCS do people prefer? .......... > ..... What are the good and bad points of each system? > I have used both systems, depending on which was available on the particular computer I was using. I find RCS particularly easier to use than SCCS. In fact, in one case, I converted all my SCCS files to RCS using the sccstorcs utility. Another feature of RCS is that it stores the current version of your file and the changes backward to the original, whereas SCCS stores the original version of your file and the changes forward to the current. Therefore, it will take SCCS a trifle longer to produce the current version than RCS.
ekrell@hector.UUCP (Eduardo Krell) (06/29/88)
In article <290@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >Can anyone explain to me how a program could store `the most recent version` >such that each line in the file does not need to be examined to determine >if it is in the most recent version? You store the most recent version at the beginning of the file in clear text followed by the reverse delta to get the previous version (followed by the reverse delta to get the version before that, etc.). Time to get the latest version is thus proportional only to the size of that version. Time to get version N is proportional to the size of the last version plus the size of all deltas necessary to get from there down to version N. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com
g-rh@cca.CCA.COM (Richard Harter) (06/29/88)
In article <290@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >Can anyone explain to me how a program could store `the most recent version` >such that each line in the file does not need to be examined to determine >if it is in the most recent version? There are two different ways that I know of to do this. One is the way RCS does it. When the file is updated the delta is calculated in terms of carrying the latest version to the previous version. The delta is appended to the stored deltas, and the previous version is replaced by the updated version. I can't give you the details on the other way (it is proprietary to ADC) but the essence of the matter is the information about the lines do not have to be stored with the lines. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
landauer@morocco.Sun.COM (Doug Landauer) (06/29/88)
In article <1134@cod.NOSC.MIL>, dberg@cod.NOSC.MIL (David I. Berg) wrote: > Another feature of RCS is that it stores the current > version of your file and the changes backward to the original, whereas > SCCS stores the original version of your file and the changes forward > to the current. This is a common misconception (oversimplification) -- it implies that it could take significantly longer using SCCS to get the current version of the file than for it to get the original version. In fact, SCCS does not store separate deltas; it stores all of the deltas together, in the appropriate places within "the original file", in the file in such a way that it takes about the same amount of time to get any version. There are several barely relevant performance implications of the differences between this scheme and what RCS does: + for RCS: For retrieving the latest version (RCS is betting that this is the most common case), RCS is likely to be faster; ~ : For retrieving any other versions, RCS slows down relative to its own performance on the latest version (and at some point depending on how many deltas as well as how many lines changed per delta, it may be slower than SCCS); + for SCCS: Doing RCS check-ins (storing new versions) should be distinctly slower than doing SCCS deltas; > I find RCS particularly easier to use than SCCS. I personally agree with this statement (disclaimer: Sun doesn't officially agree). The BSD "sccs" front-end command helps some. Finally, the performance differences mentioned above probably add up (over the course of my entire SCCS career) to less time than I spent composing this message (as David I. Berg put it, "it will take SCCS a trifle longer"), so the ease-of-use factor should become the overriding factor if you're starting a new project in a new company or on your own. In practice, the "what-they-use-here" factor is the real overriding factor. This is one of the few areas where VMS (gasp!) really does do better than Unix (IMHO) -- DEC's CMS (though it has brain damage in some ways) really does have some features that would make it, on the whole, better than either SCCS or RCS, if you could use it on Unix instead of VMS. -- Doug Landauer Sun Microsystems, Inc. ARPA Internet: landauer@sun.com Software Products Division UUCP: ...!sun!landauer -- Acronym glossary: (Some of these are trademarks -- you know who you are.) BSD -- Berkeley Software Distribution CMS -- Code Management System (I think) DEC -- Digital Equipment Corporation IMHO -- In My Humble Opinion RCS -- Revision Control System SCCS -- Source Code Control System UUCP -- Unix-to-Unix CoPy VMS -- Virtual Memory System (an operating system for some DEC computers) --
haugj@pigs.UUCP (Joe Bob Willie) (06/29/88)
In article <29975@cca.CCA.COM>, g-rh@cca.CCA.COM (Richard Harter) writes: > It is true, however, that there is, in principle, a signifigant performance > advantage for the RCS scheme versus the SCCS scheme. SCCS must process > all lines including those not currently active; RCS need only process those > that are currently active. Furthermore RCS does not need to do any processing > on the line other than copying it out; SCCS has to check the control data > for the line. On the other hand, RCS pays a penalty if the version being > extracted is not the latest. > -- > Richard Harter, SMDS Inc. [ In the Oil Fields of HELL, Where the drought grows long and HOT ] OK - I'll bite, and I'm sure others will also. What exactly does an RCS file look like. I'm a die-hard SCCS junkie. How about a few specific examples for those of us without RCS or RCS documentation. - John. -- The Beach Bum Big "D" Home for Wayward Hackers UUCP: ...!killer!rpp386!jfh jfh@rpp386.uucp :SMAILERS "You are in a twisty little maze of UUCP connections, all alike" -- fortune
g-rh@cca.CCA.COM (Richard Harter) (06/29/88)
In article <10406@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >In article <290@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >>Can anyone explain to me how a program could store `the most recent version` >>such that each line in the file does not need to be examined to determine >>if it is in the most recent version? >You store the most recent version at the beginning of the file in clear >text followed by the reverse delta to get the previous version >(followed by the reverse delta to get the version before that, etc.). >Time to get the latest version is thus proportional only to the size of >that version. Time to get version N is proportional to the size of >the last version plus the size of all deltas necessary to get from there >down to version N. It is not quite that simple. The obvious method to use to get a version N down is to build N successive versions by applying the deltas in turn. If you do this the cost is N times the average version size. You can do much better than this by maintaining linked lists and manipulating line numbers only. This reduces the size of the problem since each line is only processed once; however the arrays of line numbers must be reworked for each version. This again is a cost of N times the average version size, albeit with a much smaller constant. This cost if (as far as I know) unavoidable if deltas are framed in terms of line numbers. The cost can be reduced to size of last version plus deltas if line identifers are associated with each line with deltas being recorded in the form of references to line identifiers rather than line numbers. However this increases the time required for an update, since the table of line identifiers must be updated with each version. If this is managed correctly the cost of updating line identifiers is less than the difference calculation by a large margin. If anyone has access to the RCS implementation (I do not) I would be interested in hearing whether it uses raw line numbers in the implementation or something more sophisticated. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
chris@mimsy.UUCP (Chris Torek) (06/29/88)
In article <214@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >What exactly does an RCS file look like. It looks like this? (There, that gives an appropriate distribution of ? and . characters, if not in the right places :-) ) Comments by me appear on the far right. head 1.1; most recent rev access ; list of authorised users symbols ; names for specific rev's locks ; owners of locks on rev's comment @# @; for log messages; can ignore descriptor for rev 1.1 1.1 date 88.06.29.00.57.21; author chris; state Exp; branches ; next ; desc descriptive text @program to test for Vax 11/785 cpu bug @ latest rev is 1.1 1.1 log log message about rev 1.1 @Initial revision @ text text of rev 1.1 @start: .word 0 movl $0x80000000,r11 0: extzv $13,$4,-4(r11),r0 brb 0b @ if there were deltas, differences to convert 1.1 to (say) 0.9 would appear here (although 1.1 is always the first rev, unless you force it to be higher). the next delta might then convert rev 0.9 to rev 0.8. In each case a delta is a series of `d #' and `a # <text>' lines, with text quoted in `@' signs. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
wdg@unccvax.UUCP (Doug Gullett) (06/29/88)
The learning curve for using RCS effectively is probably easier that SCCS. I say that since the total number of commands related to RCS is about 6 or 7 (in my personal experence only 2 or 3 are used regularly). When my previous employer did an evaluation of the two, it was decided that a few manual pages would bring programmers up to speed on RCS while whole volumes are written about the use of SCCS. The standard MAKE program understands SCCS and not RCS. This one limitation is solved by intelligent setup of the makefile dependencies. Doug Gullett University of NC at Charlotte #include <standard disclaimers>
joel@intelisc.UUCP (Joel Clark) (06/29/88)
In article <10406@ulysses.homer.nj.att.com> ekrell@hector (Eduardo Krell) writes: >In article <290@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: > >>Can anyone explain to me how a program could store `the most recent version` >>such that each line in the file does not need to be examined to determine >>if it is in the most recent version? > >You store the most recent version at the beginning of the file in clear >text followed by the reverse delta to get the previous version >(followed by the reverse delta to get the version before that, etc.). > >Time to get the latest version is thus proportional only to the size of >that version. Time to get version N is proportional to the size of >the last version plus the size of all deltas necessary to get from there >down to version N. > > Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ > > UUCP: {ihnp4,ucbvax}!ulysses!ekrell ARPA: ekrell@ulysses.att.com How well does this work if (as we are) you are working from 3 branches at once. We keep major branches for Development engineers, Sustaining engineers and Evaluation all in the same source file. This allows us to proceed with project that may not go into production for 12-18 months based on the same sources that we ship, folding in the changes to the production code as they become solid.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/30/88)
In article <1023@unccvax.UUCP> wdg@unccvax.UUCP (Doug Gullett) writes: >The learning curve for using RCS effectively is probably easier that SCCS. For routine simple use, that is true, although the difference is not very significant. People who know how to write shell scripts can mimic RCS commands using SCCS utilities, or do even more useful things. >... a few manual pages >would bring programmers up to speed on RCS while whole volumes are written >about the use of SCCS. This is quite misleading. I haven't seen "volumes" on SCCS, but it is easy to use for routine purposes. admin -iFILE s.FILE # create archive get s.FILE # check out latest version for use get -e s.FILE # check out for editing delta s.FILE # check edited version back in
g-rh@cca.UUCP (07/01/88)
... Re the usual argument for RCS and what SCCS really does. >There are several barely relevant performance implications of the >differences between this scheme and what RCS does: > > + for RCS: For retrieving the latest version (RCS is betting that > this is the most common case), RCS is likely to be faster; Actually, if you are using the RCS type scheme, you can gain a real factor of speed by storing the raw latest file by itself since file extraction is a straight copy -- this can be a big win if the hardware supports DMA. However RCS doesn't do this. There are arguments for not doing this -- if anybody mucks with the raw file you have just bitten the big wienie. > + for SCCS: Doing RCS check-ins (storing new versions) should be > distinctly slower than doing SCCS deltas; I see no reason for this statement -- in either case you need to (a) extract the comparison version, and (b) do the difference. This part is the same with RCS having an edge on extraction. You then have to rewrite the history controlled file. In the SCCS scheme you rewrite the entire interleaved file. In the RCS scheme you write the new version and the deltas; these occupy the same space (more or less). There is a potential gain in the RCS scheme in that the rewrite can be done as concatenations. >This is one of the few areas where VMS (gasp!) really does do better >than Unix (IMHO) -- DEC's CMS (though it has brain damage in some ways) >really does have some features that would make it, on the whole, better >than either SCCS or RCS, if you could use it on Unix instead of VMS. CMS is intermediate between simple version control systems (which operate on a single file, e.g. RCS and SCCS) and real configuration manage- ment systems which have means for dealing with collections of files. It has a modicum of CM features. It also has a simple merge facility. The original CMS implementation used a base plus all successive deltas and had horrid problems with speed; the current implementation is decent. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
g-rh@cca.UUCP (07/01/88)
In article <293@intelisc.UUCP> joel@intelisc.UUCP (Joel Clark) writes: >How well does this work if (as we are) you are working from 3 branches at once. >We keep major branches for Development engineers, Sustaining engineers and >Evaluation all in the same source file. This allows us to proceed with project >that may not go into production for 12-18 months based on the same sources >that we ship, folding in the changes to the production code as they become >solid. Not very well. In principle you can do it in SCCS using inclusion and exclusion but it is rather messy. Any system which uses interleaved deltas and lets you do include/exclude of deltas can do it. The problem with SCCS for this is two-fold. The mechanics of handling multiple tracks are awkward and the SCCS nomenclature scheme is a problem when you are dealing with multiple files. The whole thing can be done with shell scripts and auxilliary data files. It's not very lovely. Somebody may have posted the relevant scripts -- if you can avoid it, you don't want to do it yourself. There are commerical systems that do this sort of thing well. We (SMDS) market one called ADC. I don't know of any public domain or near public domain systems that do. SUN's NSE and Apollo's DSEE really don't do multiple tracks with change migration, as far as I can see, although they are nice development environments. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
mitch@Stride.COM (Thomas Mitchell) (07/02/88)
In article <1134@cod.NOSC.MIL> dberg@cod.NOSC.MIL (David I. Berg) writes: >In article <710@ubu.warwick.UUCP>, maujd@warwick.UUCP (Geoff Rimmer) writes: >> Which out of RCS and SCCS do people prefer? .......... Voting for RCS >.... Another feature of RCS is that it stores the current >version of your file and the changes backward to the original, .... Because RCS stores the current version it is much quicker. Also When looking at files -- the current version is present and can just be examined. A little experimentation and the markers used by RCS are easy to find and identify the start of the current version. -- Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702)322-6868 TWX: 910-395-6073 FAX: (702)322-7975 MicroSage Computer Systems Inc. Opinions expressed are probably mine.
rbj@cmr.icst.nbs.gov (Root Boy Jim) (07/02/88)
? From: Doug Gullett <wdg@unccvax.uucp> ? The standard MAKE program understands SCCS and not RCS. This one limitation ? is solved by intelligent setup of the makefile dependencies. Try .DEFAULT: co $@ Of course, then you must explicitly list that every .o file depends on the corresponding .c file. Another gambit if you do not use a separate RCS directory and do not keep sources checked out is: .SUFFIXES: .c,v .c,v.o: co $*.c $(CC) $(CFLAGS) -c $*.c rm $*.c Apologys if I screwed up, I just typed this off the top of my head. It is rumored that some people (ok, I give, U of Md. among others) have hacked make to understand RCS, altho to what level , I don't know. Maybe someone with initials ACT will clear this up. :-) Finally, there is GNU make, which recognizes prefixes as well as suffixes, in a totally new (gnu?) way. I have it but haven't used it yet. ? Doug Gullett ? University of NC at Charlotte (Root Boy) Jim Cottrell <rbj@icst-cmr.arpa> National Bureau of Standards Flamer's Hotline: (301) 975-5688 The opinions expressed are solely my own and do not reflect NBS policy or agreement Careful with that VAX Eugene!
jfh@rpp386.UUCP (John F. Haugh II) (07/02/88)
In article <12222@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <214@pigs.UUCP> haugj@pigs.UUCP (Joe Bob Willie) writes: >>What exactly does an RCS file look like. > >It looks like this? (There, that gives an appropriate distribution >of ? and . characters, if not in the right places :-) ) Comments by >me appear on the far right. [ wonderful example??? deleted ] i hate to ask this question[.,;?:!] (there, that gives most of the punctuation characters on the keyboard ;-) but i really wanted to see an actual (visible ASCII-fied if needbe) RCS file. if someone local to dfw would mail me a uuencoded RCS file, i'd greatly appreciate it. - john "mr. punctuation man". -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
jfh@rpp386.UUCP (John F. Haugh II) (07/02/88)
In article <8187@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1023@unccvax.UUCP> wdg@unccvax.UUCP (Doug Gullett) writes: >>... a few manual pages >>would bring programmers up to speed on RCS while whole volumes are written >>about the use of SCCS. > >This is quite misleading. I haven't seen "volumes" on SCCS, but it is >easy to use for routine purposes. i've seen several long SCCS documents, the longest of which was the SCCS User's Guide, which i recall was about 50 or 75 pages long, which arrived with System III. i've seen other disertations on SCCS, tho none that long. SCCS seems to be extremely simple for simple tasks. but the curve for harder tasks is like O(N**2) or something. trying to maintain multiple branches is HELL, and the error messages which can result are cryptic. which isn't too bad because the error messages are very standardized with SCCS, and the help command is actually helpful. the hardest thing is learning about commands like admin -z for dealing with corrupted files. and then there are the quirks of rmdel, cdc, comb (which i think i must be the only person who uses) and the rest of the members which doug didn't reference. there is much more to SCCS than admin, get and delta. - john. -- John F. Haugh II +--------- Cute Chocolate Quote --------- HASA, "S" Division | "USENET should not be confused with UUCP: killer!rpp386!jfh | something that matters, like CHOCOLATE" DOMAIN: jfh@rpp386.uucp | -- with my apologizes
chris@mimsy.UUCP (Chris Torek) (07/02/88)
>In article <12222@mimsy.UUCP> I included a short RCS file. In article <3493@rpp386.UUCP> jfh@rpp386.UUCP (John F. Haugh II) writes: >i hate to ask this question[.,;?:!] (there, that gives most of the >punctuation characters on the keyboard ;-) but i really wanted to >see an actual (visible ASCII-fied if needbe) RCS file. That *was* an actual RCS file. No encoding is needed. RCS embeds arbitrary text in `@' delimiters; `@'s are represented by doubling them. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
gwyn@brl-smoke.ARPA (Doug Gwyn ) (07/03/88)
In article <3494@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes: >there is much more to SCCS than admin, get and delta. My point is that you rarely need to worry about the others. We use SCCS routinely here (some of us do, anyway), and I recall using "comb" and "prs" only a couple of times each, "sccsdiff" a few times, and other SCCS utilities I didn't mention not at all. We have used some of the "admin" options to control who gets to modify the archives etc. but even that is wrapped up in a "new_sccs" shell script so it's easy to use. I agree that SCCS is not perfect (branch deltas are a botch, for example), but neither is RCS.
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (07/03/88)
>From article <3493@rpp386.UUCP>, by jfh@rpp386.UUCP (John F. Haugh II): > i hate to ask this question[.,;?:!] (there, that gives most of the > punctuation characters on the keyboard ;-) but i really wanted to > see an actual (visible ASCII-fied if needbe) RCS file. > > if someone local to dfw would mail me a uuencoded RCS file, i'd > greatly appreciate it. There's no need to "ASCII-fy" or uuencode unless the file being RCS'ed itself contains nonprintable characters. Here's an actual RCS file of my .logout file (a toy example, however): --- RCS/.logout,v --- head 1.2; access ; symbols ; locks ; strict; comment @@; 1.2 date 88.07.02.12.45.09; author mkhaw; state Exp; branches ; next 1.1; 1.1 date 88.07.02.12.43.31; author mkhaw; state Exp; branches ; next ; desc @example RCS file @ 1.2 log @can't embed Log in shell script (no syntax for multiline comments) @ text @ # $Header: .logout,v 1.1 88/07/02 12:43:31 mkhaw Exp $ # replaced "Log" header with this comment clear @ 1.1 log @Initial revision @ text @d2 1 a2 1 # $Header$ d4 1 a4 1 # $Log$ @ --- END of RCS/.logout,v --- The initial version of the file was: --- .logout --- # $Header$ # $Log$ clear --- END of .logout --- After checking in the initial version ("ci"), I changed the second comment line to: # replaced "Log" header with this comment and checked the file back in. You can see that the RCS file starts with a bunch of administrivial lines, then the complete verbatim latest version, then diff-like lines for the reverse-delta to the previous version(s). Mike Khaw -- internet: mkhaw@teknowledge.arpa uucp: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge.arpa hardcopy: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303
charles@dragon.UUCP (Charles Wolff) (08/02/88)
In article <3494@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) writes: >In article <8187@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >>In article <1023@unccvax.UUCP> wdg@unccvax.UUCP (Doug Gullett) writes: ...and so forth. Since sccs vs. rcs is back in the news, I'll add my thoughts. I studied the two to decide which we'd use for our 88000 sourcebase. We ended up using rcs, but my conclusion was that with a little clever shell scripting you could pretty well do whatever you wanted with either one... in fact, we basically went with rcs just because our 68000 group was using sccs and we wanted to see what the differences would be. we did come across an interesting problem with sccs today... we had a shell script in one of our utilities where the author (are you reading this, Fred Fish?) wanted to capture the current date and time in a format suitable to use with the "touch" command, so he did something like: DATE_TOUCH=`date +%m%d%H%M%y` when we checked it into and back out of the sccs source base however, something happened... sccs saw %H% in the middle of the line and decided that was an SCCS significant string... so on checking out the file, converted it to the current date in MM/DD/YY format. Oops... if anybody has any brilliant suggestions for how to get around this, they'd be welcome... -- "Whenever the literary German dives into a sentence, | Charles Wolff that is the last you are going to see of him till he | Motorola Microsystems emerges on the other side of his Atlantic with his verb | Tempe, AZ in his mouth." --Mark Twain, Connecticut Yankee | (602) 438-3432
gwyn@smoke.ARPA (Doug Gwyn ) (08/02/88)
In article <1207@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, 602 438-3432) writes: >we did come across an interesting problem with sccs today... > DATE_TOUCH=`date +%m%d%H%M%y` >... sccs saw %H% in the middle of the line and decided >that was an SCCS significant string... Yes, "get"'s %X% substitution is useful except when something like this happens. "get -k" will suppress all %X% keyword substitutions. If you want to suppress just an individual case, I know of no method other than to arrange for there to be no keyword pattern. E.g. DATE_TOUCH=`date +%m%d%H'%'M%y`
grs@alobar.ATT.COM (Gregg Siegfried) (08/02/88)
In article <1207@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, 602 438-3432) writes: > DATE_TOUCH=`date +%m%d%H%M%y` > >when we checked it into and back out of the sccs source base however, >something happened... sccs saw %H% in the middle of the line and decided >that was an SCCS significant string... so on checking out the file, >converted it to the current date in MM/DD/YY format. Oops... if anybody >has any brilliant suggestions for how to get around this, they'd be >welcome... I experienced this in a C program about a year ago .. It can be the source of some really interesting results. I got around it by using backslashes. DATE_TOUCH=`date +%m\%d\%H\%M\%y` should do the trick.. >"Whenever the literary German dives into a sentence, | Charles Wolff >that is the last you are going to see of him till he | Motorola Microsystems >emerges on the other side of his Atlantic with his verb | Tempe, AZ >in his mouth." --Mark Twain, Connecticut Yankee | (602) 438-3432 -- Gregg Siegfried | Nothing I say should be taken as AT&T AT&T - Cincinnati | policy or opinion .. I just hack here. UUCP: grs@alobar.att.com | Don't Rock - Wobble ARPA: grs%alobar.att.arpa | 513-629-8314 (work) 513-561-0368 (antiwork)
ok@quintus.uucp (Richard A. O'Keefe) (08/03/88)
In article <1207@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, 602 438-3432) writes: >In article <3494@rpp386.UUCP> jfh@rpp386.UUCP (The Beach Bum) wrote: [They have a problem with SCCS, a file containing] > DATE_TOUCH=`date +%m%d%H%M%y` [has the %H% recognised as an SCCS keyword. He asked for suggestions.] Try putting backslashes in front of the percents, thus: DATE_TOUCH=`date +\%m\%d\%H\%M\%y` The shell will be happy with them, and SCCS will be put off the scent.
goudreau@xyzzy.UUCP (Bob Goudreau) (08/07/88)
In article <1207@dragon.UUCP> charles@dragon.UUCP (Charles Wolff, 602 438-3432) writes: >we did come across an interesting problem with sccs today... we had a >shell script in one of our utilities where the author (are you reading >this, Fred Fish?) wanted to capture the current date and time in a format >suitable to use with the "touch" command, so he did something like: > > DATE_TOUCH=`date +%m%d%H%M%y` > >when we checked it into and back out of the sccs source base however, >something happened... sccs saw %H% in the middle of the line and decided >that was an SCCS significant string... so on checking out the file, >converted it to the current date in MM/DD/YY format. I once ran into a very similar problem: a date command in an SCCS archived makefile. The solution was simple -- define a make variable named PCT that consisted solely of the string "%" and replace all %'s that could cause trouble with $(PCT). That way, no SCCS keywords at all were present in the makefile. This method can also be used in shell scripts, of course: PCT=% DATE_TOUCH=`date +${PCT}m${PCT}d${PCT}H${PCT}M${PCT}y` A hack, admittedly, and it decreases the readability of the shell script, but it keeps SCCS from munging your source. -- Bob Goudreau Data General Corp., 62 Alexander Drive, Research Triangle Park, NC 27709 (919) 248-6231 {ihnp4, seismo, etc.}!mcnc!rti!xyzzy!goudreau goudreau@dg-rtp.dg.com
wombat@urbsdc.Urbana.Gould.COM (08/15/88)
This happened with a file on the user-contributed software tape that came with 4.2BSD. A '%D%' got expanded to a date in the middle of a printf string, causing mysterious failures.... "I think you should kill him and eat his brain," Mr. Frostee said quickly. "That's not the answer to *every* problem in interpersonal relations," Cobb said. *Software*, Rudy Rucker Wombat uunet!uiucuxc!urbsdc!wombat, wombat@urbsdc.Urbana.Gould.COM