Xref: utzoo comp.unix.questions:23014 comp.unix.wizards:22500 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!brutus.cs.uiuc.edu!apple!amdahl!dgcad!gary From: gary@dgcad.SV.DG.COM (Gary Bridgewater) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: Question about RCS check-in Keywords: RCS, ci, help Message-ID: <1835@proa.SV.DG.COM> Date: 17 Jun 90 08:58:17 GMT References: <558@fltk.UUCP> <1990Jun17.050747.27703@cs.umn.edu> Reply-To: gary@proa.SV.DG.COM () Followup-To: comp.unix.questions Distribution: usa Organization: Data General SDD, Sunnyvale, CA Lines: 34 In article <1990Jun17.050747.27703@cs.umn.edu> slevy@klein.geom.umn.edu (Stuart Levy) writes: >Yes. The effect on 'make' of checking RCS'd files in/out really annoyed me. >I modified ci & co to optionally preserve the mod date: on checkin, to >(a) keep the source file modification date unchanged and (b) set the >RCS revision date = source file's mod date; on checkout, to set >checked-out file's mod date = RCS revision date. Works great. > >Walter Tichy argued this shouldn't be the default behavior, though; >if you have a source file on hand, then check out an older revision, >you'd *want* make to remake anything depending on that file. I would argue against it on the grounds that your ident string will will be inconsistent between the source and the executable. That final, "unnecessary" compile is what puts all of them in synch so you can determine what is installed versus what is current. If you don't care about such things that is your perogative - although I would wonder why you would want to disregard such a handy piece of information to save a few minutes of time at the end of a project. In a multi-team effort such niceties can save many hours of hassle - team A produces library A, team B produces library B, team 1 produces product 1 using library A and library B. Knowing what of which was used when is very useful. In a c++ environment it can be critical - right down to the header files. Given that - if you do keep headers in sync you should be able to wrap co with a script that compares the headers between the checked out source and the .o file and, if they are the same, touch's the .o (or the .c) to synch the dates. For header files, this is impractical. A more exotic kludge would be to wrap ci with a script that grabs the date of the source file at the beginning and then touches the .o up to sync. It should also sed the new ident string into the .o while it was at it. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary C++ - it's the right thing to do.