Re: Year 2000 - an alternative headache

In article <33995E4E.19357D62@mindspring.com>, Tim Schaefer <tschaefe@mindspring.com> writes >Jonathan Leffler wrote: >> >> Hi, >> >> If you don't use SCCS, you don't need to read any further. >> >> The existing SCCS file format uses a 2-digit year field. Funnily >> enough, this does not work well once we reach the year 2000. I tested >> this on my Sun Sparc running Solaris 2.5.1 by setting the date to 2002. >> If you manage to get a file into SCCS, it comes out with corrupted >> information, and fetching an old file was not reliable either. >> Oh great,we have 15 sites. 5 are on one source tree + library on machine 1. 2 others are on 2 separate source trees on machine 2 the others are on machine 3 with one library tree, a shared generic source tree and separate site specific source trees. Each tree apart from the ones on machine 3 has ~200 PROGRAMS in it! i.e. >1000 forms and >1000 modules! I figure maybe 10000 4gls and 10000 forms! We don't use SCCS branches but even so this should be fun! > >> Sun is going to be releasing patches for SCCS on Solaris later this year >> (see their Year 2000 pages at http://www.sun.com). I have not been able >> to determine whether their change will be the same as anybody else's >> change to handle the year 2000. It is not clear, therefore, whether >> SCCS files will continue to be portable to all different machines after >> the year 2000. >> We use an ICL DRS 6000, an ICL Teamserver and a SCO Pentium box. > >> Consequently, and much to my chagrin, I've converted from SCCS to RCS, >> which uses 4-digit dates. I still don't like a number of features of >> RCS, but having the source code control programs work after the year >> 2000 offsets the other problems. It is also inherently portable. We use a set of scripts which sit on top of SCCS and provide version control for programs rather the modules so with a bit of tweaking this should be ok (there are only 3 scripts, get,delta and unget!). [Don'I you just love simple configurations!] >> Traditionally, SCCS files have been too, but it isn't clear whether all >> the vendors will use the same fix for SCCS, so I'm not taking any >> chances. >> >> I do have a comprehensive version of sccs2rcs which I'll post if people >> are interested. It is Bourne/Korn shell script (the original was C >> Shell), and its what I used to do all my conversions. The only item I'm >> not happy with is the way it handles (or, rather, doesn't handle) >> branch versions such as 1.10.1.3. >> Greate - I've love a copy - we use Korn shell. >> I only had one file affected by this, so I ducked and finished that file >> manually. >> >> Yours, >> Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> > >Jonathan and group, > >I have a conversion program too, for SCCS-to-RCS, however I can't say it's >better than your newer sccs2rcs. The last time I looked at sccs2rcs it >was woefully inadequate, and scary. I couldn't tell what it was up to. >So, I wrote my own, and I believe it goes three-deep: > >1.1.2.1.3.1 > 1 2 3 > >It could probably go deeper, with a minimum amount of modification. I haven't >diddled with it in over a year, but my tools work %100 and it's been proven >to work on rather large distributions. The docs may not be enough, but I can >help whoever is interested. > >I had no idea SCCS wasn't year-2000 compliant. Interesting. Yes - thanks Jonathan, saving us again, now where is the similar posting from Ora*le to save their users...:->>... > >Well, anyway, I make mention of my tools not as a competition, but merely >as an alternative, to help. Like I say, I'm not sure if it's better that what >you have Jonathan, but I know it works quite well. Head to the "Master Listing" >at my site and help yourself... > Thanks, PS like the tone of the above paragraph, true co-operation. >And yes, I'd be interested in a copy of your program... > >:-) > >Tim > -- David Williams