That was a speedy response! I have included some attached files with are the IP of the company I work for.
I'll send a copy without the files to the mailing list separately. Can you please treat these files as confidential and delete them when you have finished with them. I'm being super paranoid here, but want to give my employers some peace of mind. > On Dec 13, 2007 9:27 PM, Geoff Hull <[EMAIL PROTECTED]> wrote: > > > > > > Greetings all! > > > > > > We are a COBOL software development company (now moving to Java) and we > > moved to using a Red Hat Enterprise Linux server as our main machine at > > the beginning of this year. We did some trials before moving to Linux, > > to see if there were likely to be any major problems with using CSSC. We > > didn't find any. > > I'm not surprised. I was in the same position just over ten years > ago and built CSSC to do the migration :) And you did a very good job of it, I must say! > > > We copied our 20 years of SCCS files to our new RHEL 4.4 server and > > started > > using CSSC in earnest. There were some minor differences between UNIX > > SCCS and CSSC, but we use a wrapper script (called sccs) so didn't have > > any problems with dealing with these. > > > Our move to CSSC has been remarkably trouble-free. > > I'm very glad to hear this. > > > It is slightly more fussy about file layout, > > Any difference there is almost certainly a bug. Do you have enough > remaining information to be more precise about the differences there? > Mainly the space before the date issue. A sample file s.uwadvc.fil is attached. Line 244 is the offender. SCCS on Solaris 10 will handle this. > > > but we've only had to "fix" about a dozen files out > > of nearly 13,000. We have been using CSSC exclusively for nearly a year > > now. > > Congratulations and thanks for letting us all know. > > > File Problems > > > > > > 1. Our file problems stem from allowing our programmers to manually > > edit > > the SCCS/s.<filename> file and then do "admin -z" on it (to recalculate > > the checksum). > > So you're pretty sure that the format problems you describe were > manually introduced, and not compatibility issues? > > Also, I'm morbidly curious: why do your programmers need to do this? > The only time I have needed to manually edit SCCS files was to fix the > history files which had been corrupted by a non-y2k-compliant version of > SCCS on Dynix. > Hmmm. Yes, we have had some rogue programmers. Some of them got into the habit of editing the SCCS file if they found they had branched a later version than they needed to. Try "cssc get s.uwtotlnlth.sel" on the attached file. This works fine for Solaris 10 (and previously HP-UX 11i v2 and AIX 5.3 - you do get a date warning on the latter). I think there are some deleted revisions, followed by some "deleted" revisions. Try the same "cssc get" for s.uwrgen.old and s.uwmtft.cbl.dck. They are also both okay under Solaris 10 and AIX 5.3. > > > > > > In two of our files we had an extra space before a date field on the > > "d" > > line, for example: > > > > > > ^As 00034/00000/03110 > > ^Ad D 35.2 03/08/07 13:36:08 keith 70 69 > > ^Am 8447 > > ^Ac Add Location Co-ordinate Fields > > ^Ae > > I see you have an MR number there. Do you use an MR validation > script? Up to now, I haven't heard of anybody actually using one, > though the functionality is well tested. > We don't use any validation script. I didn't realize we could until your question. We only switched these on a couple of years ago. These correspond to our "IDs" which are really job numbers I guess. We sometimes enter 2 or 3 MRs. > > This gave us a message like: > > > > > > prs: /s/uniworks/SCCS/s.uwclblr.prt: line 465: Corrupted SCCS file. > > (Invalid number) > > > > > > It was easily fixed - edit the file to remove the space and do an " > > cssc > > admin -z " on the file. (I had renamed /usr/bin/sccs to /usr/bin/cssc to > > avoid conflicts with our sccs script.) > > Watch out for automatic OS upgrades :) We only use CSSC on Linux and it doesn't come with SCCS (obviously), so it would only happen when we upgraded CSSC. > > > > 2. We also found problems in about 8 of our files where our programmers > > had > > manually removed some simple intermediate revisions from the SCCS file, > > and had then run "admin -z" to fix the checksum. SCCS handles this but > > CSSC doesn't. We fixed this by manually editing the file and creating > > phony auto null deltas. > > > This does sound like an incompatibility. It would be nice to fix it, > though it sounds like you have resolved the problem. See above. > > > > Minor Differences > > > > > > prs -d":T" - no space between the "-d" and the parameters > > Yes; modern implementations allow arguments to be separated from the > options, though this is not the ancient behaviour. Back when I was > migrating from SCCS, I was using scripts which used options without > arguments to indicate the lack of a checkin comment, for example. > > I believe it probably would be useful to support modern argument > interpretation, at least as a configure-time option. The problem > though is that it is hard to figure out a change which exaclt > minimised incompatibilities. Because of the risk of unexpected > changes in behaviour I have simply avoid making any changes there. > Yes, I think that is probably not worth the effort. > > CSSC's rmdel allows a person to delete a revision made by another > > programmer > > I had no idea regular SCCS had this feature! Thanks for telling me! > Do you have any idea how this interacts with the authorised-user > list? I think this is a bug, too. My apologies. I got this information second-hand. I just tried it here and got this with AT&T SCCS (Solaris 10): /data/tmp$ delta -m10056 s.uwadvc.fil comments? deleted some lines ERROR [s.uwadvc.fil]: login name or SID specified not in p-file (de2) And with CSSC: sam:/home/gbh/tmp>cssc delta -m10065 -y'nice one!' s.uwadvc.fil delta: s.uwadvc.fil: You have no edits outstanding. Might have been something else our wrapper script was doing. > > > CSSC's sccsdiff is better than SCCS at showing differences revisions > > (doesn't show bogus differences like SCCS does). > > Curious; CSSC's sccsdiff doesn't try to be especially clever. Do you > think there might be circumstances where the difference could be a > problem? I'm not sure, I'm going on what one of our programmers told me. I think it is something that looks like changes in whitespace, but there aren't any changes. I think this has been tested several times by getting the different versions out then doing a diff on them, which showed that some of the differences were "phantoms". > > > CSSC's get command allows for editing (at the same time) of both the > > main > > and a branch. (We prevent this with our sccs wrapper script, so it > > doesn't affect us.) > > [frown.] I didn't know this was not supposed to be possible. Could > you please please please try to make a test script which succeeds with > "real" SCCS but fails with CSSC? Sorry, another thing our script has always stopped us from doing. When I tested this here myself, it works identically for both SCCS and CSSC. > > > > PRS Bug > > > > > > One difference between GNU CSSC and AT&T SCCS is in what is displayed > > for > > the command "sccs prs -l <s.file>". SCCS gives only the latest revision > > whereas CSSC also includes all the auto null delta revisions (if > > present) as well. > > > > > > James, should I register this as a bug on SourceForge as well? > > Please do; it certainly sounds like a bug! > > James. Using the attached s.uwadvc.fil (you will have to take a copy and edit it to remove the extra space, then do "admin -z"), if you do these commands, you'll see what I mean: /home/gbh/tmp$ cssc rmdel -r43.2 s.uwadvc.fil /home/gbh/tmp$ cssc prs -l s.uwadvc.fil Just another note - I note that there is a "to do" to rewrite the sccs2rcs script. An IBM employee - Jonathon Leffler - has already done this, and included it in his "sccstools" package. I found it on this page . He says he has made some improvements to it, such as not getting any source code out of SCCS files to convert them. There is a download link on that page. He may be willing to allow a link to his page from the CSSC web page. Geoff _______________________________________________ cssc-users mailing list cssc-users@gnu.org http://lists.gnu.org/mailman/listinfo/cssc-users
