dnb@fltk.UUCP (David Buonomo) (06/16/90)
We are using RCS to "control" our source. Our strategy has been to keep a read-only copy of each source file checked-out after a check-in (ci -u <file>). This allows us much faster compile/link phases when we build an entire system (there are quite a few source files; > 2000). The system build script simply runs through our baseline tree running any makefile that it finds which in turn will recompile/link recently touched source files. The problem is that the modification time on the source file changes when the check-in occurs. This will cause that file to be recompiled (remember make) even though there was no change to the file, only its modification time changed. Has anyone else experienced a problem of this type? I would appreciate hearing any approaches to how this was resolved. I am currently thinking along the lines of writing a program that will record the current modification time of the file via fstat, check-in the file via ci, and then restore the modification time via utime. Although this will probably work, I feel that there should be SOMEONE out there that has been this route that may have a more elegant/simpler solution. David Buonmomo uunet!fltk!dnb
cpcahil@virtech.uucp (Conor P. Cahill) (06/16/90)
In article <558@fltk.UUCP> dnb@fltk.UUCP (David Buonomo) writes: >The problem is that the modification time on the source file changes when the >check-in occurs. This will cause that file to be recompiled (remember make) >even though there was no change to the file, only its modification time >changed. The big question is "Why are you checking in source files that haven't changed?" -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
rfinch@caldwr.water.ca.gov (Ralph Finch) (06/16/90)
In article <1990Jun16.011650.29099@virtech.uucp> cpcahil@virtech.UUCP (Conor P. Cahill) writes: >In article <558@fltk.UUCP> dnb@fltk.UUCP (David Buonomo) writes: >>The problem is that the modification time on the source file changes when the >>check-in occurs. >The big question is "Why are you checking in source files that haven't >changed?" He probably isn't. Others have checked out the file, made changes, and checked it back in. The makefile detects that the ,v file has changed and proceeds to check out his unchanged version again, and recompile. Does GNU make avoid this problem? -- Ralph Finch 916-445-0088 rfinch@water.ca.gov ...ucbvax!ucdavis!caldwr!rfinch Any opinions expressed are my own; they do not represent the DWR
slevy@klein.geom.umn.edu (Stuart Levy) (06/17/90)
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. It appears I'm not the only one to do this; Silicon Graphics' rcs package has an option which does the same thing, just uses a different option letter (-M). I can send source diffs (against RCS version 3 or 4) for the mods if you like. Stuart Levy, Geometry Group, University of Minnesota slevy@geom.umn.edu, (612) 624-1867
gary@dgcad.SV.DG.COM (Gary Bridgewater) (06/17/90)
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.