droms@ibm.com (12/05/86)
I'm looking for references to distributed implementations of Walter Tichy's RCS system - especially implementations that do *not* use a shared file system such as IBIS or NFS. Any help would be greatly appreciated. - Ralph Ralph Droms, IBM Watson Research Lab droms@ibm.com, droms@yktvmh.bitnet, ihnp4!purdue!yktpcix!droms
daveb@geac.UUCP (David Collier-Brown) (03/24/88)
In article <7537@ncoast.UUCP> allbery@ncoast.UUCP (Brandon Allbery) writes: [about RCS] > ...but requires a source code license, since it includes 4.xBSD diff sources > modified for RCS. This leaves binary ncoast out in the cold, with SCCS which > is nowhere near as nice to use. (If this has changed, someone please tell me > so I can get my hands on it!) > -- Well, it probably hasn't changed, but one CAN get a copy without the diff source (just the patches) and modify one of the PD diffs. That's what we did at Honeywell TSDC & CCSC when we didn't have Unix licences for our DPS-8s. It took about half a day... --dave -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
m5@lynx.uucp (Mike McNally) (03/30/89)
When a file is checked out (with co) of an RCS directory, it seems to me
that it would be nice if the modification date were set to the date of
the revision. This would keep "make" happy.
Because I've just started using RCS in an attempt to bring some sanity
to our software, I might easily be confused. Perhaps there's a good reason
that the file time should be the time of check-out, and I'm just not really
in the RCS groove. Any explanations are welcome.
--
Mike McNally Lynx Real-Time Systems
uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233
Where equal mind and contest equal, go.dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/30/89)
In article <5372@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: [about timestaps of files checked out with RCS]: >Perhaps there's a good reason >that the file time should be the time of check-out... ...As opposed to the revision time. Yes, there is. Suppose you check out all files and compile. Now you change your mind and check out an earlier revision of one of the source files and type "make" again. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu
chris@mimsy.UUCP (Chris Torek) (03/30/89)
In article <5372@lynx.UUCP> m5@lynx.uucp (Mike McNally) writes: >When a file is checked out (with co) of an RCS directory, it seems to me >that it would be nice if the modification date were set to the date of >the revision. This would keep "make" happy. Since `co' expands RCS keywords, this would be wrong. For instance: % co -l foo.c 1.1 locked % edit foo.c ... % make ... % ./test foo works % ci foo.c ... % co foo.c % make `foo' is up to date. % ident foo $Header: ... chris Locked $ % Other than the single `extra' recompilation (not always unnecessary, as above), if you keep a copy co'd all the time, this is no problem. Alternatively, you can use a variant of `make' that knows about RCS files. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
m5@lynx.uucp (Mike McNally) (03/30/89)
In article <16623@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Since `co' expands RCS keywords, this would be wrong. For instance: ... In article <6389@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Yes, there is. Suppose you check out all files and compile. Now you >change your mind and check out an earlier revision of one of the source >files and type "make" again. OK, I see. I admit that the obvious (and nearly transparent) solution of keeping all the sources checked out (read only) is correct. In addition to these two responses, a more clued-in person here tipped me off to the scene. On the subject of RCS: I saw, in a message from some archive somewhere, mention of some sort of registration that should be carried out with the creator of the RCS system. I can't find any mention of this in the sources I have (which I think came from the usenet archive). -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (03/31/89)
m5@lynx.uucp (Mike McNally) writes:
On the subject of RCS: I saw, in a message from some archive somewhere,
mention of some sort of registration that should be carried out with the
creator of the RCS system. I can't find any mention of this in the sources
I have (which I think came from the usenet archive).
See the file rcs/src/READ_ME in your RCS distribution tree.mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn) (03/31/89)
In article <5372@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >When a file is checked out (with co) of an RCS directory, it seems to me >that it would be nice if the modification date were set to the date of >the revision. This would keep "make" happy. I will bias this toward C program development, but the principals hold pretty well for other things that you would want to RCS. Usually when you check out a revision, you are doing one of two things: 1. Checking out a source file which does not exist in the current directory. (if it did, why would you check it out again? Unless...) 2. You are replacing an existing source file which may have been "hurt" somehow. (Say you made some "fixes" and found that they broke everything, so you want to baseline your software.) In both of these cases, you want a new object file to match your source file. To give an example, say you have foo.c file which produced a foo.o file. You then check out a new foo.c. Chances are, when you do your next make, you want the foo.o file to be remade. If RCS checked out the foo.c file at the last checkin time, foo.o would probably not be remade. -- Mark H. Colburn "Look into a child's eye; Minnetech Consulting, Inc. there's no hate and there's no lie; mark@jhereg.mn.org there's no black and there's no white."
m5@lynx.uucp (Mike McNally) (04/01/89)
In article <741@jhereg.Jhereg.MN.ORG> mark@jhereg.MN.ORG (Mark H. Colburn) writes: >In article <5372@lynx.UUCP> m5@lynx.UUCP (Mike McNally) [ME] writes: >>When a file is checked out (with co) of an RCS directory, it seems to me >>that it would be nice if the modification date ... blah blah blah And many people, including Mr. Colburn, responded. Thanks. The RCS documentation mentions Mr. Tichy's paper from some conference proceedings as a good place to look for in-depth RCS stuff. If anyone can tell me where this stuff is available (like on-line), or if anyone has a copy and wants to mail me one (with my UPS number if it's thick), I'd be happy. Note that I'm not interested in violating any laws, so if I need to buy a copy of the conference proceedings, I will (although I'd probably be too lazy...) -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go.
scs@adam.pika.mit.edu (Steve Summit) (04/01/89)
In article <5372@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: >When a file is checked out (with co) of an RCS directory, it seems to me >that it would be nice if the modification date were set to the date of >the revision. That's exactly what I thought. I'm a stickler for modification time preservation, so this was a requirement of mine for any revision control system I might use. RCS seemed quite powerful otherwise, so I went in and modified it, with the following results: 1. The time associated with a revision is its original modification time, not the time of checkin. 2. When a new revision is checked in on the main branch, the RCS (,v) file inherits the time of the revision being checked in. If ci -u or -l is used, the working copy's modification time is preserved, notwithstanding any keywords which may have been expanded. 3. When any revision is checked out, its original modification time is resurrected. 4. The rcs command preserves the modification time of the RCS (,v) file. I want the modification time of a source file to reflect the last time I did something to it, not the last time it was copied (I use the equivalent of cp -p) checked in or out of RCS, or otherwise manipulated by system utilities. I arranged for the time of the RCS (,v) file to reflect the time of the head revision on the main branch so that ls -lt on the RCS directory gives sensible results, again based on the last time I edited a file. Among other things, this makes it easy to see what needs checking in, by comparing ls -lt of the RCS directory with the working directory. Playing with modification times under RCS in this way has two disadvantages: 1. The timestamps in the RCS file no longer record checkin time; this information is lost. I have never really missed having this information. 2. As has been adequately discussed, there can be problems with make when old versions are checked out, or when keywords are expanded. I simply remember to delete the .o file when I check out an old revision, and I don't use keywords any more, because for me they're more trouble than they're worth. (You can never compare .o files that ought to be identical, because they might contain different RCSid's.) I grant that there's a lot of personal preference involved here, and that having to remember to manually delete .o files can be problematical. For me, having modification times changing every time RCS blinked would be unthinkable; I've been very pleased, and have had no problems, using this modified version of RCS. I could probably be persuaded to make context diffs available, if anyone else is interested in these modifications. If you're not interested, or if you think I'm crazy for having RCS behave this way, all you have to do is not ask me for them. (I bet somebody posts a followup telling me that I'm wrong, anyway.) Steve Summit scs@adam.pika.mit.edu