gonzalez@VAX.BBN.COM (07/08/87)
I am attempting to put some (somebody else's) FORTRAN source under SCCS. Being a C hacker, I am somewhat unfamiliar with how f77 stores strings. In C, a convenient way to embed an SCCS string, for later detection by what(1) and strings(1), is to begin each source file with: static char * sccsid = "%W% (...) %G%"; The closest I've been able to get with f77 is to declare a character array in the first function of each source file, and then assign to it: character*72 sccsid . . sccsid = '%W% (...) %G%' There several problems with this. First of all, strings(1) doesn't find the string unless you give it the - switch, because it is unitialized data. Secondly, the function in each source file that has this is doing busy work (the assignment) each time it is called. I first thought that the parameter mechanism was what I wanted, but it appears to be more like #define (the string appears *nowhere* in the object file). Any ideas? -Jim Gonzalez BBN Laboratories, Inc. gonzalez@vax.bbn.com
ron@topaz.rutgers.edu (Ron Natalie) (07/10/87)
Try: character*72 sccsid data sccsid/'%W% ... %G'/ This shows up in strings without the - option.
DeadHead@cup.portal.com (Bruce M Ong) (01/17/91)
Hi - I have a naive question relating to bsd SCCS (on sparc station) I have a source file, test.c, and I have versions 1.1, 1.2, 1.3, and 1.3.1.1, and 1.3.1.2. Now, I want to modify 1.1 and have the changes propagated to anything including and beyond 1.1, to the branches as well. How can I do this? The sccs fix command does not allow me to do this since it is not a leaf node... Thanks for any help - /bruce deadhead@cup.portal.com
singleto@evax.arl.utexas.edu (Gary Singleton) (02/14/91)
I'm posting this for a friend of mine who does not have usenet access. Please respond to singleto@evax.uta.edu or to usenet. Thanks. SCCS and RCS both seem to have a couple of bugs concerning their use of dates and times. First, a discussion of times. SCCS stores delta times in `HH:MM:SS' form, and RCS stores times in `HH.MM.SS' form. While they do handle the 24-hour time rather well, they fail to account for the time zone. Thus, if I am using SCCS or RCS on a networked system that spans more than one time zone, I could get into serious trouble attempting to track the exact time that deltas are made. SCCS can't deal with deltas with a time in the `future', which would occur if user bob made a delta in the EST zone and user ray then immediately checking out that delta for read only in the CST time zone. Part of this problem can be alleviated by executing remote commands, such that all SCCS/RCS commands are executed on a single machine, but this doesn't solve the problem if a networked file system (like NFS) is used instead. Second, a discussion of dates. SCCS stores delta dates in `YY/MM/DD' form, and RCS stores dates in `YY.MM.DD' form. This is obviously going to be a problem after 31-Dec-1999 (which isn't far off), because only the last two digits of the year are stored. RCS doesn't seem to care what the the digits are (allowing the full range of years from 00 to 99), but SCCS dislikes year numbers less than 70. (Remember that 01-Jan-1970 is the `zero' day of the current Unix era, as encoded in the 32-bit signed integer time_t type). Our projects are currently built on top of SCCS, and we deal with the time zone problem by having all delta times made relative to the UTC (Universal Time) zone. It's sometimes a pain to convert between UTC and local time, but it will save our necks when we need to deal with multiple time zones in the future. The two-digit year problem, however, doesn't seem to have a solution, short of rewriting SCCS (which is not an option for us on all of the platforms we support). Some of our version control scripts deal with this problem by assuming that a year number of 70 to 99 represents 1970 to 1999 and a year number of 00 to 69 represents 2000 to 2069. However, this will not save us from the inevitable failure of SCCS when the new millennium rolls in. RCS is less prone to failure, since it doesn't care what the year number is, but we still have to interpret year numbers 00 to 69 differently, so that sorting deltas by date and time is (will be) done correctly. The point of this whole diatribe is to ask the question: will SCCS/RCS be fixed to deal with four-digit years any time soon, (say, before 1999)? Will SCCS/RCS be enhanced to deal with different time zones? If so, how will the changes affect existing SCCS/RCS files? This leads to another question: when Unix runs out of seconds to represent in the time_t type (which is sometime in 2038), will the Unix era be changed? Or is is assumed that by then Unix will be replaced by another operating system that can deal with it? What about archived files that (will) have old date stamps on them? Needless to say, there will be a lot of migration programmers employed by the end of 1999.
runyan@hpcuhc.cup.hp.com (Mark Runyan) (02/16/91)
>/ singleto@evax.arl.utexas.edu (Gary Singleton) / 6:49 am Feb 14, 1991 / >SCCS and RCS both seem to have a couple of bugs concerning their use >of dates and times. > >First, a discussion of times. >SCCS stores delta times in `HH:MM:SS' form, >and RCS stores times in `HH.MM.SS' form. >While they do handle the 24-hour time rather well, In theory, RCS takes into account the timezone. It is suppose to store the actual times in GMT and translate the times based on the TZ variable. Your RCS may vary on this... >Second, a discussion of dates. >SCCS stores delta dates in `YY/MM/DD' form, >and RCS stores dates in `YY.MM.DD' form. >This is obviously going to be a problem after 31-Dec-1999 This has been noted for RCS. Perhaps GNU-RCS will have a solution which may not be completely backward compatible (i.e. expand the year field). >Needless to say, >there will be a lot of migration programmers employed by the end of 1999. 1999 is going to affect a lot of software. Computer companies should start planning now for the pain... Mark Runyan